frege wrote:
> kanze wrote:
>> James Dennett wrote:
>>
>>     [...]
>>> If only the *value* of Arb::i is needed, there is no need
>>> for a definition.
>>
>> In practice, that's true, but the current version of the
>> standard clearly states that it is undefined behavior if the
>> definition is absent.  (See paragraphs 2 and 3 of =A73.2.)  There
>> is a proposal, accepted (and presumably already integrated into
>> the latest working draft) to not require the definition IF the
>> only uses are an immediate lvalue to rvalue conversion, but
>> until the next version of the standard is published, it remains
>> officially undefined behavior.
>>
>>> If its identity is needed, then you do need the definition.
>>> (I'm unsure how *clear* the standard is in this respect, but
>>> that's the intention.)
>>
>> I don't think that that was even the intention in the 1998
>> standard.  At any rate, that version of the standard is clear on
>> this subject, but not in the way you seem to think.
>>
>> As a general rule, as a class author, you don't know whether
>> anyone will take the address or not.  They may take it
>> indirectly, e.g. by passing the value to a function which takes
>> a const reference (something like v.push_back(x), where v is an
>> std::vector< type_of_x >).  Thus, as a class author, I consider
>> it an error in my code not to provide the definition.  And will
>> continue to do so even when the new version of the standard is
>> approved.
>>
>
>
> Would it really be the hard for the compiler to ALWAYS generate a
> definition of the member.  It knows everything except which cpp file
> to put it in - but guess, what? I don't care which cpp file it goes
> in. Just reserve some memory for me.  Leave a note for the linker to
> make sure there is only one, etc.

It's a Buridan's Ass problem.  If there is no difference in which of
the translation units to put the definition, one cannot arrive at
a conclusion based on logic, and the compiler is based on logic, AFAIK.

> For the cases where you really don't want to take the hit of those 4
> bytes, use the new typed-enum thing (assuming it works out).

What's wrong with how the rules are set now?  If you need the object
itself (using it as lvalue), *you* need to define it.  Otherwise you
don't need to.

In any case, compilers are based on rules prescribed in the Standard.
To allow the compiler to generate the definition would be breaking the
rule that the *program* must have a definition.  Changing that rule
would require changing the Standard, and it's just easier to change
it to *not* require the definition (if the object is not used), which
it will when the next edition comes out, AFAIU.

V
--=20
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask=20


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Moderator posted:

> C++ Standard, section 9.4.2 "Static data members", paragraphs 2 and 4.


I was of the impression that you could "define" the const static member
within the class definition, without need for another definition of the
member outside. Alas I was wrong. The correct way to do it seems to be:

/* Header File */

struct Arb {

    int const static i = 5;
};


/* Corresponding Source File */

int const Arb::i;


--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> Moderator posted:
>
>> C++ Standard, section 9.4.2 "Static data members", paragraphs 2 and 4.
>
>
> I was of the impression that you could "define" the const static member
> within the class definition, without need for another definition of the
> member outside. Alas I was wrong. The correct way to do it seems to be:
>
> /* Header File */
>
> struct Arb {
>
>     int const static i = 5;
> };
>
>
> /* Corresponding Source File */
>
> int const Arb::i;

If only the *value* of Arb::i is needed, there is no need
for a definition.  If its identity is needed, then you do
need the definition.  (I'm unsure how *clear* the standard
is in this respect, but that's the intention.)

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

James Dennett wrote:

    [...]
> If only the *value* of Arb::i is needed, there is no need
> for a definition.

In practice, that's true, but the current version of the
standard clearly states that it is undefined behavior if the
definition is absent.  (See paragraphs 2 and 3 of    3.2.)  There
is a proposal, accepted (and presumably already integrated into
the latest working draft) to not require the definition IF the
only uses are an immediate lvalue to rvalue conversion, but
until the next version of the standard is published, it remains
officially undefined behavior.

> If its identity is needed, then you do need the definition.
> (I'm unsure how *clear* the standard is in this respect, but
> that's the intention.)

I don't think that that was even the intention in the 1998
standard.  At any rate, that version of the standard is clear on
this subject, but not in the way you seem to think.

As a general rule, as a class author, you don't know whether
anyone will take the address or not.  They may take it
indirectly, e.g. by passing the value to a function which takes
a const reference (something like v.push_back(x), where v is an
std::vector< type_of_x >).  Thus, as a class author, I consider
it an error in my code not to provide the definition.  And will
continue to do so even when the new version of the standard is
approved.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota wrote:
> On Tue, 18 Jul 2006 10:27:44 CST, "kanze" <kanze@gabi-soft.fr> wrote:

> >I think that's actually implementation defined.  Normally, where
> >the compiler is putting it is where you put the
> >definition---initialization or not, the declaration in the class
> >is only a declaration, not a definition.  And if you don't
> >provide a definition, it is undefined behavior.

> You might appreciate this:

>  <http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#454>

I don't see where it changes anything, except maybe allowing
errors to go undetected longer (which IMHO is not a good thing).
If you are the author of a class, you don't know whether a user
will take the address of your static member or not, so not
providing the definition is an error.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> Neo posted:
>
> > In early compilers(I have VC 6.0) it does not work but it works with
> > VC7.0.
>
>
> Microsoft get it wrong. Regularly.

Well yes of course.  So does every other compiler vendor.  Compilers
are non-trivial programs, so they have bugs.

Furthermore, compilers are implemented incrementally with the most
important features first.  VC6 is ancient history; I *think* it
predates the formal ratification of the standard, and it was certainly
hampered by a legal dispute which prevented the standard library which
shipped with VC6 being any better than that with VC5 (although that
doesn't affect this particular issue).

> They're too busy dumbing down their operating system with each progressive
> release to consider how C++ should be implemented.

Err, how do you explain the fact that VC7.0 was much more conformant
that VC6.5, VC7.1 was significantly better again, and VC8.0 is better
still.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> "Victor Bazarov" posted:

> >> int main()
> >> {
> >>    int const *p = &ABC::var;  /* Compile ERROR */

> > No, this would be a _linking_ error because ABC::var has not been
> > _defined_ anywhere.

> If ABC::var were not defined anywhere, then would the
> following not fail to compile?

> struct ABC {
>     int const static var = 10;
> };

> int main()
> {
>     int const i = ABC::var;
> }

Both are undefined behavior.  A compiler is not required to
compile either, but may compile both.  A compiler may also
compile either into code which reformats your hard disk.

Gennaro Prota has pointed out that the current draft of the
standard has been modified so that a compiler is required to
compile (and link) the code if the variable is immediately
converted to an rvalue.  But this is not yet part of the
official standard.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Wed, 19 Jul 2006 09:52:32 CST, "kanze" <kanze@gabi-soft.fr> wrote:

>Gennaro Prota wrote:
>
>> You might appreciate this:
>
>>  <http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#454>
>
>I don't see where it changes anything, except maybe allowing
>errors to go undetected longer (which IMHO is not a good thing).

Well, I said "you *might*" :-) Admittedly when I wrote the DR I had
primarily in mind that, in as much can be inferred from the remarks
about core issue 48, the committee had already agreed that a
definition was not required (for brevity's sake I'll not repeat the
circumstances under which that holds).

>If you are the author of a class, you don't know whether a user
>will take the address of your static member or not, so not
>providing the definition is an error.

The only solution I see to this is N1579. If we think about it, data
members having const integral or const enumeration type are "a
curiously half-baked concept" ;-)

PS: James, I've repeatedly tried to contact you a few (three?) weeks
ago, but your mail address above doesn't seem to work. Well, you know
mine ;-)

--
Gennaro Prota

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kanze wrote:
> James Dennett wrote:
>=20
>     [...]
>> If only the *value* of Arb::i is needed, there is no need
>> for a definition.
>=20
> In practice, that's true, but the current version of the
> standard clearly states that it is undefined behavior if the
> definition is absent.  (See paragraphs 2 and 3 of =A73.2.)  There
> is a proposal, accepted (and presumably already integrated into
> the latest working draft) to not require the definition IF the
> only uses are an immediate lvalue to rvalue conversion, but
> until the next version of the standard is published, it remains
> officially undefined behavior.
>=20
>> If its identity is needed, then you do need the definition.
>> (I'm unsure how *clear* the standard is in this respect, but
>> that's the intention.)
>=20
> I don't think that that was even the intention in the 1998
> standard.  At any rate, that version of the standard is clear on
> this subject, but not in the way you seem to think.

There are other lacks of clarity in the 1998 standard on
this area, in terms of what constitutes the "use" of such
a static data member.  (We can apply the normal English
use of the term, but it's not entirely clear if that's
appropriate.)

In any case:
(1) As you noted, in practice it's safe to assume that
the resolution of issue 454 applies to current compilers,
so that the definition is not necessary if the member
is used for its value
(2) The 1998 standard doesn't make clear such a guarantee,
(3) C++0x almost certainly will make such a guarantee, but
(4) Providing a definition isn't an error, and allows for
slightly more flexible use of the static data member.

-- James

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kanze posted:

> James Dennett wrote:
>
>     [...]
>> If only the *value* of Arb::i is needed, there is no need
>> for a definition.
>
> In practice, that's true, but the current version of the
> standard clearly states that it is undefined behavior if the
> definition is absent.  (See paragraphs 2 and 3 of    3.2.)  There
> is a proposal, accepted (and presumably already integrated into
> the latest working draft) to not require the definition IF the
> only uses are an immediate lvalue to rvalue conversion, but
> until the next version of the standard is published, it remains
> officially undefined behavior.


I think it would be great if:

   (1) If you don't provide a definition of the const static member outside
of the class, then:

        (1.a) You can only use it as an R-value.


--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> [..]
> I think it would be great if:
>
>   (1) If you don't provide a definition of the const static member
> outside of the class, then:
>
>        (1.a) You can only use it as an R-value.

I think it's already in the proposal.  There is no need to define it
if you don't use it as an lvalue.  What you wrote here is the inverse
of that, AFAICT.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Wed, 19 Jul 2006 10:07:21 CST, "kanze" <kanze@gabi-soft.fr> wrote:

>Gennaro Prota has pointed out that the current draft of the
>standard has been modified so that a compiler is required to
>compile (and link) the code if the variable is immediately
>converted to an rvalue.  But this is not yet part of the
>official standard.

It's not in the working draft yet, at least not in the latest publicly
available one (which I think _is_ the latest, in this case). I guess
the final decision also depends on what will be done with strongly
typed enums. If the latter will be accepted they will be a great way
to obtain "true" compile-time constants without lvalueness
complications and in that case it's probably not worth changing the
rules about static const data members. Just my opinion, though.

--
Gennaro Prota

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

kanze wrote:
> James Dennett wrote:
>
>     [...]
> > If only the *value* of Arb::i is needed, there is no need
> > for a definition.
>
> In practice, that's true, but the current version of the
> standard clearly states that it is undefined behavior if the
> definition is absent.  (See paragraphs 2 and 3 of    3.2.)  There
> is a proposal, accepted (and presumably already integrated into
> the latest working draft) to not require the definition IF the
> only uses are an immediate lvalue to rvalue conversion, but
> until the next version of the standard is published, it remains
> officially undefined behavior.
>
> > If its identity is needed, then you do need the definition.
> > (I'm unsure how *clear* the standard is in this respect, but
> > that's the intention.)
>
> I don't think that that was even the intention in the 1998
> standard.  At any rate, that version of the standard is clear on
> this subject, but not in the way you seem to think.
>
> As a general rule, as a class author, you don't know whether
> anyone will take the address or not.  They may take it
> indirectly, e.g. by passing the value to a function which takes
> a const reference (something like v.push_back(x), where v is an
> std::vector< type_of_x >).  Thus, as a class author, I consider
> it an error in my code not to provide the definition.  And will
> continue to do so even when the new version of the standard is
> approved.
>


Would it really be the hard for the compiler to ALWAYS generate a
definition of the member.  It knows everything except which cpp file to
put it in - but guess, what? I don't care which cpp file it goes in.
Just reserve some memory for me.  Leave a note for the linker to make
sure there is only one, etc.

For the cases where you really don't want to take the hit of those 4
bytes, use the new typed-enum thing (assuming it works out).

Tony


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Neo wrote:
> hie Guys,
>
> I have a class like
>
> class ABC
> {
> public:
> static const int var=10;
> };
>
> Here initialing the var with 10 is allowed inside class.
>
> In early compilers(I have VC 6.0) it does not work but it works with
> VC7.0.
>
> Rule says that only static integral constants are allowed to be
> initialized inside class.
>
> May I know why this requirement came when we already have following
> facility as shown belows
>
> class ABC
> {
> public:
> static const int var;
>
> };
>
> const int ABC:: var =10;

Because we want to be able to do

   class ABC
   {
       static const int array_size = 42;
       ...
       int my_int_array[array_size];
       std::string my_strings[array_size];
   };

and it would be rather difficult to use a "real" value that is only
defined elsewhere in the program, in a different TU, wouldn't it?

> Also My question is where is the compiler putting this code - static
> const int var=10 when it is inside a class?

Nowhere.  Unless you try taking the address of that variable, it does
not even occupy any memory.  It's a _compile-time_constant_.

> It can not be in constructor or in memberwise Initialization list.So
> what is workaround? Why this is special case?

Because it's easier than using an enum for the same sizing purpose.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Neo posted:

> In early compilers(I have VC 6.0) it does not work but it works with
> VC7.0.


Microsoft get it wrong. Regularly.

They're too busy dumbing down their operating system with each progressive
release to consider how C++ should be implemented.


> Also My question is where is the compiler putting this code - static
> const int var=10 when it is inside a class?


There *is* no code.

Wherever the compiler sees something like:

    int i = ABC::var;

It treats it as if it were:

    int i = 10;


Furthermore, (and quite appropriatly if you ask me), a const static object
which is initialised within the class definition body is an R-value, so you
can't take its address:

struct ABC {
    int const static var = 10;
};

int main()
{
    int const *p = &ABC::var;  /* Compile ERROR */
}


It's almost indentical to writing:


struct ABC {
    enum { var = 10 };
};


--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Victor Bazarov" wrote:
> Neo wrote:

> > I have a class like

> > class ABC
> > {
> > public:
> > static const int var=10;
> > };

> > Here initialing the var with 10 is allowed inside class.

> > In early compilers(I have VC 6.0) it does not work but it
> > works with VC7.0.

> > Rule says that only static integral constants are allowed to
> > be initialized inside class.

> > May I know why this requirement came when we already have
> > following facility as shown belows

> > class ABC
> > {
> > public:
> > static const int var;
> > };

> > const int ABC:: var =10;

> Because we want to be able to do

>    class ABC
>    {
>        static const int array_size = 42;
>        ...
>        int my_int_array[array_size];
>        std::string my_strings[array_size];
>    };

> and it would be rather difficult to use a "real" value that is
> only defined elsewhere in the program, in a different TU,
> wouldn't it?

In technical terms, we want to be able to use it in integral
constant expressions in any translation unit which includes the
class definition (and in fact, any time the declaration is
visible).

> > Also My question is where is the compiler putting this code
> > - static const int var=10 when it is inside a class?

> Nowhere.  Unless you try taking the address of that variable,
> it does not even occupy any memory.  It's a
> _compile-time_constant_.

I think that's actually implementation defined.  Normally, where
the compiler is putting it is where you put the
definition---initialization or not, the declaration in the class
is only a declaration, not a definition.  And if you don't
provide a definition, it is undefined behavior.

> > It can not be in constructor or in memberwise Initialization
> > list.So what is workaround? Why this is special case?

> Because it's easier than using an enum for the same sizing
> purpose.

Easier, I don't know.  Clearer, and more coherent with regards
to type, in any case.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> [...]
> Furthermore, (and quite appropriatly if you ask me), a const static
> object which is initialised within the class definition body is an
> R-value, so you can't take its address:

That's not true.

> struct ABC {
>    int const static var = 10;
> };
>
> int main()
> {
>    int const *p = &ABC::var;  /* Compile ERROR */

No, this would be a _linking_ error because ABC::var has not been
_defined_ anywhere.

> }
>
>
> It's almost indentical to writing:
>
>
> struct ABC {
>    enum { var = 10 };
> };

"Almost" is the key word.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Victor Bazarov" posted:

>> int main()
>> {
>>    int const *p = &ABC::var;  /* Compile ERROR */
>
> No, this would be a _linking_ error because ABC::var has not been
> _defined_ anywhere.


If ABC::var were not defined anywhere, then would the following not fail to
compile?

struct ABC {
    int const static var = 10;
};

int main()
{
    int const i = ABC::var;
}



--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> "Victor Bazarov" posted:
>
>>> int main()
>>> {
>>>    int const *p = &ABC::var;  /* Compile ERROR */
>>
>> No, this would be a _linking_ error because ABC::var has not been
>> _defined_ anywhere.
>
>
> If ABC::var were not defined anywhere, then would the following not
> fail to compile?
>
> struct ABC {
>    int const static var = 10;
> };
>
> int main()
> {
>    int const i = ABC::var;
> }

Implementation-defined, as soon as we start separating "compilation"
and "linking".  For all we know, 'ABC::var' can be defined in some
other TU, and then the resulting program is created from two TU, which
are compiled (translated) separately.  In that case the following will
_not_ fail to compile.   Just try it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Tue, 18 Jul 2006 10:27:44 CST, "kanze" <kanze@gabi-soft.fr> wrote:

>I think that's actually implementation defined.  Normally, where
>the compiler is putting it is where you put the
>definition---initialization or not, the declaration in the class
>is only a declaration, not a definition.  And if you don't
>provide a definition, it is undefined behavior.

You might appreciate this:

 <http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#454>

--
Gennaro Prota

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

===================================== MODERATOR'S COMMENT:

C++ Standard, section 9.4.2 "Static data members", paragraphs 2 and 4.


===================================== END OF MODERATOR'S COMMENT
Victor Bazarov posted:

>> If ABC::var were not defined anywhere, then would the following not
>> fail to compile?
>>
>> struct ABC {
>>    int const static var = 10;
>> };
>>
>> int main()
>> {
>>    int const i = ABC::var;
>> }
>
> Implementation-defined, as soon as we start separating "compilation"
> and "linking".  For all we know, 'ABC::var' can be defined in some
> other TU, and then the resulting program is created from two TU, which
> are compiled (translated) separately.  In that case the following will
> _not_ fail to compile.   Just try it.


When you initialise a const static member within the class definition, does
it not constitute a definition?

Here's a complete program consisting of two translation units. It doesn't
compile for me with g++.


G++: other_file.cpp duplicate initialization of ABC::var


/* header.hpp */

#ifndef INCLUDE_HEADER_HPP
#define INCLUDE_HEADER_HPP

struct ABC {
    int const static var = 10;
};

#endif


/* main.cpp */

#include "header.hpp"

int main()
{
    int i = ABC::var;
}


/* other_file.cpp */

#include "header.hpp"

int const ABC::var = 10;



--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

hie Guys,

I have a class like

class ABC
{
public:
static const int var=10;
};

Here initialing the var with 10 is allowed inside class.

In early compilers(I have VC 6.0) it does not work but it works with
VC7.0.

Rule says that only static integral constants are allowed to be
initialized inside class.

May I know why this requirement came when we already have following
facility as shown belows

class ABC
{
public:
static const int var;

};

const int ABC:: var =10;


Also My question is where is the compiler putting this code - static
const int var=10 when it is inside a class?
It can not be in constructor or in memberwise Initialization list.So
what is workaround? Why this is special case?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]