[prog] C++ strange linking behaviour

[Riccarda Cassini]

On Mon, Nov 08, 2004 at 05:19:03PM -0600, Kathryn Hogg wrote:
> Meredith L. Patterson said:
> > then you can be assured that you won't define methods multiple times; if
> >   somewhere in the compilation chain it turns out you have "someclass.h"
> > included more than once, the first time it'll define the macro
> > _SOMECLASS_H (which never expands into anything; you can safely think of
> > it as a boolean value) and include the header, then the second time the
> > preprocessor will see that _SOMECLASS_H has been defined, it'll skip
> > down to the #endif, and you're safe. :)
> 
> I usually recommend that people use some kind organization prefix on their
> gaurd macros.  On large projects.  I have seen cases where some external
> code uses the same guard macros  which can break things if I end up
> including both of them.
> 
> So, I'd use #ifndef KJH_SOMECLASS_H if my company/project was named KJH


I always wondered why this is necessary at all - can't the compiler
just silently ignore "redeclarations" as long as they're identical?
Why does a tool, that otherwise is perfectly able to build up so
complex data structures that people even recommend it for RAM testing,
force the programmer to issue such cumbersome and, IMHO, unnecessary
boilerplate in each and every header file?

Why not just do something like (expressed in perl pseudocode, for
brevity):

  if (!exists $decl{$symbol} ) {
  
    $decl{$symbol} = $declaration;
    # set up the declaration, the first time it is encountered

  } elsif ($declaration ne $decl{$symbol} ) {

    # issue warning/error

  } else {

    # identical redeclaration encountered - just shut up here...

  }
  
This logic doesn't seem too complex to me... :-)
So, is there any reason other than "it's always been that way"?

Riccarda

(waiting to be told that she's overlooking something fundamental ;-)