class templates with pointers to each other in seperate header files

Discussion in 'C++' started by Ben, May 27, 2006.

  1. Ben

    Ben Guest

    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?
     
    Ben, May 27, 2006
    #1
    1. Advertising

  2. Ben

    Ben Guest

    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, May 27, 2006
    #2
    1. Advertising

  3. Ben wrote:
    > 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.


    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
     
    Thomas Tutone, May 27, 2006
    #3
  4. Ben

    Luke Meyers Guest

    Ben wrote:
    > 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?


    Of course. Just forward-declare the template:

    template <typename> Foo;

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

    Luke
     
    Luke Meyers, May 27, 2006
    #4
  5. Ben

    Luke Meyers Guest

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


    Yes. See the FAQ:
    http://www.parashift.com/c -faq-lite/templates.html

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


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

    Luke
     
    Luke Meyers, May 27, 2006
    #5
  6. Ben

    Ben Guest

    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, May 28, 2006
    #6
  7. Ben

    Luke Meyers Guest

    Ben wrote:
    > Thanks for the help!


    Certainly.

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


    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, May 28, 2006
    #7
  8. Re: class templates with pointers to each other in seperate headerfiles

    * Luke Meyers:
    > Ben wrote:
    >> Thanks for the help!

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

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


    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, May 28, 2006
    #8
  9. Ben

    Luke Meyers Guest

    Alf P. Steinbach wrote:
    > * Luke Meyers:
    > > 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.

    >
    > On the contrary.
    >
    > The Microsoft style


    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.

    > makes a mess of file dependencies,


    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?

    > introduces #include statement order depends, with associated problems,


    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.

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


    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.

    > If header inclusion impact negatively on build times, then those headers
    > are badly designed.


    In what sense? The recompilation dependency introduced by
    unnecessarily moving #includes to headers, per your recommendation, is
    sufficient to drastically reduce average build speed.

    > First, try to fix them, i.e. add proper include
    > guards and perhaps (conditional on the compiler) #pragma once.


    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.

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


    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, May 28, 2006
    #9
  10. Re: class templates with pointers to each other in seperate headerfiles

    * Luke Meyers:
    > Alf P. Steinbach wrote:
    >> * Luke Meyers:
    >>> 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.

    >> On the contrary.
    >>
    >> The Microsoft style

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


    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, May 28, 2006
    #10
  11. Ben

    Luke Meyers Guest

    Alf P. Steinbach wrote:
    > 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).


    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.

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


    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.

    > where the most important quote is (quoting myself :) )


    I get accused of that a lot when I cite Scott Meyers. ;)

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


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

    Luke
     
    Luke Meyers, May 28, 2006
    #11
  12. Ben

    Ben Guest

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


    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>
     
    Ben, May 28, 2006
    #12
  13. Luke Meyers wrote:
    > Alf P. Steinbach wrote:
    > > 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).

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

    >
    > 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.
    >
    > > where the most important quote is (quoting myself :) )

    >
    > I get accused of that a lot when I cite Scott Meyers. ;)
    >
    > > "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.

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


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

    even openGL headers may annoy the M$ unexperienced user :-(
     
    Diego Martins, May 29, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Mantoulidis
    Replies:
    3
    Views:
    415
    Jared Dykstra
    Dec 20, 2003
  2. DrUg13
    Replies:
    1
    Views:
    477
    DrUg13
    Feb 10, 2004
  3. moondaddy
    Replies:
    2
    Views:
    581
    Steven Cheng[MSFT]
    Oct 16, 2006
  4. Replies:
    4
    Views:
    485
    EventHelix.com
    Oct 7, 2005
  5. Eric
    Replies:
    8
    Views:
    309
    Mark P
    Oct 28, 2006
Loading...

Share This Page