V3 PATCH: Static data members

[Gabriel Dos_Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| >>>>> "Gabriel" == Gabriel Dos Reis <gdr@codesourcery.com> writes:
| 
|     Gabriel> Mark Mitchell <mark@codesourcery.com> writes:
| 
|     Gabriel> | G++ doesn't handle static data members well (they are
|     Gabriel> not implicitly | instantiated) on AIX, and it may not do
|     Gabriel> so in the near future.  It | handles *const* static data
|     Gabriel> members better, because it often doesn't | actually
|     Gabriel> allocate storage for the constants.
| 
|     Gabriel> Is that a conforming behaviour? static data members have
|     Gabriel> external linkage and I would expect the compiler to
|     Gabriel> allocate storage for such beasts.
| 
| The compiler is free not to allocate storage for them if they are
| defined in-class.

Yes of course, but that happens only for integral data types.  I was
speaking not just of integral types.

| ...  (Since then by the ODR they must be present in all
| translations where they are needed.)  For out-of-class definitions,
| I'm not sure. 

The compiler needs to, unless it does special optimization at the
linker level but then we're getting very speculative.  There is a
fundamental difference between const objects defined at namespace
scope and const static data members.

| ... You could be right that the compiler is not strictly
| conforming -- but the bottom line is that *V3* is still conforming,
| and the compiler has an easier time. :-)

Well, when I decided to check in the patch it was because I was tired
of seeing emission of "unncessary" variables.  That wasn't
speculation.  It was practical matter.

|     Gabriel> You've hit a reason why I recommand using enums where
|     Gabriel> possible in lieu of static integral data members.  See a
|     Gabriel> recent patch of mine about _Count_ones<>.
| 
| The copmiler should treat in-class initialized static const data
| members just like enums, and code written that way is cleaner.  

The compiler should ideally do any nifty optimization.  But the
compiler we use for the moment doesn't and as implementors we have to
cope with it as we can in order to reduce the abstraction penalty.

| ... If the
| compiler doesn't treat those two things identically, that is a
| quality-of-implementation issue.  

Get real!  I would appreciate any patch from you to improve the
compiler in that area.

| ... I would recommend that in V3 we do
| what we think makes the cleanest code; if the compiler generates
| inferior code file a bug against the compiler.

On the contrary, I think we should cope with the compiler limits and
reduce the abstraction penalty when possible.  Users are after quality 
(and footprint happens to be one the criteria); purity is secondary.

-- Gaby