template related query

[Soumen]

I've a templatized class member function calling templatized member
function of another class.

//A.h
template <class T>
class A {
public:
static T* create();
};

//B.h
class B {

template<class T>
T* makeData();

};

template<class T>
T* B::makeData()
{
return A<T>::create();
}

I get a compile error (gcc 3.3.6) when I include B.h in some X.cpp.
(Error is on the line where I include, not where I instantiate).

But I don't get compile error with gcc 4.2.2. Is there any way that I
can avoid this error in gcc3.3.6?

Regards,
~ Soumen

 

[Soumen]

I've a templatized class member function calling templatized member
function of another class.

//A.h
template <class T>
class A {
public:
static T*      create();

};

//B.h
class B {
public:
template<class T>
T*       makeData();

};

template<class T>
T*      B::makeData()
{
       return A<T>::create();

}

I get a compile error (gcc 3.3.6) when I include B.h in some X.cpp.
(Error is on the line where I include, not where I instantiate).

But I don't get compile error with gcc 4.2.2. Is there any way that I
can avoid this error in gcc3.3.6?

Regards,
~ Soumen

Little correction A is not templatized class, rather create is
templatized method.

class A {
public:
template <class T>
static T* create();
};

Also, B::makeData() is like following:

//B.h
class B {
public:
template<class T>
T* makeData();

};

template<class T>
T* B::makeData()
{
return A::create<T>();
}

 

[Hendrik Schober]

[...]
I get a compile error (gcc 3.3.6) when I include B.h in some X.cpp.
(Error is on the line where I include, not where I instantiate).

So it must suspect you've done something wrong there.

But I don't get compile error with gcc 4.2.2. Is there any way that I
can avoid this error in gcc3.3.6?

Post the exact code that reproduces the error, tell us the
exact error message, and we can begin to speculate about the
compiler's reasoning and whether it's right or wrong.
Don't be as specific, and the answers probably won't get more
specific than mine from above.

~ Soumen

Schobi

 

[Hendrik Schober]

[...]
I get a compile error (gcc 3.3.6) when I include B.h in some X.cpp.
(Error is on the line where I include, not where I instantiate).

So it must suspect you've done something wrong there.

... or the compiler is incapable of processing the code because it is
malfunctioning due to a bug or to a misinterpretation of the Standard.

What would be the difference?

[...]
V

Schobi

 

[Kai-Uwe Bux]

Soumen wrote:
[...]
I get a compile error (gcc 3.3.6) when I include B.h in some X.cpp.
(Error is on the line where I include, not where I instantiate).
So it must suspect you've done something wrong there.

... or the compiler is incapable of processing the code because it is
malfunctioning due to a bug or to a misinterpretation of the Standard.

What would be the difference?

The difference, as I understand it, is _who_ had done something wrong: the
programmer of the code or the programmer of the compiler.


Best

Kai-Uwe Bux

 

[Hendrik Schober]

Hendrik Schober wrote:
Soumen wrote:
[...]
I get a compile error (gcc 3.3.6) when I include B.h in some X.cpp.
(Error is on the line where I include, not where I instantiate).
So it must suspect you've done something wrong there.
... or the compiler is incapable of processing the code because it is
malfunctioning due to a bug or to a misinterpretation of the Standard.

What would be the difference?

The difference, as I understand it, is _who_ had done something wrong: the
programmer of the code or the programmer of the compiler.

If I say the compiler /suspects/ the programmer has done
something wrong, then who's accused?

Kai-Uwe Bux

Schobi

 

[Kai-Uwe Bux]

Victor Bazarov wrote:
Hendrik Schober wrote:
Soumen wrote:
[...]
I get a compile error (gcc 3.3.6) when I include B.h in some X.cpp.
(Error is on the line where I include, not where I instantiate).
So it must suspect you've done something wrong there.
... or the compiler is incapable of processing the code because it is
malfunctioning due to a bug or to a misinterpretation of the Standard.
What would be the difference?

The difference, as I understand it, is _who_ had done something wrong:
the programmer of the code or the programmer of the compiler.

If I say the compiler /suspects/ the programmer has done
something wrong, then who's accused?

The programmer and not the compiler. In the vast majority of cases, the
compilers suspicions are right. I get compiler errors almost all the time,
but I have found only 10 compiler bugs so far.


Best

Kai-Uwe Bux

 

[James Kanze]

[...] I get compiler errors almost all the time,
but I have found only 10 compiler bugs so far.

  You need to do more porting. Or more template stuff. Or both.

It depends on what his boss is paying him to do: write working
(and maintainable) code, or stress test compilers. With modern
compilers, it's actually fairly rare to stumble on a compiler
bug unless you're pushing the envelope well beyond what is
reasonable in a normal production environment.

 

[James Kanze]

Kai-Uwe Bux wrote:
[...] I get compiler errors almost all the time,
but I have found only 10 compiler bugs so far.
  You need to do more porting. Or more template stuff. Or
both.

It depends on what his boss is paying him to do: write
working (and maintainable) code, or stress test compilers.
 With modern compilers, it's actually fairly rare to stumble
on a compiler bug unless you're pushing the envelope well
beyond what is reasonable in a normal production
environment.

  In the last decade I have written code that needed to compile
  using several versions of Borland, Microsoft, Metrowerks, GCC,
  multiplied with several std lib implementations (and versions
  thereof) and, at least with GCC, several platforms.

There are two ways of doing that. One is writing very up to
date C++, with platform dependent work-arounds for errors or
unsupported features. The other is to simply write code using
the common subset of C++ which actually works on all target
compilers. Twenty-five or thirty years ago, the common subset
which worked was very, very small---if you throw in g++ 1.49
(the first compiler I used professionally), it didn't even
include local variables with a destructor. Today, it's a
reasonable subset for most uses, even if you throw in what are
today some very old compilers. And most applications should
take this approach. There are exceptions---some of what Boost
tries to do is intentially pushing the envelope, for example,
legitimately. But be aware that pushing the envelope can be
very expensive, and most commercial operations won't reap any
real benefit from the added cost.