kanze@gabi-soft.de (James Kanze) wrote
> [Moderator's note: this defect report has been
>  forwarded to the C++ committee. -moderator.]
>
> There seems to be an error in the definition of "integral constant
> expression"    5.19/1 [expr.const].  According to the standard: "An
> integral constant-expression can involve only literals, enumerators,
> const variables or static data members of integral or enumeration types
> initialized with constant expressions, [...]"
[Snipped example of an extern int const being used to size an array]

Good catch.

My suggestion for the new wording:
    An integral constant-expression can involve only literals,
    enumerators, const variables or static data members of integral
    or enumeration types, previously initialized in the same
    translation unit with constant expressions, [...]

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

 [Moderator's note: this defect report has been
 forwarded to the C++ committee. -moderator.]

There seems to be an error in the definition of "integral constant
expression"    5.19/1 [expr.const].  According to the standard: "An
integral constant-expression can involve only literals, enumerators,
const variables or static data members of integral or enumeration types
initialized with constant expressions, [...]"  Consider the following
program:

file1.cc :
    extern int const size = 10 ;

file2.cc :
    extern int const size ;
    char array[ size ] ;

I don't know of a compiler in the world which will accept it, and I
don't think that I could implement one using standard linker
technologies.  But "size" is definitly a "const variable [...] of
integral or enumeration type", and it is certainly "initialized with a
constant expression".  So according to the standard, the above code is
well formed, and the compiler (and linker) writers have some work cut
out for them.  I don't think that this was the intent, however.

While I'm at it, concerning the same sentence, Gabriel Dos Reis and I
would like to know whether the initialization of const static data
members referred to in this sentence concerns just an initialization in
the class definition, or any initialization.  That is, is the following
legal:

    struct X
    {
        static int const size ;
    } ;

    int const  X::size = 10 ;
    char array[ X::size ] ;

The above quoted sentence seems clear that it is, but in    9.4.2
[class.static.data], paragraph 4, there is a sentence which states "In
that case [where the initialization is in the class definition], the
member can appear in integral constant expressions within its scope."
Since there is no statement concerning the other case (where the
initialization is not in the class definition), this would seem to imply
that the variable can only appear in integral constant expressions "in
that case".

I argued the contrary, since it seemed to me that the text in
[expr.const] was perfectly clear.  Except that since the text actually
promises something not implementable, it is difficult to argue based on
what it literally says.  We are reduced to "guessing" the intent behind
the words, and of course, his guess is as good as mine.

(Actually, I don't think so: since the wording in [expr.const] predates
the extension to allow initialization in the class definition, it can't
have originally been intended to refer only to it.  And I don't think
that there was any intent that allowing initialization in class
definitions should break existing code.  But it would be nice to hear it
from some official source.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]