In article <smeyersCxnD72.EHG@netcom.com> smeyers@netcom.com (Scott Meyers) writes:
>
>We all know the One Definiton Rule has been a myth for a while, but
>this seems to really bring it out in the open.

 The myth is about to become a reality, with any luck.
At Valley Forge in a few days, Josee Lajoie's core subgroup
is scheduled to discuss the One Definition Rule. There is
a specific, and reasonably precise proposal. (Which I wrote
with considerable assistance) Previous resolutions on linkage
have set the scene.

 The proposal contains a set of mechnically checkable
rules for measuring whether two expressions or function
definitions are equivalent: a program is in error if
any of these requiremets is breached when equivalence is
required, although in most cases a compiler is not required to diagnose
an error.

 FYI the first rule says that the sequence of
tokens in two definitions or expressions must be the same
for them to be equivalent. The second rule says the first
rule is applied recursively to the definition of any
entity with internal linkage referred to by one of
these tokens. (Additional rules attempt to provide
a sufficiently wide set of functions to encompass
reasonble use, including such common idioms as
refering to constants and inline functions,
while at the same time guarranteeing functional equivalence).

 An alternative rule may be adopted: just require
functional equivalence and be done with it. The advantage
of this rule is that it is the largest possible set required for
coherent program behaviour, and is easy to specify,
the disadvantage is that it is provably impossible to
mechanically check for functional equivalence.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

I see from the June C++ Report (I'm a little behind, sorry -- it's
been a hell of a summer) that in March the ANSI/ISO committee blessed
initializing class static ints with constant expressions:

  class X {
    static int n = 42;   // now legal
    ...
  };

We all know the One Definiton Rule has been a myth for a while, but
this seems to really bring it out in the open.  What does the
(emerging) standard have to say about the location of X::n's
definition?  Which translation unit (given that the definition for X
is likely to be in a .h file) contains it?  Where in that transation
unit is X::n defined?

If this is an old question, perhaps some kind-hearted soul can mail me
the answers.

Thanks,

Scott

>>>>> Scott Meyers <smeyers@netcom.com> writes:

> I see from the June C++ Report (I'm a little behind, sorry -- it's
> been a hell of a summer) that in March the ANSI/ISO committee blessed
> initializing class static ints with constant expressions:

>   class X {
>     static int n = 42;   // now legal
>     ...
>   };

> We all know the One Definiton Rule has been a myth for a while, but
> this seems to really bring it out in the open.  What does the
> (emerging) standard have to say about the location of X::n's
> definition?  Which translation unit (given that the definition for X
> is likely to be in a .h file) contains it?  Where in that transation
> unit is X::n defined?

The declaration above is just a declaration, not a definition -- the
variable still needs to be defined somewhere, with

int X::n;

Jason

In article <JASON.94Oct14012338@phydeaux.cygnus.com> jason@cygnus.com
(Jason Merrill) writes:

|> >>>>> Scott Meyers <smeyers@netcom.com> writes:

|> > I see from the June C++ Report (I'm a little behind, sorry -- it's
|> > been a hell of a summer) that in March the ANSI/ISO committee blessed
|> > initializing class static ints with constant expressions:

|> >   class X {
|> >     static int n = 42;   // now legal
|> >     ...
|> >   };

|> > We all know the One Definiton Rule has been a myth for a while, but
|> > this seems to really bring it out in the open.  What does the
|> > (emerging) standard have to say about the location of X::n's
|> > definition?  Which translation unit (given that the definition for X
|> > is likely to be in a .h file) contains it?  Where in that transation
|> > unit is X::n defined?

|> The declaration above is just a declaration, not a definition -- the
|> variable still needs to be defined somewhere, with

|> int X::n;

And all of the initializations seen in the different translation units
must be identical, or unknown behavior results.

The purpose of this rule is simply to allow things like:
 int a[ X::n ] ;
in any module which knows about X.
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <smeyersCxnD72.EHG@netcom.com>,
Scott Meyers <smeyers@netcom.com> wrote:
>I see from the June C++ Report (I'm a little behind, sorry -- it's
>been a hell of a summer) that in March the ANSI/ISO committee blessed
>initializing class static ints with constant expressions:
>
>  class X {
>    static int n = 42;   // now legal
>    ...
>  };
>
>We all know the One Definiton Rule has been a myth for a while, but
>this seems to really bring it out in the open.  What does the
>(emerging) standard have to say about the location of X::n's
>definition?  Which translation unit (given that the definition for X
>is likely to be in a .h file) contains it?  Where in that transation
>unit is X::n defined?
>
>If this is an old question, perhaps some kind-hearted soul can mail me
>the answers.
>
>Thanks,
>
>Scott
>

 It must still be defined in some translation unit. It cannot be
initialized there if it has been initialized in the class definition.
   -- Pete