<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 15, 2014 at 6:33 AM, Larry Evans <span dir="ltr"><<a href="mailto:cppljevans@suddenlink.net" target="_blank">cppljevans@suddenlink.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/15/2014 06:59 AM, Gabriel Dos Reis wrote:<br>
> On Fri, Nov 14, 2014 at 4:23 AM, Larry Evans <<a href="mailto:cppljevans@suddenlink.net">cppljevans@suddenlink.net</a>><br>
> wrote:<br>
><br>
>> On 11/14/2014 12:48 AM, David Blaikie wrote:<br>
>>> My guess is that the proposal was written assuming a certain<br>
>> implementation<br>
>>> of constexpr that never panned out.<br>
>>><br>
>>> It looks like both GCC and Clang expect constexpr member variables to be<br>
>>> explicitly marked static:<br>
>>><br>
>>> const.cpp:5:19: error: non-static data member 'f' declared 'constexpr'<br>
>>>    constexpr foo f{};<br>
>>>                    ^<br>
>>><br>
>>> (is GCC 4.9's diagnostic - for a simple non-template constexpr member<br>
>> variable)<br>
>>><br>
>> That's sad because, as n3651 says on pp. 2-3:<br>
>><br>
>>   The main problems with “static data member” are:<br>
>><br>
>>   • they require “duplicate” declarations: once inside the class<br>
>>     template, once outside the class template to provide the “real”<br>
>>     definition in case the constants is odr-used.<br>
>><br>
><br>
> then don't put it in a class.<br>
><br>
<br>
</span>But then I don't understand why the problem was mentioned in n3651 on<br>
pp. 2-3.  I thought one of the reasons for the proposal was to free<br>
programmers from the need for "duplicate" declarations; however, the<br>
solution:<br>
<span class=""><br>
  don't put it in a class<br>
<br>
</span>seems to indicate that the problem can be avoided simply by not<br>
creating the problem.  IOW, the "duplicate" declaration in the<br>
archetypical example on p. 2, the numeric_limits example, can be<br>
avoided by not putting it in a template class (or struct in this<br>
case).<br>
<br>
In that case, I don't understand the rationale for proposal.<br>
<br>
I must be missing something :(<br>
<br>
-regards,<br>
Larry<br></blockquote><div><br></div><div>If you hate (as I do) having to put a variable in a class template just so that you can abstract over its type but then you are forced to provide a "duplicate" declaration (the real definition) outside the class, then variable templates remove that pain: they do what they were designed for.</div><div><br></div><div>If you want to change the language rules for not having to "redeclare" a static data member at namespace scope, then that is a *different problem*; one you should write a proposal for if you feel strongly about it.</div><div><br></div><div>-- Gaby</div><div><br></div></div></div></div>