This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: static const double pi = 3.1415;
gdr at integrable-solutions dot net (Gabriel Dos Reis) wrote on 19.02.03 in <m3d6lo904k dot fsf at uniton dot integrable-solutions dot net>:
> kaih at khms dot westfalen dot de (Kai Henningsen) writes:
>
> | Note I'm not arguing for or against any particular extension here.
> |
> | That said - what would be hard about allowing to initialize PODs with
> | constant expressions?
>
> I don't know how hard it would be. But I do know for sure that a
> couple of bugs on that issue have made their ways into the compiler.
> Getting rid of that undocumented extension certainly makes the job of
> implementing the language easier.
>
> Now, if you want that feature,
Note my first sentence above.
> maybe you might come with a detailled
> specification -- no, the undocumented extension didn't describe the
> semantics.
>
> what is clear is that integral constant and enumeration are considered
> compile-time entities and as such maybe "optimized" away by the
> compiler -- that is the main prupose of the standard feature.
> However, the picture is less clear when you consider non-compile time
> entities.
Frankly, that answer doesn't make sense to me.
Let me try to put the question differently.
Exhibit 1:
static sometype = someexpression;
Exhibit 2:
class foo {
static sometype = someexpression;
[...]
};
What is the justification for putting stronger requirements on the Exhibit
2 case than on the Exhibit 1 case? (That is, why does the standard make a
difference here?)
That is what is unobvious.
As for a detailed specification: "Handle Exhibit 2 exactly like Exhibit 1,
except for namespace issues." That would certainly follow the principle of
least surprise. What is hard about that?
I can't decide to prefer one version over the other until I know why there
is a difference in the first place. Maybe there is a good reason - but
until now, I haven't seen any argument that doesn't seem to be restricted
to "the standard says so". Well duh, we already know that. It doesn't
answer the question - it *causes* the question.
MfG Kai