Re: Header File Clutter

Discussion in 'C++' started by Ian Collins, Jan 13, 2011.

  1. Ian Collins

    Ian Collins Guest

    On 01/14/11 08:33 AM, Joe Hesse wrote:
    > When I write many X.h and X.cpp files and debug/modify them, after a
    > while they contain library or other header files that may not be
    > necessary. I realize that there are #ifdef's that prevent a header file
    > from being included more than once so it doesn't hurt to put them in more
    > places than necessary.
    >
    > My question is: Is there a tool to take a C++ program that compiles and
    > reorganize the header files so there are no more #include<blah> than
    > necessary?


    While it is possible, what real benefits would such a tool bring?

    --
    Ian Collins
    Ian Collins, Jan 13, 2011
    #1
    1. Advertising

  2. On Jan 13, 3:11 pm, Ian Collins <> wrote:
    > On 01/14/11 08:33 AM, Joe Hesse wrote:
    >
    > > When I write many X.h and X.cpp files and debug/modify them, after a
    > > while they contain library or other header files that may not be
    > > necessary.  I realize that there are #ifdef's that prevent a header file
    > > from being included more than once so it doesn't hurt to put them in more
    > > places than necessary.

    >
    > > My question is:  Is there a tool to take a C++ program that compiles and
    > > reorganize the header files so there are no more #include<blah>  than
    > > necessary?

    >
    > While it is possible, what real benefits would such a tool bring?


    I would have thought it obvious that it can significantly reduce
    compile times and especially eliminate dependency triggers.

    KHD
    Keith H Duggar, Jan 13, 2011
    #2
    1. Advertising

  3. Ian Collins

    Jorgen Grahn Guest

    On Thu, 2011-01-13, Ian Collins wrote:
    > On 01/14/11 08:33 AM, Joe Hesse wrote:
    >> When I write many X.h and X.cpp files and debug/modify them, after a
    >> while they contain library or other header files that may not be
    >> necessary. I realize that there are #ifdef's that prevent a header file
    >> from being included more than once so it doesn't hurt to put them in more
    >> places than necessary.
    >>
    >> My question is: Is there a tool to take a C++ program that compiles and
    >> reorganize the header files so there are no more #include<blah> than
    >> necessary?

    >
    > While it is possible, what real benefits would such a tool bring?


    Reducing compile times (sometimes drastically).
    Improving readability -- if a file starts with '#include <foolib.h>'
    you expect it to use functionality from foolib.

    Yet, I don't think automatic "weeding" is desireable. The list of
    #includes is to some extent documentation, and should be maintained
    by a real person, IMHO.

    I personally do some manual weeding now and then but don't spend a
    lot of time trying to get it exactly right.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jan 13, 2011
    #3
  4. Ian Collins

    Ian Collins Guest

    On 01/14/11 09:25 AM, Keith H Duggar wrote:
    > On Jan 13, 3:11 pm, Ian Collins<> wrote:
    >> On 01/14/11 08:33 AM, Joe Hesse wrote:
    >>
    >>> When I write many X.h and X.cpp files and debug/modify them, after a
    >>> while they contain library or other header files that may not be
    >>> necessary. I realize that there are #ifdef's that prevent a header file
    >>> from being included more than once so it doesn't hurt to put them in more
    >>> places than necessary.

    >>
    >>> My question is: Is there a tool to take a C++ program that compiles and
    >>> reorganize the header files so there are no more #include<blah> than
    >>> necessary?

    >>
    >> While it is possible, what real benefits would such a tool bring?

    >
    > I would have thought it obvious that it can significantly reduce
    > compile times and especially eliminate dependency triggers.


    Eliminate dependency triggers, yes but significantly reduce compile
    times? Include guards take care of most waste there.

    --
    Ian Collins
    Ian Collins, Jan 13, 2011
    #4
  5. On Jan 13, 1:03 pm, Ian Collins <> wrote:
    > On 01/14/11 09:25 AM, Keith H Duggar wrote:
    >
    >
    >
    > > On Jan 13, 3:11 pm, Ian Collins<>  wrote:
    > >> On 01/14/11 08:33 AM, Joe Hesse wrote:

    >
    > >>> When I write many X.h and X.cpp files and debug/modify them, after a
    > >>> while they contain library or other header files that may not be
    > >>> necessary.  I realize that there are #ifdef's that prevent a header file
    > >>> from being included more than once so it doesn't hurt to put them in more
    > >>> places than necessary.

    >
    > >>> My question is:  Is there a tool to take a C++ program that compiles and
    > >>> reorganize the header files so there are no more #include<blah>    than
    > >>> necessary?

    >
    > >> While it is possible, what real benefits would such a tool bring?

    >
    > > I would have thought it obvious that it can significantly reduce
    > > compile times and especially eliminate dependency triggers.

    >
    > Eliminate dependency triggers, yes but significantly reduce compile
    > times?  Include guards take care of most waste there.


    I wouldn't be so sure. I've heard that judicious use of pImpl combined
    with removing superfluous headers can dramatically reduce build times,
    like on the order of 10x or more.

    I've had some confirming anecdotal evidence as well while working on a
    codebase of ~4000 cpp files.
    Joshua Maurice, Jan 13, 2011
    #5
  6. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On 1/13/2011 3:11 PM, Ian Collins wrote:
    > On 01/14/11 08:33 AM, Joe Hesse wrote:
    >> When I write many X.h and X.cpp files and debug/modify them, after a
    >> while they contain library or other header files that may not be
    >> necessary. I realize that there are #ifdef's that prevent a header file
    >> from being included more than once so it doesn't hurt to put them in more
    >> places than necessary.
    >>
    >> My question is: Is there a tool to take a C++ program that compiles and
    >> reorganize the header files so there are no more #include<blah> than
    >> necessary?

    >
    > While it is possible, what real benefits would such a tool bring?
    >


    The commercial tool Coverity has a checker for some of that.
    It does not reorganize to the optimum, but it will tell you when you
    are including a header unnecessarily.

    - --
    Nelson Ferreira
    Pubkey: http://triatlantico.org/njsf.asc
    (9DFE 82A7 C689 BAEE EC25 A8E8 3C64 1789 7420 ED20)
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.10 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

    iEYEARECAAYFAk0vas4ACgkQPGQXiXQg7SBEsACfbEQi9OIF/9wj0bVXmaAZS2lC
    m+oAnihfzYga4tzvTtnt0zAR9GhX3Jf9
    =7j9H
    -----END PGP SIGNATURE-----
    Nelson Ferreira, Jan 13, 2011
    #6
  7. Ian Collins

    Ian Collins Guest

    On 01/14/11 10:06 AM, Joshua Maurice wrote:
    > On Jan 13, 1:03 pm, Ian Collins<> wrote:
    >> On 01/14/11 09:25 AM, Keith H Duggar wrote:
    >>
    >>
    >>
    >>> On Jan 13, 3:11 pm, Ian Collins<> wrote:
    >>>> On 01/14/11 08:33 AM, Joe Hesse wrote:

    >>
    >>>>> When I write many X.h and X.cpp files and debug/modify them, after a
    >>>>> while they contain library or other header files that may not be
    >>>>> necessary. I realize that there are #ifdef's that prevent a header file
    >>>>> from being included more than once so it doesn't hurt to put them in more
    >>>>> places than necessary.

    >>
    >>>>> My question is: Is there a tool to take a C++ program that compiles and
    >>>>> reorganize the header files so there are no more #include<blah> than
    >>>>> necessary?

    >>
    >>>> While it is possible, what real benefits would such a tool bring?

    >>
    >>> I would have thought it obvious that it can significantly reduce
    >>> compile times and especially eliminate dependency triggers.

    >>
    >> Eliminate dependency triggers, yes but significantly reduce compile
    >> times? Include guards take care of most waste there.

    >
    > I wouldn't be so sure. I've heard that judicious use of pImpl combined
    > with removing superfluous headers can dramatically reduce build times,
    > like on the order of 10x or more.
    >
    > I've had some confirming anecdotal evidence as well while working on a
    > codebase of ~4000 cpp files.


    I guess a lot depends on where you are starting from. If build time is
    considered early enough in a project, it is less of an issue.

    --
    Ian Collins
    Ian Collins, Jan 13, 2011
    #7
  8. On Jan 13, 4:03 pm, Ian Collins <> wrote:
    > On 01/14/11 09:25 AM, Keith H Duggar wrote:
    > > On Jan 13, 3:11 pm, Ian Collins<>  wrote:
    > >> On 01/14/11 08:33 AM, Joe Hesse wrote:
    > >>> When I write many X.h and X.cpp files and debug/modify them, after a
    > >>> while they contain library or other header files that may not be
    > >>> necessary.  I realize that there are #ifdef's that prevent a header file
    > >>> from being included more than once so it doesn't hurt to put them in more
    > >>> places than necessary.

    >
    > >>> My question is:  Is there a tool to take a C++ program that compiles and
    > >>> reorganize the header files so there are no more #include<blah>    than
    > >>> necessary?

    >
    > >> While it is possible, what real benefits would such a tool bring?

    >
    > > I would have thought it obvious that it can significantly reduce
    > > compile times and especially eliminate dependency triggers.

    >
    > Eliminate dependency triggers, yes but significantly reduce compile
    > times?  Include guards take care of most waste there.


    Unfortunately they do not (unless you are talking about external
    guards?). The reason is that due to the textual include mechanism
    and C++ language rules, internal guards still require that the
    entire contents of the header file and recursively on down must
    be scanned and tokenized (but not parsed etc).

    And, it turns out, that for C++ code scanning and tokenization can
    be a substantial if not the lion's share of total compilation time.
    Especially with "modern" code where the headers often comprise huge
    portions of the code.

    By the way, Walter Bright (as you know a genius compiler writer)
    has IIRC talked discussed this a few times in this forum usually
    in the context of a "true" modules system and the inadequacy of
    pre-compiled headers.

    KHD
    Keith H Duggar, Jan 13, 2011
    #8
  9. Ian Collins

    Jorgen Grahn Guest

    On Thu, 2011-01-13, Ian Collins wrote:
    > On 01/14/11 09:25 AM, Keith H Duggar wrote:
    >> On Jan 13, 3:11 pm, Ian Collins<> wrote:
    >>> On 01/14/11 08:33 AM, Joe Hesse wrote:
    >>>
    >>>> When I write many X.h and X.cpp files and debug/modify them, after a
    >>>> while they contain library or other header files that may not be
    >>>> necessary. I realize that there are #ifdef's that prevent a header file
    >>>> from being included more than once so it doesn't hurt to put them in more
    >>>> places than necessary.
    >>>
    >>>> My question is: Is there a tool to take a C++ program that compiles and
    >>>> reorganize the header files so there are no more #include<blah> than
    >>>> necessary?
    >>>
    >>> While it is possible, what real benefits would such a tool bring?

    >>
    >> I would have thought it obvious that it can significantly reduce
    >> compile times and especially eliminate dependency triggers.

    >
    > Eliminate dependency triggers, yes but significantly reduce compile
    > times? Include guards take care of most waste there.


    But eliminating dependency triggers is a way to reduce compile times!

    If I edit foo.h, type "make" and a dozen files are recompiled even
    though the change in foo.h cannot affect the twelve object files, that
    time is wasted.

    (Not that I think a tool is the answer; see elsewhere in the thread.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jan 13, 2011
    #9
  10. On 01/13/2011 03:47 PM, Keith H Duggar wrote:
    > On Jan 13, 4:03 pm, Ian Collins<> wrote:
    >> On 01/14/11 09:25 AM, Keith H Duggar wrote:
    >>> On Jan 13, 3:11 pm, Ian Collins<> wrote:
    >>>> On 01/14/11 08:33 AM, Joe Hesse wrote:
    >>>>> When I write many X.h and X.cpp files and debug/modify them, after a
    >>>>> while they contain library or other header files that may not be
    >>>>> necessary. I realize that there are #ifdef's that prevent a header file
    >>>>> from being included more than once so it doesn't hurt to put them in more
    >>>>> places than necessary.

    >>
    >>>>> My question is: Is there a tool to take a C++ program that compiles and
    >>>>> reorganize the header files so there are no more #include<blah> than
    >>>>> necessary?

    >>
    >>>> While it is possible, what real benefits would such a tool bring?

    >>
    >>> I would have thought it obvious that it can significantly reduce
    >>> compile times and especially eliminate dependency triggers.

    >>
    >> Eliminate dependency triggers, yes but significantly reduce compile
    >> times? Include guards take care of most waste there.

    >
    > Unfortunately they do not (unless you are talking about external
    > guards?). The reason is that due to the textual include mechanism
    > and C++ language rules, internal guards still require that the
    > entire contents of the header file and recursively on down must
    > be scanned and tokenized (but not parsed etc).


    Using "#pragma once" as the first line of the header file solves this
    problem, and is supported in nearly every modern version of GCC, Visual
    Studio and any compiler that uses MCPP as its preprocessor.
    Kevin P. Fleming, Jan 13, 2011
    #10
  11. On 01/13/2011 04:44 PM, Jorgen Grahn wrote:
    > On Thu, 2011-01-13, Ian Collins wrote:
    >> On 01/14/11 09:25 AM, Keith H Duggar wrote:
    >>> On Jan 13, 3:11 pm, Ian Collins<> wrote:
    >>>> On 01/14/11 08:33 AM, Joe Hesse wrote:
    >>>>
    >>>>> When I write many X.h and X.cpp files and debug/modify them, after a
    >>>>> while they contain library or other header files that may not be
    >>>>> necessary. I realize that there are #ifdef's that prevent a header file
    >>>>> from being included more than once so it doesn't hurt to put them in more
    >>>>> places than necessary.
    >>>>
    >>>>> My question is: Is there a tool to take a C++ program that compiles and
    >>>>> reorganize the header files so there are no more #include<blah> than
    >>>>> necessary?
    >>>>
    >>>> While it is possible, what real benefits would such a tool bring?
    >>>
    >>> I would have thought it obvious that it can significantly reduce
    >>> compile times and especially eliminate dependency triggers.

    >>
    >> Eliminate dependency triggers, yes but significantly reduce compile
    >> times? Include guards take care of most waste there.

    >
    > But eliminating dependency triggers is a way to reduce compile times!
    >
    > If I edit foo.h, type "make" and a dozen files are recompiled even
    > though the change in foo.h cannot affect the twelve object files, that
    > time is wasted.


    Use 'ccache'; this will short-circuit the build process if the change to
    foo.h does not in fact result in the output from the preprocessor being
    different (and thus would not affect the compiler's output).
    Kevin P. Fleming, Jan 13, 2011
    #11
  12. Ian Collins

    Goran Guest

    On Jan 13, 10:03 pm, Ian Collins <> wrote:
    > On 01/14/11 09:25 AM, Keith H Duggar wrote:
    >
    >
    >
    > > On Jan 13, 3:11 pm, Ian Collins<>  wrote:
    > >> On 01/14/11 08:33 AM, Joe Hesse wrote:

    >
    > >>> When I write many X.h and X.cpp files and debug/modify them, after a
    > >>> while they contain library or other header files that may not be
    > >>> necessary.  I realize that there are #ifdef's that prevent a header file
    > >>> from being included more than once so it doesn't hurt to put them in more
    > >>> places than necessary.

    >
    > >>> My question is:  Is there a tool to take a C++ program that compiles and
    > >>> reorganize the header files so there are no more #include<blah>    than
    > >>> necessary?

    >
    > >> While it is possible, what real benefits would such a tool bring?

    >
    > > I would have thought it obvious that it can significantly reduce
    > > compile times and especially eliminate dependency triggers.

    >
    > Eliminate dependency triggers, yes but significantly reduce compile
    > times?  Include guards take care of most waste there.


    It's actually about build (not "full build"/"rebuild") times. Imagine:

    h1.h

    stuff

    h2.h

    stuff


    random_source.c

    #include "h1.h"
    #include "h2.h"

    stuff

    Now, suppose that h2.h is not needed in random_source and that
    random_source could compile without that include. Regardless of that,
    any change to h2 cause random_source to be rebuilt, albeit it
    shouldn't. Now, rince, repeat that situation on a bigg(ish) codebase,
    and watch your build times explode.

    Goran.
    Goran, Jan 14, 2011
    #12
  13. Ian Collins

    James Kanze Guest

    On Jan 13, 9:47 pm, Keith H Duggar <> wrote:
    > On Jan 13, 4:03 pm, Ian Collins <> wrote:
    > > On 01/14/11 09:25 AM, Keith H Duggar wrote:
    > > > On Jan 13, 3:11 pm, Ian Collins<> wrote:
    > > >> On 01/14/11 08:33 AM, Joe Hesse wrote:
    > > >>> When I write many X.h and X.cpp files and debug/modify
    > > >>> them, after a while they contain library or other header
    > > >>> files that may not be necessary. I realize that there
    > > >>> are #ifdef's that prevent a header file from being
    > > >>> included more than once so it doesn't hurt to put them
    > > >>> in more places than necessary.


    > > >>> My question is: Is there a tool to take a C++ program
    > > >>> that compiles and reorganize the header files so there
    > > >>> are no more #include<blah> than necessary?


    > > >> While it is possible, what real benefits would such a tool bring?


    > > > I would have thought it obvious that it can significantly
    > > > reduce compile times and especially eliminate dependency
    > > > triggers.


    > > Eliminate dependency triggers, yes but significantly reduce
    > > compile times? Include guards take care of most waste
    > > there.


    > Unfortunately they do not (unless you are talking about external
    > guards?). The reason is that due to the textual include mechanism
    > and C++ language rules, internal guards still require that the
    > entire contents of the header file and recursively on down must
    > be scanned and tokenized (but not parsed etc).


    No they don't. Any decent compiler will note that the included
    file had include guards, and not even open it when it is
    included a second time. This has been standard practice since
    the mid-1990's. (I'm pretty sure that g++ was the first to
    introduce it.)

    --
    James Kanze
    James Kanze, Jan 14, 2011
    #13
  14. Ian Collins

    James Kanze Guest

    On Jan 13, 11:03 pm, "Kevin P. Fleming" <> wrote:
    > On 01/13/2011 03:47 PM, Keith H Duggar wrote:


    [...]
    > > Unfortunately they do not (unless you are talking about external
    > > guards?). The reason is that due to the textual include mechanism
    > > and C++ language rules, internal guards still require that the
    > > entire contents of the header file and recursively on down must
    > > be scanned and tokenized (but not parsed etc).


    > Using "#pragma once" as the first line of the header file
    > solves this problem, and is supported in nearly every modern
    > version of GCC, Visual Studio and any compiler that uses MCPP
    > as its preprocessor.


    Gcc accepts "#pragma once" in order to be able to compile code
    written for VC++. (It's also "bug compatible" in a couple of
    places---only generating warnings, when it should generate
    errors.) Gcc doesn't need "#pragma once" to avoid rereading
    a header file twice.

    --
    James Kanze
    James Kanze, Jan 14, 2011
    #14
  15. James Kanze <> wrote:
    > Gcc accepts "#pragma once" in order to be able to compile code
    > written for VC++. (It's also "bug compatible" in a couple of
    > places---only generating warnings, when it should generate
    > errors.)


    Why would it generate any error on it?

    (And btw, gcc throwing warnings on #pragma lines is quite annoying,
    especially if you are using them for something useful, eg. with a
    different program which interprets them. Or even with gcc itself,
    if you are using OpenMP and want to compile a non-multithreaded
    version of the program, in which case the warnings are useless.)
    Juha Nieminen, Jan 14, 2011
    #15
  16. On Jan 14, 4:41 am, James Kanze <> wrote:
    > On Jan 13, 9:47 pm, Keith H Duggar <> wrote:
    > > On Jan 13, 4:03 pm, Ian Collins <> wrote:
    > > > On 01/14/11 09:25 AM, Keith H Duggar wrote:
    > > > > On Jan 13, 3:11 pm, Ian Collins<>  wrote:
    > > > >> On 01/14/11 08:33 AM, Joe Hesse wrote:
    > > > >>> When I write many X.h and X.cpp files and debug/modify
    > > > >>> them, after a while they contain library or other header
    > > > >>> files that may not be necessary.  I realize that there
    > > > >>> are #ifdef's that prevent a header file from being
    > > > >>> included more than once so it doesn't hurt to put them
    > > > >>> in more places than necessary.
    > > > >>> My question is:  Is there a tool to take a C++ program
    > > > >>> that compiles and reorganize the header files so there
    > > > >>> are no more #include<blah>    than necessary?
    > > > >> While it is possible, what real benefits would such a tool bring?
    > > > > I would have thought it obvious that it can significantly
    > > > > reduce compile times and especially eliminate dependency
    > > > > triggers.
    > > > Eliminate dependency triggers, yes but significantly reduce
    > > > compile times?  Include guards take care of most waste
    > > > there.

    > > Unfortunately they do not (unless you are talking about external
    > > guards?). The reason is that due to the textual include mechanism
    > > and C++ language rules, internal guards still require that the
    > > entire contents of the header file and recursively on down must
    > > be scanned and tokenized (but not parsed etc).

    >
    > No they don't. Any decent compiler will note that the included
    > file had include guards, and not even open it when it is
    > included a second time.  This has been standard practice since
    > the mid-1990's.  (I'm pretty sure that g++ was the first to
    > introduce it.)


    This above statement is simply false. I've come to realize that
    when many a Mr. X in this forum writes "any decent" it actually
    translates to "my fantasy".

    I am afraid the devil is in the details for this particular C++
    compilation aspect. When you actually start writing the compiler
    reality lays waste to your fantasies. If you would review the
    many many discussions /after/ the mid-1990's you would learn
    the many reasons why you are wrong and why the problems are only
    getting worse not better (as a result of changes in C++ usage as
    well as proposed language changes):

    Here is a recent article by Walter

    http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html

    giving a short but accurate synopsis.

    So (sadly for all of us C++ users) you are wrong; James' fantasy
    compiler does not exist; Walter is right.

    KHD
    Keith H Duggar, Jan 14, 2011
    #16
  17. On Jan 13, 6:03 pm, "Kevin P. Fleming" <> wrote:
    > On 01/13/2011 03:47 PM, Keith H Duggar wrote:
    > > On Jan 13, 4:03 pm, Ian Collins<>  wrote:
    > >> On 01/14/11 09:25 AM, Keith H Duggar wrote:
    > >>> On Jan 13, 3:11 pm, Ian Collins<>    wrote:
    > >>>> On 01/14/11 08:33 AM, Joe Hesse wrote:
    > >>>>> When I write many X.h and X.cpp files and debug/modify them, after a
    > >>>>> while they contain library or other header files that may not be
    > >>>>> necessary.  I realize that there are #ifdef's that prevent a header file
    > >>>>> from being included more than once so it doesn't hurt to put them in more
    > >>>>> places than necessary.

    >
    > >>>>> My question is:  Is there a tool to take a C++ program that compiles and
    > >>>>> reorganize the header files so there are no more #include<blah>      than
    > >>>>> necessary?

    >
    > >>>> While it is possible, what real benefits would such a tool bring?

    >
    > >>> I would have thought it obvious that it can significantly reduce
    > >>> compile times and especially eliminate dependency triggers.

    >
    > >> Eliminate dependency triggers, yes but significantly reduce compile
    > >> times?  Include guards take care of most waste there.

    >
    > > Unfortunately they do not (unless you are talking about external
    > > guards?). The reason is that due to the textual include mechanism
    > > and C++ language rules, internal guards still require that the
    > > entire contents of the header file and recursively on down must
    > > be scanned and tokenized (but not parsed etc).

    >
    > Using "#pragma once" as the first line of the header file solves this
    > problem, and is supported in nearly every modern version of GCC, Visual
    > Studio and any compiler that uses MCPP as its preprocessor.


    #pragma once

    1) is not a standard C++ feature

    2) is not even part of C++0x

    3) is it not portably implemented

    4) on those systems that support it, it can introduce subtle
    non-conformance pitfalls

    5) the complexity of 4) leads to confusion /even among
    compiler implementers/, one reason why gnu deprecated,
    then un-deprecated, then (now) deprecated the feature
    again ie flip-flop-flip

    6) you have control over whether 3rd part library try to
    use it

    In other words, practically speaking for standard C++ #pragma
    once is not viable.

    KHD
    Keith H Duggar, Jan 14, 2011
    #17
  18. On Jan 14, 11:52 am, Keith H Duggar <> wrote:
    > #pragma once
    > ...
    >    6) you have control over whether 3rd part library try to
    >       use it


    Obviously should have been "no control" to make a 3rd party
    library use it which might be substantial parts of your code.

    KHD
    Keith H Duggar, Jan 14, 2011
    #18
  19. Ian Collins

    James Kanze Guest

    On Jan 14, 3:45 pm, Juha Nieminen <> wrote:
    > James Kanze <> wrote:
    > > Gcc accepts "#pragma once" in order to be able to compile code
    > > written for VC++. (It's also "bug compatible" in a couple of
    > > places---only generating warnings, when it should generate
    > > errors.)


    > Why would it generate any error on it?


    Because it can? Who knows why g++ does anything; older (very,
    very much older) versions of g++ would start a game when they
    encountered a #pragma.

    > (And btw, gcc throwing warnings on #pragma lines is quite annoying,
    > especially if you are using them for something useful, eg. with a
    > different program which interprets them. Or even with gcc itself,
    > if you are using OpenMP and want to compile a non-multithreaded
    > version of the program, in which case the warnings are useless.)


    You see. They're warnings, and not errors, but the principle is
    still there. (To tell the truth, it's an awkward issue. If
    a compiler supports pragma's, and you've a typo in one of its
    pragma's, so that the pragma isn't recognized, you do want to
    know about it.)

    --
    James Kanze
    James Kanze, Jan 14, 2011
    #19
  20. Ian Collins

    James Kanze Guest

    On Jan 14, 4:40 pm, Keith H Duggar <> wrote:
    > On Jan 14, 4:41 am, James Kanze <> wrote:


    >
    >
    > > On Jan 13, 9:47 pm, Keith H Duggar <> wrote:
    > > > On Jan 13, 4:03 pm, Ian Collins <> wrote:
    > > > > On 01/14/11 09:25 AM, Keith H Duggar wrote:
    > > > > > On Jan 13, 3:11 pm, Ian Collins<> wrote:
    > > > > >> On 01/14/11 08:33 AM, Joe Hesse wrote:
    > > > > >>> When I write many X.h and X.cpp files and debug/modify
    > > > > >>> them, after a while they contain library or other header
    > > > > >>> files that may not be necessary. I realize that there
    > > > > >>> are #ifdef's that prevent a header file from being
    > > > > >>> included more than once so it doesn't hurt to put them
    > > > > >>> in more places than necessary.
    > > > > >>> My question is: Is there a tool to take a C++ program
    > > > > >>> that compiles and reorganize the header files so there
    > > > > >>> are no more #include<blah> than necessary?
    > > > > >> While it is possible, what real benefits would such a tool bring?
    > > > > > I would have thought it obvious that it can significantly
    > > > > > reduce compile times and especially eliminate dependency
    > > > > > triggers.
    > > > > Eliminate dependency triggers, yes but significantly reduce
    > > > > compile times? Include guards take care of most waste
    > > > > there.
    > > > Unfortunately they do not (unless you are talking about external
    > > > guards?). The reason is that due to the textual include mechanism
    > > > and C++ language rules, internal guards still require that the
    > > > entire contents of the header file and recursively on down must
    > > > be scanned and tokenized (but not parsed etc).


    > > No they don't. Any decent compiler will note that the included
    > > file had include guards, and not even open it when it is
    > > included a second time. This has been standard practice since
    > > the mid-1990's. (I'm pretty sure that g++ was the first to
    > > introduce it.)


    > This above statement is simply false. I've come to realize that
    > when many a Mr. X in this forum writes "any decent" it actually
    > translates to "my fantasy".


    My "any decent compiler" is admittedly a figure of speak. Most
    compilers would be quite accurate, however.

    > I am afraid the devil is in the details for this particular C++
    > compilation aspect.


    Agreed. Defining what is the same file is not trivial, and to
    be frank, I don't know exactly what definition g++ (for example)
    uses. But the example problematic cases don't generally show up
    in actual practice.

    > When you actually start writing the compiler
    > reality lays waste to your fantasies. If you would review the
    > many many discussions /after/ the mid-1990's you would learn
    > the many reasons why you are wrong and why the problems are only
    > getting worse not better (as a result of changes in C++ usage as
    > well as proposed language changes):


    > Here is a recent article by Walter


    > http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html


    > giving a short but accurate synopsis.


    A not very accurate synopsis. G++ (and if I can trust my
    measurements, Sun CC as well) don't reopen an include file
    protected by include guards more than once, regardless of how
    many times it has been included.

    > So (sadly for all of us C++ users) you are wrong; James' fantasy
    > compiler does not exist; Walter is right.


    My "fantasy" compiler is called g++. The source code is
    available, so you can even see how it does it.

    --
    James Kanze
    James Kanze, Jan 14, 2011
    #20
    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. Newsgroup - Ann
    Replies:
    4
    Views:
    681
    lilburne
    Nov 2, 2003
  2. Bit byte
    Replies:
    1
    Views:
    633
    benben
    Apr 19, 2006
  3. Skybuck Flying
    Replies:
    16
    Views:
    643
    tragomaskhalos
    Aug 25, 2007
  4. mlt
    Replies:
    2
    Views:
    804
    Jean-Marc Bourguet
    Jan 31, 2009
  5. Martin DeMello

    anyone using clutter?

    Martin DeMello, Jun 10, 2008, in forum: Ruby
    Replies:
    2
    Views:
    93
    Daniel Brumbaugh Keeney
    Jun 13, 2008
Loading...

Share This Page