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]

On Oct 10, 6:22*pm, Soumen <[e-mail]:

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]

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.

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

[Victor Bazarov]

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.
There is no way to tell for sure.

>

>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.

Most likely the difference between versions is because the compiler
developers have caught up with the Standard or fixed some bugs in their
product. It would be wise to ask this question in the GCC forum [as
well as, not instead of, here].

>

>~ Soumen

Schobi

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Hendrik Schober]

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?

[...]
V

Schobi

[Kai-Uwe Bux]

Hendrik Schober wrote:

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.
Best

Kai-Uwe Bux

[Hendrik Schober]

Kai-Uwe Bux wrote:

Hendrik Schober wrote:

>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? :)

Kai-Uwe Bux

Schobi

[Kai-Uwe Bux]

Hendrik Schober wrote:

Kai-Uwe Bux wrote:

>Hendrik Schober wrote:

>>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

[Hendrik Schober]

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. :)

Kai-Uwe Bux

Schobi

[James Kanze]

On Oct 15, 1:46*pm, Hendrik Schober <[e-mail]:

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Hendrik Schober]

James Kanze wrote:

On Oct 15, 1:46 pm, Hendrik Schober <[e-mail]:

>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. Although,
in my experience, too, most of the time when at first I thought
I'd found a compiler error I have found one of my own, I did
find several dozen of compiler errors in that time -- and not
just in obscure corner cases. And quite a lot of my 10 years
old code is still in use (although it doesn't need all that
much maintenance nowadays).
But, yes, I was paid to write portable code (and to get compiler
vendors to send us hotfixes).

Schobi

[James Kanze]

On Oct 18, 9:48*pm, Hendrik Schober <[e-mail]:

James Kanze wrote:

On Oct 15, 1:46 pm, Hendrik Schober <[e-mail]:

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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Hendrik Schober]

James Kanze wrote:

On Oct 18, 9:48 pm, Hendrik Schober <[e-mail]:

>James Kanze wrote:

>>On Oct 15, 1:46 pm, Hendrik Schober <[e-mail]:
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.

We were trying to find some middle ground: Push the envelop, but
only so far. :)
Code according to the smallest common sub set had been written in
that company for half a decade. We changed that and tried to apply
more modern techniques. And we found it worked well. When I started
there, the common error report from the field was a crash report,
usually accompanied by data loss. Nowadays, it's that a dialog
popped up telling it found some unexpected error -- and those are
a lot rarer.

Schobi