Re: initialization of a const static float data member in a class
On Jun 15, 12:46 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
[...]
For the moment, I don't know exactly what the
counter-proposal is, so it's hard to argue against it, or
agree with it. If the proposal is that the declaration in
the class should be a definition (and thus, that you don't
need a definition elsewhere), then I'm radically against it;
such a rule would mean that things like:
static int someArray[] ;
would be illegal (since a definition requires a complete
type), and that you'd always have to provide the initializer
in the class (and most of the time, you really don't want
to).
So let's try to reword [9.4.2/2]:
The declaration of a static data member in its class
definition is not a definition and may be of an incomplete
type other than cv-qualified void unless it specifies an
initializer, in which case it is a definition and the type
shall be complete. If the declaration is not a definition,
the definition for a static data member shall appear in a
namespace scope enclosing the member?s class definition. In
the definition at namespace scope, the name of the static
data member shall be qualified by its class name using the
:: operator. The initializer expression in the definition of
a static data member is in the scope of its class (3.3.6).
What about that?
It's a start. Of course, you'll also need something in =A73.2.
Otherwise, a header which contains something like:
struct S { static int i = 43 ; } ;
will cause undefined behavior if it is included in more than one
translation unit.
Also, consider the issues of backwards compatibility; your
suggestion would make a lot of currently conforming code
illegal (since the previously required definition would suddenly
become a duplicate definition).
But those problems should be solvable as well. The real problem
is, of course, that on one has presented such a proposition to
the committee (and I suspect that it is too late now---we should
be very, very close to a CD, if the next version is really to be
C++0x, and not C++1x).
I can understand Alf's desire that all types (and not just
integral types) can have an initializer, and that shouldn't be
too hard to specify nor to implement. With regards to his
desire that you not need the separate definition, however, I'd
want to see the actual proposal. I understand the desire, but I
fear that it would require significant rework of the meaning of
definitions and declarations, which in turn is very likely to
have effects elsewhere.
In my coding style (I do almost exclusively templated code),
all code goes into header files. I rarely ever split
declarations from definitions.
I'm not sure I understand, and I don't quite see what templates
have to do with it. Whether the definition is in the header
file (or a file included from the header file) or in some
separate source file doesn't really change much.
I think, you misunderstood what I meant by splitting declarations and
definitions. I usually write
template < typename T >
class some_class {
void some_method ( some_type some_arg ) {
// implementation
}
};
instead of
template < typename T >
class some_class {
some_result_type some_method ( some_type some_arg );
};
template < typename T >
some_class<T>::some_result_type
some_class<T>::some_method ( some_class<T>::some_type some_arg ) {
// implementation
}
You mean that you make almost all of your functions inline?
In my work, it is normal to insist that the implementations be
in a separate file (even if, in the case of templates, this file
is included by the header). It's more or less a basic principle
if you're working in large systems (or more strictly speaking,
if there are more than two or three people working on the
application); you don't want the interface to accidentally
change after some bug fix in the implementation. (If you've
never accidentally changed something you didn't mean to, you're
a better typist than I am. Where as it's impossible to
accidentally change something in a file you haven't checked
out.)
Being forced to do that for static const members creates an
imbalance in coding style that makes the non-hack ugly and the
hack natural.
I don't think it is a good idea for the standard to legislate
style; and for templated code, the issue is more or less
entirely a matter of style.
I'm afraid I don't see where templates change anything.
They don't change the technical side of things. However, as
you can see above, the separation of the definition from the
declaration becomes quite wordy for templates.
There's a fair amount of redundance even for non-templates:-). A
good editor helps, but there's still a fair bit of typing to do.
Moreover, it has very little return for the effort since
compilers by and large do not support export and the main
technical reasons to hide definitions do not apply. That
influences coding style.
Even without export, I use separate files. For one, it will
make migration to a compiler which supports export simpler, and
for the other, it still keeps the implementation in a separate
file from the interface---essential when you have more than a
few people working on the same code base (but I agree that
without export, templates are pretty much unusable at the
application level).
But whatever. Until there is a concrete proposal, I don't
know what I'm considering.
See above.
Next step: get it to the committee. If you'd like, write it up
in the format of a formal proposal (with motivation, impact, and
potentially discussion of other alteratives, and why they are
rejected), and send it to me by private email, and I'll take
charge of presenting it. But don't get your hopes up too
much---two or three years ago, I think it would have found a
good deal of interest, but I fear that it's a bit too late at
present. (On the other hand, it's possible that something else
will come up which delays the standard, and someone on the
committee might take advantage of that to slip it through.)
--
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