Re: meaning of static within a namespace?
From: Anthony Borla (ajborla_at_bigpond.com)
Date: 03/27/05
- Next message: Alf P. Steinbach: "Re: Pointer question."
- Previous message: Anthony Borla: "Re: Pointer question."
- In reply to: Mark P: "Re: meaning of static within a namespace?"
- Next in thread: Bart van Ingen Schenau: "Re: meaning of static within a namespace?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 26 Mar 2005 23:58:30 GMT
"Mark P" <not@my.real.email> wrote in message
news:%9i1e.15743$C47.11311@newssvr14.news.prodigy.com...
> Anthony Borla wrote:
> > "Mark P" <not@my.real.email> wrote in message
> > news:Lw91e.2834$zl.2813@newssvr13.news.prodigy.com...
> >
> >>Anthony Borla wrote:
> >>
> >>>"Mark P" <not@my.real.email> wrote in message
> >>>news:PJ01e.1644$FN4.200@newssvr21.news.prodigy.com...
> >
> > <SNIP>
> >
> >>So suppose I declare and define a function in a header file:
> >>
> >>static void a() { /* do something */}
> >>
> >>and then include that header file in multiple .cpp files.
> >>
>
> Thanks, that's helpful. And it explains why my compiler
> complained (well, warned, with -Wall) about a fcn
> "defined but not used" when I had it declared static,
> defined in a header file included by several .cpp
> files, but only used in one of those .cpp files.
>
> As for your example below, I'm without access to a compiler
> for a couple days but let me try to guess what will happen
> based on my meager understanding of all this.
>
> <guess>
>
> When amain.cpp is compiled, the call to b() is unresolved
> because b() is declared but not defined in that trans. unit.
> The call to a() would be illegal because a() is declared static
> and not defined.
>
Yes.
>
> When a1.cpp and a2.cpp are compiled, each gets a separate
> a() fcn which, being static and defined, can be fully resolved.
> (Is __FILE__ a preprocessor directive to obtain a string of the
> filename?)
>
Yes to __FILE__, and to the separate versions of 'a'.
>
> Then since each defines b(), those can be resolved too, and each
> will compile b() to call its corresponding version of a().
>
Yes.
>
> Then the object files are linked and the linker must figure
> out what amain.cpp means when it calls b(). I'm assuming
> by your posting it that this code will link without error, so
> that the order of linkage determines which of the two different
> compilations of b() will be used by amain. So the two
> executions will print different filenames?
> </guess>
>
Actually, only one of the versions will be linked in - the first in the
list - because only one version of 'b' is allowed to be linked in. You
should be able to change your linker settings to get a warning / error if an
attempt to link two versions together is made.
>
> Somehow it seems like this ought to violate the ODR,
> or is it that such a perverse case is too difficult for the
> linker to efficiently detect in general so it can only verify
> that the definitions of b() are identical
> within the .cpp files?
>
The linker is a general purpose tool, one that only knows about object
modules and the symbols it contains. At this level, whether the module(s)
were created with C, C++, Pascal, or Oberon, is largely irrelevant. Thus,
linkage issues AFAIK are beyond the language, and are platform /
tool-specific.
>
> Also, is there any particular significance to your choice of
> C rather than C++ output, viz. <stdio.h> and printf?
>
No, no significance. Th past couple of examples I posted used 'printf', so I
just used it here :) !
>
> Thanks for your help,
> Mark
>
No worries :) !
Cheers,
Anthony Borla
- Next message: Alf P. Steinbach: "Re: Pointer question."
- Previous message: Anthony Borla: "Re: Pointer question."
- In reply to: Mark P: "Re: meaning of static within a namespace?"
- Next in thread: Bart van Ingen Schenau: "Re: meaning of static within a namespace?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
