class templates with pointers to each other in seperate header files

I'm kind of new to creating templates. I've made some small class and
function templates in the past and I have used quite of bit of the STL,
but I am having problems tyring to create templates.

I'm trying to make class templates in seperate header files with
pointers to each other, and I am getting strange errors.

Is it possible to do?

I guess the real problem is the recursive inclusion of the header
files. Is there a workaround?

For non-template classes, I just put the include for one of the headers
in the.cpp file, but I can't do that with templates.

Ben wrote:[color=blue]
> I guess the real problem is the recursive inclusion of the header
> files. Is there a workaround?
>
> For non-template classes, I just put the include for one of the headers
> in the.cpp file, but I can't do that with templates.[/color]

Post a small, self-contained piece of code that illustrates the problem
you're having, along with the error messages you get when you try to
compile. Make sure it is something that we can literally cut&paste and
compile ourselves.

Best regards,

Tom

Ben wrote:[color=blue]
> I'm kind of new to creating templates. I've made some small class and
> function templates in the past and I have used quite of bit of the STL,
> but I am having problems tyring to create templates.
>
> I'm trying to make class templates in seperate header files with
> pointers to each other, and I am getting strange errors.
>
> Is it possible to do?[/color]

Of course. Just forward-declare the template:

template <typename> Foo;

template <typename T> class Bar
{
Foo<T> *
};

Luke

Ben wrote:[color=blue]
> I guess the real problem is the recursive inclusion of the header
> files. Is there a workaround?[/color]

Yes. See the FAQ:
http://www.parashift.com/c++-faq-lite/templates.html
[color=blue]
> For non-template classes, I just put the include for one of the headers
> in the.cpp file, but I can't do that with templates.[/color]

It does get a bit hairy in some cases, but there's a way.

Luke

Thanks for the help!

My includes are a quite messy right now, so I will see if I can clean
it up, and try some of the stuff in the faq.

Ben wrote:[color=blue]
> Thanks for the help![/color]

Certainly.
[color=blue]
> My includes are a quite messy right now, so I will see if I can clean
> it up, and try some of the stuff in the faq.[/color]

It's unfortunate that so many people are taught to add #includes into
headers for everything their class uses. You should only #include what
you absolutely *have to* in a header (most commonly base classes,
by-value members (when not using pimpl), and typedefs), and leave the
rest for the implementation file. This really helps to cut down on
build times and recompilation.

While you're looking at the FAQ, take a peek at the section on posting
etiquette and quoting conventions -- really helps if you indicate what
you're replying to.

Cheers,
Luke

* Luke Meyers:[color=blue]
> Ben wrote:[color=green]
>> Thanks for the help![/color]
>
> Certainly.
>[color=green]
>> My includes are a quite messy right now, so I will see if I can clean
>> it up, and try some of the stuff in the faq.[/color]
>
> It's unfortunate that so many people are taught to add #includes into
> headers for everything their class uses. You should only #include what
> you absolutely *have to* in a header (most commonly base classes,
> by-value members (when not using pimpl), and typedefs), and leave the
> rest for the implementation file. This really helps to cut down on
> build times and recompilation.[/color]

On the contrary.

The Microsoft style makes a mess of file dependencies, introduces
#include statement order depends, with associated problems, and often
results in one big mother-of-all include file to ensure that all that's
required is there, in the right order: imposing on all of the code that
which caused the problems in the first place.

If header inclusion impact negatively on build times, then those headers
are badly designed. First, try to fix them, i.e. add proper include
guards and perhaps (conditional on the compiler) #pragma once. If that
doesn't help, consider whether you're accessing headers off a network
drive and have a really old, less than smart compiler. One fix is then
to upgrade the compiler. Another to move the headers to local storage.
A third, to use local storage wrapper headers.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach wrote:[color=blue]
> * Luke Meyers:[color=green]
> > It's unfortunate that so many people are taught to add #includes into
> > headers for everything their class uses. You should only #include what
> > you absolutely *have to* in a header (most commonly base classes,
> > by-value members (when not using pimpl), and typedefs), and leave the
> > rest for the implementation file. This really helps to cut down on
> > build times and recompilation.[/color]
>
> On the contrary.
>
> The Microsoft style[/color]

Beg pardon? I don't know what "the Microsoft style" is, and I'm
curious why you assume I would. I'll proceed assuming you meant the
practice of minimizing header includes, preferring to place those
includes as locally as possible -- that is, in the implementation
files.
[color=blue]
> makes a mess of file dependencies,[/color]

As I see it, it reduces dependencies. If Bar uses Baz, and Foo uses
Bar but not Baz, under your scheme Foo must recompile anyway
(needlessly) whenever Baz.h changes. If the include of Baz.h is in
Bar.cpp, instead of Bar.h, this recompilation dependency goes away. If
your point of view is really contrary to this, could you please explain
your reasoning?
[color=blue]
> introduces #include statement order depends, with associated problems,[/color]

I fail to see the relationship here. Well-designed headers should not
have order dependencies, regardless of what other headers they do or
don't include. Order dependencies commonly arise from the practice of
relying on some other header to include the header you're using, rather
than just including it yourself. Such side-effects are not part of a
class's interface, can change without notice, and should not be relied
upon.
[color=blue]
> and often
> results in one big mother-of-all include file to ensure that all that's
> required is there, in the right order: imposing on all of the code that
> which caused the problems in the first place.[/color]

I agree that this may occur, given the premise of #include order
dependencies. I disagree that the practice I recommend leads to such
order dependencies.
[color=blue]
> If header inclusion impact negatively on build times, then those headers
> are badly designed.[/color]

In what sense? The recompilation dependency introduced by
unnecessarily moving #includes to headers, per your recommendation, is
sufficient to drastically reduce average build speed.
[color=blue]
> First, try to fix them, i.e. add proper include
> guards and perhaps (conditional on the compiler) #pragma once.[/color]

Include guards are a remedial and obvious step -- omission of them will
cause all sorts of problems in any case. My recommendation assumes
that such basic steps are universally taken -- if they're not, then the
answer is to adopt them, not to move #include directives around.
[color=blue]
> If that
> doesn't help, consider whether you're accessing headers off a network
> drive and have a really old, less than smart compiler. One fix is then
> to upgrade the compiler. Another to move the headers to local storage.
> A third, to use local storage wrapper headers.[/color]

These are non-sequiturs -- while such steps may improve build speeds
for some people in some situations, they have nothing to do with the
aspect of #include structure under discussion. Please let's get back
to the point at hand; explain, if you would, your reasoning from the
point where our opinions diverged.

Luke

* Luke Meyers:[color=blue]
> Alf P. Steinbach wrote:[color=green]
>> * Luke Meyers:[color=darkred]
>>> It's unfortunate that so many people are taught to add #includes into
>>> headers for everything their class uses. You should only #include what
>>> you absolutely *have to* in a header (most commonly base classes,
>>> by-value members (when not using pimpl), and typedefs), and leave the
>>> rest for the implementation file. This really helps to cut down on
>>> build times and recompilation.[/color]
>> On the contrary.
>>
>> The Microsoft style[/color]
>
> Beg pardon? I don't know what "the Microsoft style" is, and I'm
> curious why you assume I would. I'll proceed assuming you meant the
> practice of minimizing header includes, preferring to place those
> includes as locally as possible -- that is, in the implementation
> files.[/color]

It may be that we're not really disagreeing.

However, what you wrote has as its limit to not include other headers in
a header, and leave that to the implementation files, since what you
"absolutely /have to/" include is zero, nix, nada; a common practice
with Microsoft (e.g. Visual Studio generated headers are that way).

Since I only criticized that abhorrent practice, not stating anything
about my own preferences, perhaps that would be in order; see ch 1.6 of
<url: http://home.no.net/dubjai/win32cpptut/html/w32cpptut_01.html>,
where the most important quote is (quoting myself :-) ) "A header file
should always be self-contained: it should be possible to just #include
it without having to #include any other headers first"; subject to that
requirement it's fine to minimize the dependencies, otherwise IMO not.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Alf P. Steinbach wrote:[color=blue]
> It may be that we're not really disagreeing.
>
> However, what you wrote has as its limit to not include other headers in
> a header, and leave that to the implementation files, since what you
> "absolutely /have to/" include is zero, nix, nada; a common practice
> with Microsoft (e.g. Visual Studio generated headers are that way).[/color]

I see now whence came confusion. I could have stated it less strongly,
but do note that I gave several examples of what I meant by "absolutely
have to" -- base classes, by-value members, and typedefs. The
Microsoft Way you describe evidently jumps through hoops to elide even
these, with the consequences you describe. So, I'll try to be less
liberal with universal qualifiers, but I do wonder whether you really
thought I meant to recommend such an extreme, given that doing so would
contraindicate the examples I explicitly gave.
[color=blue]
> Since I only criticized that abhorrent practice, not stating anything
> about my own preferences, perhaps that would be in order; see ch 1.6 of
> <url: http://home.no.net/dubjai/win32cpptut/html/w32cpptut_01.html>,[/color]

I'll have to satisfy myself with the section you quoted -- downloading
and unzipping a word doc is generally past my pain threshold for casual
newsreading. HTML-ify it and I'll gladly take a peek.
[color=blue]
> where the most important quote is (quoting myself :-) )[/color]

I get accused of that a lot when I cite Scott Meyers. ;)
[color=blue]
> "A header file
> should always be self-contained: it should be possible to just #include
> it without having to #include any other headers first"; subject to that
> requirement it's fine to minimize the dependencies, otherwise IMO not.[/color]

Yes. This strikes me as so fundamental that I would rather state it as
an absolute than suggest any ambiguity.

Luke

> Certainly.[color=blue]
>
> It's unfortunate that so many people are taught to add #includes into
> headers for everything their class uses. You should only #include what
> you absolutely *have to* in a header (most commonly base classes,
> by-value members (when not using pimpl), and typedefs), and leave the
> rest for the implementation file. This really helps to cut down on
> build times and recompilation.
>
> While you're looking at the FAQ, take a peek at the section on posting
> etiquette and quoting conventions -- really helps if you indicate what
> you're replying to.[/color]

Aaahh...I finally figured it out! I just removed the #include <B.h>
from A.h, and put an #include <B.h> in front of everywhere that there
is an #include <A.h>

Luke Meyers wrote:[color=blue]
> Alf P. Steinbach wrote:[color=green]
> > It may be that we're not really disagreeing.
> >
> > However, what you wrote has as its limit to not include other headers in
> > a header, and leave that to the implementation files, since what you
> > "absolutely /have to/" include is zero, nix, nada; a common practice
> > with Microsoft (e.g. Visual Studio generated headers are that way).[/color]
>
> I see now whence came confusion. I could have stated it less strongly,
> but do note that I gave several examples of what I meant by "absolutely
> have to" -- base classes, by-value members, and typedefs. The
> Microsoft Way you describe evidently jumps through hoops to elide even
> these, with the consequences you describe. So, I'll try to be less
> liberal with universal qualifiers, but I do wonder whether you really
> thought I meant to recommend such an extreme, given that doing so would
> contraindicate the examples I explicitly gave.
>[color=green]
> > Since I only criticized that abhorrent practice, not stating anything
> > about my own preferences, perhaps that would be in order; see ch 1.6 of
> > <url: http://home.no.net/dubjai/win32cpptut/html/w32cpptut_01.html>,[/color]
>
> I'll have to satisfy myself with the section you quoted -- downloading
> and unzipping a word doc is generally past my pain threshold for casual
> newsreading. HTML-ify it and I'll gladly take a peek.
>[color=green]
> > where the most important quote is (quoting myself :-) )[/color]
>
> I get accused of that a lot when I cite Scott Meyers. ;)
>[color=green]
> > "A header file
> > should always be self-contained: it should be possible to just #include
> > it without having to #include any other headers first"; subject to that
> > requirement it's fine to minimize the dependencies, otherwise IMO not.[/color]
>
> Yes. This strikes me as so fundamental that I would rather state it as
> an absolute than suggest any ambiguity.
>
> Luke[/color]

M$ headers suck a lot!
Try using winsock2.h and you will see wonders

even openGL headers may annoy the M$ unexperienced user :-(