Re: array bound is not an integer constant
On Aug 20, 9:01 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
Vladimir Jovic wrote:
extern const unsigned int TOTAL_SIZE;
Why would you even want a const integral to be extern?
Why wouldn't you?
What would be the advantage? As you yourself noticed, there
are only disadvantages.
Are you sure. Consider:
#include <vector>
const int i = 42 ;
inline // or make it a template...
void f()
{
std::vector< int > v ;
v.push_back( i ) ;
}
This is undefined behavior. It wouldn't be if i were extern.
(Of course, in practice, it will work with all compilers today.
Because no compiler currently checks for violations of the one
definition rule, and of course, since the address/reference
passed to vector<>::push_back is dereferenced rather quickly,
and has no impact in the final behavior of the code.)
It's ok to put const integrals in headers even if those
headers are included in more than one compilation unit. The
linker won't bark at you. There's no need for 'extern'.
The semantics are different. By default, a variable defined as
const has internal linkage; the extern forces it to have
external linkage. There are several cases where this makes a
difference. The above is an example: the symbol "i" in the
inline function "f" binds to different entities in different
translation units. (There is a special exception which applies
to const objects, but it only applies if only the value of the
object, and not its address, is used. Binding the object to the
int const& parameter of vector<>::push_back uses the address.)
There are also cases which may affect real code:
template< int const& ri >
class T { /* ... */ } ;
int const i = 42 ;
T< i > aT ;
won't compile, for example, unless you use "extern" to force i
to have external linkage. (I've actually been bitten by this in
real code, and had to add the extern to my constant objects.)
One obvious solution to this (today---the problem is historical)
would be to require the compiler to handle const objects with
namespace scope exactly like it now handles static template
data members. (Alf's suggestion.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34