"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:905ukmEL2up8Ewlt@robinton.ntlworld.com...

> >And the definition of when an expression is potentially evaluated has
been
> >updated to exclude contexts calling for an integral constant expression.
See
> >http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#201.
> >
>
> 201 is about Order of destruction of temporaries and does not seem to
> have anything to do with the issue being discussed here

Fransis, thank you very much for the correction! The correct one is #48:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#48 and it is
this one that I was referring to in my previous posting!


Sicnerely,

Andrei Iltchenko.










---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <fl4riz88ul.fsf@jambon.cmla.ens-cachan.fr>, Gabriel Dos Reis
<dosreis@cmla.ens-cachan.fr> wrote:

> "Ruslan Abdikeev" <ruslan_abdikeevREMOVE_IT@hotmail.com> writes:
>
> [...]
>
> | Is it a Boost's fault, or it is my misunderstanding of standard?
>
> In that regard, Boost isn't following the standard letter.
>
> There have been (feature) requests to relax that standard requirement,
> so I think Boost is trying to make an existing practice in order to
> get a feature in the next revision of C++ :-) (After all, it is one of
> its objectives)
>
> There are rumors that the next standard would try to make rules more
> uniform; I think that the above mentionned rule relaxing is going in
> the opposite direction as it is special-casing some kinds of static
> data members.

The uniformity is in the handing of "usage".  The "use" of a declaration
as a compile-time constant is different than the "use" of the object.

When the only "use" is as a compile-time constant it is unreasonable to
require that the object actually exist since there is no "use" of the object
itself.

Most of the rules which distinguish between the "use" of the declaration
attributes and the "use" of the object itself are already in place, e.g.
for "sizeof" and "typeid".  The same distinction should be made for uses
of static const data members as compile-time constants.

-- Bill Gibbons

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hello,

In 9.4.2/4, C++ standard explicitly requires to have a namespace
scope definition of used static const data member of integral type,
even if it has a constant-initializer.

That is,

  struct A
  {
     static const int x = 7;
  };

requires to have somewhere

  const int A::x;

if value of A::x is used.

However, Boost (www.boost.org) does not follow this practice.
For C++ implementations that support constant-initializers
it declares static const data members with const-initializers
(but does never define it).
Otherwise, it uses "enum" workaround.

Boost is a high-quality library which is overparticular to
standard compliance and non-standard extensions,
so I was very surprised to spot this issue.

Is it a Boost's fault, or it is my misunderstanding of standard?

Sincerely,
Ruslan Abdikeev
VR-1 Entertainment Corp.
http://www.vr1.com/



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Ruslan Abdikeev" <ruslan_abdikeevREMOVE_IT@hotmail.com> writes:

[...]

| Is it a Boost's fault, or it is my misunderstanding of standard?

In that regard, Boost isn't following the standard letter.

There have been (feature) requests to relax that standard requirement,
so I think Boost is trying to make an existing practice in order to
get a feature in the next revision of C++ :-) (After all, it is one of
its objectives)

There are rumors that the next standard would try to make rules more
uniform; I think that the above mentionned rule relaxing is going in
the opposite direction as it is special-casing some kinds of static
data members.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Ruslan Abdikeev" <ruslan_abdikeevREMOVE_IT@hotmail.com> wrote in message
news:a7uta0$6vs$1@news.wplus.spb.ru...

> In 9.4.2/4, C++ standard explicitly requires to have a namespace
> scope definition of used static const data member of integral type,
> even if it has a constant-initializer.
>
> That is,
>
>   struct A
>   {
>      static const int x = 7;
>   };
>
> requires to have somewhere
>
>   const int A::x;
>
> if value of A::x is used.
>
> However, Boost (www.boost.org) does not follow this practice.
> For C++ implementations that support constant-initializers
> it declares static const data members with const-initializers
> (but does never define it).
> Otherwise, it uses "enum" workaround.
>
> Boost is a high-quality library which is overparticular to
> standard compliance and non-standard extensions,
> so I was very surprised to spot this issue.
>
> Is it a Boost's fault, or it is my misunderstanding of standard?

I presume that it is neither Boost's nor your fault. As long as a static
data member of const integral or const enumeration type (declared with an
initializer which is an integral constant expression) appears only in
expressions that are not potentially evaluated, the program is well-formed
even when it contains no definition for such a member.

And the definition of when an expression is potentially evaluated has been
updated to exclude contexts calling for an integral constant expression. See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#201.

Thus, if Boost's static data members with no definitions are all of const
integral or const enumeration type (declared with an initializer which is an
integral constant expression) and are used only where integral constant
expressions are required, the library is conforming.

Hope this helps.


Regards,

Andrei Iltchenko
Brainbench MVP for C++
http://www.brainbench.com





---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <a8587s$po3oh$1@ID-62495.news.dfncis.de>, Andrei Iltchenko
<iltchenko@yahoo.com> writes
>And the definition of when an expression is potentially evaluated has been
>updated to exclude contexts calling for an integral constant expression. See
>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#201.
>

201 is about Order of destruction of temporaries and does not seem to
have anything to do with the issue being discussed here
>Thus, if Boost's static data members with no definitions are all of const
>integral or const enumeration type (declared with an initializer which is an
>integral constant expression) and are used only where integral constant
>expressions are required, the library is conforming.

Note that 'are required' which is pretty restrictive of the uses to ones
that MUST be done statically.

--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm

---
[ 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.research.att.com/~austern/csc/faq.html                ]