[Q] Deriving from templates

[Eric]

I've got a fairly simple setup that I thought would work, but I am
getting link errors.
template <class T>
class TType
{
public:
TType( void ) {}
virtual ~TType( void ) {}
virtual void Release( void ) {}
virtual void Retain( void ) {}
protected:
T mRef;
private:
};
template <class T>
class TTree :
public TType<T>
{
public:
TTree( void ) {}
virtual ~TTree( void ) {}
protected:
private:
};
class CTree :
public TTree<long>
{
public:
CTree( void ) {}
virtual ~CTree( void ) {}
Boolean Create( void ) { Release(); return false; }
protected:
private:
};
Elsewhere, I say:

CTree myTree;

Everything compiles, but the link errors I get claim that everything
from the TType class is undefined.

Any ideas?

[Victor Bazarov]

Eric wrote:

I've got a fairly simple setup that I thought would work, but I am
getting link errors.
Have you tried the FAQ?
[..]

[Eric]

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

I've got a fairly simple setup that I thought would work, but I am
getting link errors.

Have you tried the FAQ?

Yes. Unfortunately, it isn't helping much. I have a hard time clicking
my heels twice and thinking of Kansas - at least 34.13 seems to be the
most applicable section in this case.

Of course, what also may not be helping is that what I posted will
compile and link - attempted a short cut that I neglected to test first.

So, it needs to be changed to:

(This code, again, tells me that everything in TType is not defined.)

// TType.h
// TType.h
// TType.h

emplate <class T>
class TType
{
public:
TType( void );
virtual ~TType( void );
virtual void Release( void );
virtual void Retain( void );
protected:
T mRef;
private:
};

// TType.cp
// TType.cp
// TType.cp

template <class T>
TType<T>::
TType( void )
{
mRef = NULL;
}
template <class T>
TType<T>::
~TType( void )
{
}
template <class T>
void
TType<T>::
Release( void )
{
}
template <class T>
void
TType<T>::
Retain( void )
{
}

// TTree.h
// TTree.h
// TTree.h

template <class T>
class TTree :
public TType<T>
{
public:
TTree( void ) {}
virtual ~TTree( void ) {}
protected:
private:
};
class CTree :
public TTree<long>
{
public:
CTree( void ) {}
virtual ~CTree( void ) {}
Boolean Create( void ) { Release(); return false; }
protected:
private:
};

[Victor Bazarov]

Eric wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

I've got a fairly simple setup that I thought would work, but I am
getting link errors.
Have you tried the FAQ?

Yes. Unfortunately, it isn't helping much. I have a hard time clicking
my heels twice and thinking of Kansas - at least 34.13 seems to be the
most applicable section in this case.

No, 34.14 does.

Of course, what also may not be helping is that what I posted will
compile and link - attempted a short cut that I neglected to test first.

So, it needs to be changed to:

[...]

[Eric]

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

I've got a fairly simple setup that I thought would work, but I am
getting link errors.

Have you tried the FAQ?

Yes. Unfortunately, it isn't helping much. I have a hard time clicking
my heels twice and thinking of Kansas - at least 34.13 seems to be the
most applicable section in this case.

No, 34.14 does.

It was a typo. I meant to say 34.14.

Unfortunately, it still isn't helping much.

[Victor Bazarov]

Eric wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:
>I've got a fairly simple setup that I thought would work, but I am
>getting link errors.

Have you tried the FAQ?
Yes. Unfortunately, it isn't helping much. I have a hard time clicking
my heels twice and thinking of Kansas - at least 34.13 seems to be the
most applicable section in this case.

No, 34.14 does.

It was a typo. I meant to say 34.14.

Unfortunately, it still isn't helping much.

Much?

There are three solutions suggested in 34.14. Which one[s] have you tried
and how don't they help?

[Eric]

Eric <eg******@verizon.net> wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

Victor Bazarov <v.********@comAcast.net> wrote:
>Eric wrote:
>
>>I've got a fairly simple setup that I thought would work, but I am
>>getting link errors.
>
>Have you tried the FAQ?
Yes. Unfortunately, it isn't helping much. I have a hard time clicking
my heels twice and thinking of Kansas - at least 34.13 seems to be the
most applicable section in this case.

No, 34.14 does.

It was a typo. I meant to say 34.14.

Unfortunately, it still isn't helping much.

For example, when I attempt to place:

template TType<long>;

at the end of TType.cp (similar to 34.14's Foo.cpp), I get a compile
error. (illegal explicit template instantiation).

Please note, my case is at least a bit different from the one in 34.14.
In my case, I have a class derived from a template derived from a
template. In the case of 34.14, it is simply a direct use of the
template itself.

It is unclear to me why this should make much difference, but perhaps it
does.

[Victor Bazarov]

Eric wrote:

Eric <eg******@verizon.net> wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

>Eric wrote:
>
>
>>I've got a fairly simple setup that I thought would work, but I am
>>getting link errors.
>
>Have you tried the FAQ?
Yes. Unfortunately, it isn't helping much. I have a hard time clicking
my heels twice and thinking of Kansas - at least 34.13 seems to be the
most applicable section in this case.

No, 34.14 does.

It was a typo. I meant to say 34.14.

Unfortunately, it still isn't helping much.

For example, when I attempt to place:

template TType<long>;

at the end of TType.cp (similar to 34.14's Foo.cpp), I get a compile
error. (illegal explicit template instantiation).

Could it be that your compiler is somehow buggy in that area? What
compiler are you using?
Please note, my case is at least a bit different from the one in 34.14.
In my case, I have a class derived from a template derived from a
template. In the case of 34.14, it is simply a direct use of the
template itself.

It is unclear to me why this should make much difference, but perhaps it
does.

Is TType a template? If so, an explicit instantiation of it is allowed.

Anyway, try other solutions.

V

[Eric]

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

>Eric wrote:
>
>
>>I've got a fairly simple setup that I thought would work, but I am
>>getting link errors.
>
>Have you tried the FAQ?
Yes. Unfortunately, it isn't helping much. I have a hard time clicking
my heels twice and thinking of Kansas - at least 34.13 seems to be the
most applicable section in this case.

No, 34.14 does.

It was a typo. I meant to say 34.14.

Unfortunately, it still isn't helping much.

Much?

There are three solutions suggested in 34.14. Which one[s] have you tried
and how don't they help?

I already mentioned that I tried the first one (stick everything into a
single header file) and can apparently get it to work, but this solution
will not, in the end, be a practical one.

In a message you are may be reading as I write this, I tried the second
one (place the equivalent of template Foo<int>; into the equivalent of
Foo.cpp) and am getting a compile time error.

I have not attempted the third, but I suspect it will be of no help
either, since, as the FAQ seems to indicate, the second and third
solutions are virtually equivalent.

[Eric]

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

Eric <eg******@verizon.net> wrote:

Victor Bazarov <v.********@comAcast.net> wrote:
Eric wrote:

>Victor Bazarov <v.********@comAcast.net> wrote:
>
>
>
>>Eric wrote:
>>
>>
>>>I've got a fairly simple setup that I thought would work, but I am
>>>getting link errors.
>>
>>Have you tried the FAQ?
>
>
>Yes. Unfortunately, it isn't helping much. I have a hard time clicking
>my heels twice and thinking of Kansas - at least 34.13 seems to be the
>most applicable section in this case.

No, 34.14 does.
It was a typo. I meant to say 34.14.

Unfortunately, it still isn't helping much.

For example, when I attempt to place:

template TType<long>;

at the end of TType.cp (similar to 34.14's Foo.cpp), I get a compile
error. (illegal explicit template instantiation).

Could it be that your compiler is somehow buggy in that area?

Extremely unlikely.
What compiler are you using?
Latest Codewarrior for MacOSX.

However, when I changed that code to:

template class TType<long>;

It does compile. I am guessing this is a misunderstanding of the FAQ
answer on my part rather then an error in the FAQ.

I am reading the FAQ found at:

<http://www.parashift.com/c++-faq-lit...lates.html#faq
-34.12>

(I scrolled down from 34.12)

Please note, my case is at least a bit different from the one in 34.14.
In my case, I have a class derived from a template derived from a
template. In the case of 34.14, it is simply a direct use of the
template itself.

It is unclear to me why this should make much difference, but perhaps it
does.

Is TType a template?

I posted earlier:

// TType.h
// TType.h
// TType.h

template <class T>
class TType
{
public:
TType( void );
virtual ~TType( void );
virtual void Release( void );
virtual void Retain( void );
protected:
T mRef;
private:
};

// TType.cp
// TType.cp
// TType.cp

template <class T>
TType<T>::
TType( void )
{
mRef = NULL;
}
template <class T>
TType<T>::
~TType( void )
{
}
template <class T>
void
TType<T>::
Release( void )
{
}
template <class T>
void
TType<T>::
Retain( void )
{
}
If so, an explicit instantiation of it is allowed.
I do not doubt that it should be.
Anyway, try other solutions.

Have. Don't work or not practical.

Solution #1 not practical.
Solution #2 still claims undefined for everything in TType.
Solution #3 gives multiply-defined link errors.

And then, I should mention the final part:

// Random.cp
// Random.cp
// Random.cp

#include "TTree.h"

void AFunction ( void )
{
CTree myTree;
}
So, how would you modify TType.h, TType.cp, TTree.h & Random.cp?

[Victor Bazarov]

Eric wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

Eric wrote:

Eric <eg******@verizon.net> wrote:

Victor Bazarov <v.********@comAcast.net> wrote:

>Eric wrote:
>
>
>>Victor Bazarov <v.********@comAcast.net> wrote:
>>
>>
>>
>>
>>>Eric wrote:
>>>
>>>
>>>
>>>>I've got a fairly simple setup that I thought would work, but I am
>>>>getting link errors.
>>>
>>>Have you tried the FAQ?
>>
>>
>>Yes. Unfortunately, it isn't helping much. I have a hard time clicking
>>my heels twice and thinking of Kansas - at least 34.13 seems to be the
>>most applicable section in this case.
>
>No, 34.14 does.
>

It was a typo. I meant to say 34.14.

Unfortunately, it still isn't helping much.
For example, when I attempt to place:

template TType<long>;

at the end of TType.cp (similar to 34.14's Foo.cpp), I get a compile
error. (illegal explicit template instantiation).
Could it be that your compiler is somehow buggy in that area?

Extremely unlikely.

What compiler are you using?

Latest Codewarrior for MacOSX.

However, when I changed that code to:

template class TType<long>;

It does compile. I am guessing this is a misunderstanding of the FAQ
answer on my part rather then an error in the FAQ.

I am reading the FAQ found at:

<http://www.parashift.com/c++-faq-lit...lates.html#faq
-34.12>

(I scrolled down from 34.12)

Please note, my case is at least a bit different from the one in 34.14.
In my case, I have a class derived from a template derived from a
template. In the case of 34.14, it is simply a direct use of the
template itself.

It is unclear to me why this should make much difference, but perhaps it
does.

Is TType a template?

I posted earlier:

// TType.h
// TType.h
// TType.h

template <class T>
class TType
{
public:
TType( void );
virtual ~TType( void );
virtual void Release( void );
virtual void Retain( void );
protected:
T mRef;
private:
};

// TType.cp
// TType.cp
// TType.cp

Uh... Where is

#include "TType.h"

??

template <class T>
TType<T>::
TType( void )
{
mRef = NULL;
}
template <class T>
TType<T>::
~TType( void )
{
}
template <class T>
void
TType<T>::
Release( void )
{
}
template <class T>
void
TType<T>::
Retain( void )
{
}

If so, an explicit instantiation of it is allowed.

I do not doubt that it should be.

Anyway, try other solutions.

Have. Don't work or not practical.

Solution #1 not practical.
Solution #2 still claims undefined for everything in TType.
Solution #3 gives multiply-defined link errors.

And then, I should mention the final part:

// Random.cp
// Random.cp
// Random.cp

#include "TTree.h"

void AFunction ( void )
{
CTree myTree;
}
So, how would you modify TType.h, TType.cp, TTree.h & Random.cp?

I don't know. I can't say I believe I actually have seen them as they
are intended to be or are in your project.

V

[Eric]

Victor Bazarov <v.********@comAcast.net> wrote:

// TType.cp
// TType.cp
// TType.cp
Uh... Where is

#include "TType.h"

??

oops. It's actually there. Copy/Paste mistake.
I don't know. I can't say I believe I actually have seen them as they
are intended to be or are in your project.

Ok. Hopefully someone else will know.

[Jonathan Mcdougall]

Eric wrote:

There are three solutions suggested in 34.14. Which one[s] have you tried
and how don't they help?

I already mentioned that I tried the first one (stick everything into a
single header file) and can apparently get it to work, but this solution
will not, in the end, be a practical one.

Unfortunately, that is how most modern compilers
work. I think only Comeau implements the export
keyword, but you may have a look at your
compiler's documentation.
In a message you are may be reading as I write this, I tried the second
one (place the equivalent of template Foo<int>; into the equivalent of
Foo.cpp) and am getting a compile time error.
The correct syntax is

template class Foo<int>;

Is that an error in the FAQ?
I have not attempted the third, but I suspect it will be of no help
either, since, as the FAQ seems to indicate, the second and third
solutions are virtually equivalent.

The third is only a workaround for the second.

I would suggest to include the function's body in
the class' definition (in the header). I
understand it may not be the best design you saw,
but it is the only one that works reliably.
Jonathan

[Eric]

Jonathan Mcdougall <jo***************@DELyahoo.ca> wrote:

In a message you are may be reading as I write this, I tried the second
one (place the equivalent of template Foo<int>; into the equivalent of
Foo.cpp) and am getting a compile time error.

The correct syntax is

template class Foo<int>;

Is that an error in the FAQ?

Well, the FAQ at:

<http://www.parashift.com/c++-faq-lit...lates.html#faq
-34.14>

is using the syntax

template Foo<int>;

Based on your comments, I have written to the FAQ maintainer and asked
him to take a look at it.

[Eric]

Jonathan Mcdougall <jo***************@DELyahoo.ca> wrote:

Eric wrote:

There are three solutions suggested in 34.14. Which one[s] have you tried
and how don't they help?

I already mentioned that I tried the first one (stick everything into a
single header file) and can apparently get it to work, but this solution
will not, in the end, be a practical one.

Unfortunately, that is how most modern compilers
work. I think only Comeau implements the export
keyword, but you may have a look at your
compiler's documentation.

Huh.

Well, my case will ultimately involve a lot of classes (20+) & several
thousand lines of code. I really wanted a better organization for this
and not be forced to stick everything into a single and probably nearly
unmanageable header file.

I'm still hoping someone will have a hint on how to do what I want to
do.

[Old Wolf]

Eric wrote:

Well, my case will ultimately involve a lot of classes (20+) &
several thousand lines of code.
It worked for the Standard C++ Library, why can't it work for you?
I really wanted a better organization for this and not be forced
to stick everything into a single and probably nearly
unmanageable header file.

Use many header files, then. Model your organization on
an STL implementation that you like.

Also, you only have to put code that depends on the template
parameter into the header file -- eg. your CTree class can
go in a non-header.

[Eric]

Old Wolf <ol*****@inspire.net.nz> wrote:

Use many header files, then. Model your organization on
an STL implementation that you like.

Well, duh.

Thank you.

[Julie]

Old Wolf wrote:

Eric wrote:

Well, my case will ultimately involve a lot of classes (20+) &
several thousand lines of code.

It worked for the Standard C++ Library, why can't it work for you?

I really wanted a better organization for this and not be forced
to stick everything into a single and probably nearly
unmanageable header file.

Use many header files, then. Model your organization on
an STL implementation that you like.

Also, you only have to put code that depends on the template
parameter into the header file -- eg. your CTree class can
go in a non-header.

I'd hardly call the STL portions a model of how to do things. No offense to
PJP, et al., but I consider the STL a _horrible_ mess of virtually unreadable code.

[Victor Bazarov]

Julie wrote:

[...]
I'd hardly call the STL portions a model of how to do things. No
offense to PJP, et al., but I consider the STL a _horrible_ mess of
virtually unreadable code.

I am fairly certain it's perfectly readable to those who wrote it.
It is possible that they use an automated obfuscator before shipping
the final result, of course.

Besides, Mike didn't suggest to use Dinkumware's version _specifically_
but "an STL implementation that you like". If you don't like any [you
have seen], it doesn't mean they all are bad.

V

[Julie]

Victor Bazarov wrote:

Julie wrote:

[...]
I'd hardly call the STL portions a model of how to do things. No
offense to PJP, et al., but I consider the STL a _horrible_ mess of
virtually unreadable code.

I am fairly certain it's perfectly readable to those who wrote it.

Probably. And for the rest of us?
It is possible that they use an automated obfuscator before shipping
the final result, of course.
Yes, possible, but if the case, of very detrimental value.

Forget the code, of all the STL documentation that I've seen, it is based on
that (deliberately or consequentially) obfuscated code. Personally, I rate STL
documentation as the worst there is, but I digress...
Besides, Mike didn't suggest to use Dinkumware's version _specifically_
but "an STL implementation that you like". If you don't like any [you
have seen], it doesn't mean they all are bad.

I'll readily admit that I'm far from an STL expert and have limited exposure to
: Borland's version (from the early days), whatever has shipped w/ MS VisualC++
(Dinkumware included), and SGI. None of those qualify as readable to me.

If you have any recommendations to _any_ implementation that is written w/
/clarity/ in mind, please let me know, same applies to documentation.

If anyone cares, and I doubt that anyone does, those are the *main* reasons
that I don't spend a lot of time w/ STL. I didn't grow up on Unix, and
personally, shun that style and level of obfuscation.

[Victor Bazarov]

"Julie" <[e-mail]> wrote...

Victor Bazarov wrote:

Julie wrote:

[...]
I'd hardly call the STL portions a model of how to do things. No
offense to PJP, et al., but I consider the STL a _horrible_ mess of
virtually unreadable code.

I am fairly certain it's perfectly readable to those who wrote it.

Probably. And for the rest of us?

The Standard headers [even if they exist in a text file form] are not
intended to be read by us[ers]. All we need to know about them is
perfectly readably expressed in the Standard.

It is possible that they use an automated obfuscator before shipping
the final result, of course.

Yes, possible, but if the case, of very detrimental value.

Why? The reason to "obfuscate" it is to protect from possible name
conflicts. Many variables there have the form _X (where 'X' is any
capital letter). Anything that is intended for access (like typedefs
and class/function names) is perfectly readable. Multiple statements
on a single source line is a necessity to keep the processing speed
to a maximum and space to a minimum.
Forget the code, of all the STL documentation that I've seen, it is based
on that (deliberately or consequentially) obfuscated code. Personally, I
rate STL documentation as the worst there is, but I digress...
I suppose the documentation you write is perfect, yes?

Besides, Mike didn't suggest to use Dinkumware's version _specifically_
but "an STL implementation that you like". If you don't like any [you
have seen], it doesn't mean they all are bad.

I'll readily admit that I'm far from an STL expert and have limited
exposure to : Borland's version (from the early days), whatever has
shipped w/ MS VisualC++ (Dinkumware included), and SGI. None of those
qualify as readable to me.

Again, they are not intended to be readable [by you].

Get a copy of STLport, you actually may change your mind. And take a look
at other implementations, like GNU's.
If you have any recommendations to _any_ implementation that is written w/
/clarity/ in mind, please let me know, same applies to documentation.
No, I don't know of any, really. The Dinkumware source is fine with me,
especially since it works if I need to step through it (though very
rarily indeed).
If anyone cares, and I doubt that anyone does, those are the *main*
reasons that I don't spend a lot of time w/ STL. I didn't grow up on
Unix, and personally, shun that style and level of obfuscation.

I don't think the two have anything to do with each other.

V

[Julie]

Victor Bazarov wrote:

"Julie" <[e-mail]> wrote...

Victor Bazarov wrote:

Julie wrote:
[...]
I'd hardly call the STL portions a model of how to do things. No
offense to PJP, et al., but I consider the STL a _horrible_ mess of
virtually unreadable code.
I am fairly certain it's perfectly readable to those who wrote it.

Probably. And for the rest of us?

The Standard headers [even if they exist in a text file form] are not
intended to be read by us[ers]. All we need to know about them is
perfectly readably expressed in the Standard.

Ok, you say that it is there, but not meant to be read/understood -- I
disagree, I think that they _should_ be readable.

Standard == definition != documentation

Forget the code, of all the STL documentation that I've seen, it is based
on that (deliberately or consequentially) obfuscated code. Personally, I
rate STL documentation as the worst there is, but I digress...

I suppose the documentation you write is perfect, yes?

Victor, I have *NEVER* understood that argument.

Are you saying that in order to critique something I must be better than that
thing? I hope not...

In absolute terms, the STL documentation that I've encountered is sub-par, period.

[Victor Bazarov]

Julie wrote:

Victor Bazarov wrote:

The Standard headers [even if they exist in a text file form] are not
intended to be read by us[ers]. All we need to know about them is
perfectly readably expressed in the Standard.

Ok, you say that it is there, but not meant to be read/understood -- I
disagree, I think that they _should_ be readable.

Everybody is entitled to an opinion.
Standard == definition != documentation
In my book, documentation === definition.

Forget the code, of all the STL documentation that I've seen, it is
based on that (deliberately or consequentially) obfuscated code.
Personally, I rate STL documentation as the worst there is, but I
digress...

I suppose the documentation you write is perfect, yes?

Victor, I have *NEVER* understood that argument.

Julie, I have *NEVER* understood people's desire to complain about some
things.
Are you saying that in order to critique something I must be better than
that thing? I hope not...
You get what you pay for. You create documentation when you're paid to
create documentation.

Roads in the USA are crap. And I have no reservation about criticizing
those who are to maintain the roads in the US. I pay them money to
maintain the roads. I do not pay C++ compiler/library implementors to
make headers readable by me. They are readable by the compiler, that's
enough.

If you want documentation, you could pay Dinkumware and get a very nicely
packaged HTML documentation on the Standard C++ library (and Standard C
library, probably too). Check their web site. No, I am not affiliated
with them, nor am I in business promoting their documentation. It's just
an example of what you get when you pay for it.
In absolute terms, the STL documentation that I've encountered is
sub-par, period.

In absolute terms, all documentation that I've encountered is sub-par.
That doesn't mean it's impossible to use it.

There is always this saying I simply loove: he who wants to get things
done finds the means, he who doesn't want to get things done finds
excuses. Not that it's relevant here or anything...

V

[Julie]

Victor Bazarov wrote:

In my book, documentation === definition.
You are probably in a pretty small crowd.
Julie, I have *NEVER* understood people's desire to complain about some
things.
Whatever. Don't know what that has to do w/ the subject at hand.

In absolute terms, the STL documentation that I've encountered is
sub-par, period.

In absolute terms, all documentation that I've encountered is sub-par.
That doesn't mean it's impossible to use it.

Apparently you don't know what par means -- I'll rephrase:

In absolute terms, the STL documentation that I've encountered is below the
/average/ [quality level of general-use documentation], period.
There is always this saying I simply loove: he who wants to get things
done finds the means, he who doesn't want to get things done finds
excuses. Not that it's relevant here or anything...

?!

Irrelevant and condescending.

-end