Topic: Proposal: Calling Base class construct on
Author: Jonathan Wakely <cxx@kayari.org>
Date: Wed, 19 Jun 2013 11:44:57 -0700 (PDT)
Raw View
------=_Part_7013_32454129.1371667497359
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, June 19, 2013 7:22:55 PM UTC+1, Dan Hatch wrote:
>
>
>
> I'm looking for some feedback on whether something like this is a good
> idea.
> In my opinion, it makes the code more terse and easier to understand.
>
> class Base {
> explicit Base ( const char* name ) : className( name ) {}
> const char* getClassName() { return className; }
> const char* className = "Base";
> };
>
> // Call Base class' constructor
> class Derived : public Base("Derived") {
> Derived( int foo ) {}
> };
>
> // This would be syntactic sugar for calling the base class's constructor
> for
> // each of the Derived class's constructors.
> class Derived : public Base {
> Derived() : Base("Derived") {}
> Derived( int foo ) : Base("Derived") {}
> };
>
>
Interesting, it's analogous to non-static data member initializers, which
say how to initialize the member when it doesn't appear explicitly in a
ctor-init-list.
This would not be exactly the same, but you could just write one
constructor that calls the base class the way you want and then make the
other constructors delegate to it:
class Derived : public Base {
Derived() : Base("Derived") {}
Derived( int foo ) : Derived() {}
};
You could even add a new, private constructor used just for that purpose
to keep things separate and clear what's going on, if you prefer:
class Derived : public Base {
private:
struct tag {};
Derived(tag) : Base("Derived") {}
public:
Derived() : Derived(tag{}) {}
Derived( int foo ) : Derived(tag{}) {}
};
(It's not exactly the same because after the target constructor finishes
the object is fully-constructed, even though the delegating constructor
hasn't finished ... which might change the behaviour in some cases when
compared with your proposal.)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7013_32454129.1371667497359
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, June 19, 2013 7:22:55 PM UTC+1, Dan Hatch wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><br><br>I'm looking for some feedba=
ck on whether something like this is a good idea.<br>In my opinion, it make=
s the code more terse and easier to understand.<br><br><div style=3D"backgr=
ound-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:soli=
d;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#0=
08">class</span><span style=3D"color:#000"> </span><span style=3D"color:#60=
6">Base</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>{</span><span style=3D"color:#000"><br> </span><span style=3D=
"color:#008">explicit</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">Base</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">(</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">const</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#008">char</span><span style=3D"color:#660">*</span><span style=3D"colo=
r:#000"> name </span><span style=3D"color:#660">)</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">:</span><span style=3D"color:#00=
0"> className</span><span style=3D"color:#660">(</span><span style=3D"color=
:#000"> name </span><span style=3D"color:#660">)</span><span style=3D"color=
:#000"> </span><span style=3D"color:#660">{}</span><span style=3D"color:#00=
0"><br> </span><span style=3D"color:#008">const</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">char</span><span styl=
e=3D"color:#660">*</span><span style=3D"color:#000"> getClassName</span><sp=
an style=3D"color:#660">()</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">return</span><span style=3D"color:#000"> className</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">}</span><span style=3D"color:#000"><br> </=
span><span style=3D"color:#008">const</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">char</span><span style=3D"color:#660">*</spa=
n><span style=3D"color:#000"> className </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#080">"Ba=
se"</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br>=
<br></span><span style=3D"color:#800">// Call Base class' constructor</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#008">class</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#606">Derived</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">:</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">public</span><=
span style=3D"color:#000"> </span><span style=3D"color:#606">Base</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#080">"Derived"</span>=
<span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span=
style=3D"color:#660">{</span><span style=3D"color:#000"><br> =
</span><span style=3D"color:#606">Derived</span><span style=3D"color:#660">=
(</span><span style=3D"color:#000"> </span><span style=3D"color:#008">int</=
span><span style=3D"color:#000"> foo </span><span style=3D"color:#660">)</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">{}</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#660">};</span><=
span style=3D"color:#000"><br><br></span><span style=3D"color:#800">// This=
would be syntactic sugar for calling the base class's constructor for</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#800">// each =
of the Derived class's constructors.</span><span style=3D"color:#000"><br><=
/span><span style=3D"color:#008">class</span><span style=3D"color:#000"> </=
span><span style=3D"color:#606">Derived</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">:</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">public</span><span style=3D"color:#000"> </span=
><span style=3D"color:#606">Base</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">{</span><span style=3D"color:#000"><br> &nb=
sp; </span><span style=3D"color:#606">Derived</span><span style=3D"color:#6=
60">()</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
:</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Base<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#080">"Derive=
d"</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#660">{}</span><span style=3D"color:#000"><br>&nbs=
p; </span><span style=3D"color:#606">Derived</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#000"> </span><span style=3D"color:#=
008">int</span><span style=3D"color:#000"> foo </span><span style=3D"color:=
#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660"=
>:</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Base=
</span><span style=3D"color:#660">(</span><span style=3D"color:#080">"Deriv=
ed"</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </=
span><span style=3D"color:#660">{}</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">};</span><span style=3D"color:#000"><br></sp=
an></div></code></div><br></blockquote><div><br>Interesting, it's analogous=
to non-static data member initializers, which say how to initialize the me=
mber when it doesn't appear explicitly in a ctor-init-list.<br><br>This wou=
ld not be exactly the same, but you could just write one constructor that c=
alls the base class the way you want and then make the other constructors d=
elegate to it:<br><br><code><span style=3D"color:#008">class</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#606">Derived</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">:</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">public</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Base</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#000"><br> </span><span style=3D"color:#606">Derived</spa=
n><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">:</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#606">Base</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#080">"Derived"</span><span style=3D"color:#660">)</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">{}</span><span styl=
e=3D"color:#000"><br> </span><span style=3D"color:#606">Derive=
d</span><span style=3D"color:#660">(</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> foo </s=
pan><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">:</span><span style=3D"color:#000"> </span><span =
style=3D"color:#606">Derived()</span><span style=3D"color:#660"></span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">{}</span><span st=
yle=3D"color:#000"><br></span><span style=3D"color:#660">};</span><span sty=
le=3D"color:#000"><br></span></code><br> You could even add a new, pri=
vate constructor used just for that purpose to keep things separate and cle=
ar what's going on, if you prefer:<br><br><code><span style=3D"color:#008">=
class</span><span style=3D"color:#000"> </span><span style=3D"color:#606">D=
erived</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
:</span><span style=3D"color:#000"> </span><span style=3D"color:#008">publi=
c</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Base<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"><br>private:<br> struct tag {=
};<br> </span><span style=3D"color:#606">Derived</span><span s=
tyle=3D"color:#660">(tag)</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">:</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">Base</span><span style=3D"color:#660">(</span><span style=
=3D"color:#080">"Derived"</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">{}</span><span style=
=3D"color:#000"><br>public:<br></span></code><code><span style=3D"color:#00=
0"><code><span style=3D"color:#000"> </span><span style=3D"col=
or:#606">Derived</span><span style=3D"color:#660">(</span><span style=3D"co=
lor:#000"></span><span style=3D"color:#000"></span><span style=3D"color:#66=
0">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">:<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#000">Derived=
(tag{}) </span><span style=3D"color:#660">{}</span><span style=3D"color:#00=
0"><br></span></code> </span><span style=3D"color:#606">Derive=
d</span><span style=3D"color:#660">(</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> foo </s=
pan><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">:</span><span style=3D"color:#000"> </span></code=
><code><span style=3D"color:#000"><code><span style=3D"color:#000"><code><s=
pan style=3D"color:#000"></span><span style=3D"color:#000">Derived(tag{}) <=
/span></code></span></code></span><span style=3D"color:#660"></span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">{}</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">};</span><span style=
=3D"color:#000"><br></span></code><br>(It's not exactly the same because af=
ter the target constructor finishes the object is fully-constructed, even t=
hough the delegating constructor hasn't finished ... which might change the=
behaviour in some cases when compared with your proposal.)<br><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_7013_32454129.1371667497359--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 19 Jun 2013 13:51:05 -0500
Raw View
--089e0160b6244b537504df865282
Content-Type: text/plain; charset=ISO-8859-1
On 19 June 2013 13:44, Jonathan Wakely <cxx@kayari.org> wrote:
> On Wednesday, June 19, 2013 7:22:55 PM UTC+1, Dan Hatch wrote:
>>
>>
>>
>> class Base {
>> explicit Base ( const char* name ) : className( name ) {}
>> const char* getClassName() { return className; }
>> const char* className = "Base";
>> };
>>
>> // Call Base class' constructor
>> class Derived : public Base("Derived") {
>> Derived( int foo ) {}
>> };
>>
>> // This would be syntactic sugar for calling the base class's constructor
>> for
>> // each of the Derived class's constructors.
>> class Derived : public Base {
>> Derived() : Base("Derived") {}
>> Derived( int foo ) : Base("Derived") {}
>> };
>>
>>
> Interesting, it's analogous to non-static data member initializers, which
> say how to initialize the member when it doesn't appear explicitly in a
> ctor-init-list.
>
+1 if that is the intended behavior (assuming there are no syntax issues as
a result of it, of course).
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0160b6244b537504df865282
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 19 June 2013 13:44, Jonathan Wakely <span dir=3D"ltr"><<a href=3D"mai=
lto:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>></span> wrote:<=
br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Wednesday, June 19, 2013 7:22:55 PM UTC+1, Dan Hatch w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><br><br><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px;word-wrap:break-word">
<code><div><span style=3D"color:#008">class</span><span style> </span><span=
style=3D"color:#606">Base</span><span style> </span><span style=3D"color:#=
660">{</span><span style><br>=A0 =A0 </span><span style=3D"color:#008">expl=
icit</span><span style> </span><span style=3D"color:#606">Base</span><span =
style> </span><span style=3D"color:#660">(</span><span style> </span><span =
style=3D"color:#008">const</span><span style> </span><span style=3D"color:#=
008">char</span><span style=3D"color:#660">*</span><span style> name </span=
><span style=3D"color:#660">)</span><span style> </span><span style=3D"colo=
r:#660">:</span><span style> className</span><span style=3D"color:#660">(</=
span><span style> name </span><span style=3D"color:#660">)</span><span styl=
e> </span><span style=3D"color:#660">{}</span><span style><br>
=A0 =A0 </span><span style=3D"color:#008">const</span><span style> </span><=
span style=3D"color:#008">char</span><span style=3D"color:#660">*</span><sp=
an style> getClassName</span><span style=3D"color:#660">()</span><span styl=
e> </span><span style=3D"color:#660">{</span><span style> </span><span styl=
e=3D"color:#008">return</span><span style> className</span><span style=3D"c=
olor:#660">;</span><span style> </span><span style=3D"color:#660">}</span><=
span style><br>
=A0 =A0 </span><span style=3D"color:#008">const</span><span style> </span><=
span style=3D"color:#008">char</span><span style=3D"color:#660">*</span><sp=
an style> className </span><span style=3D"color:#660">=3D</span><span style=
> </span><span style=3D"color:#080">"Base"</span><span style=3D"c=
olor:#660">;</span><span style><br>
</span><span style=3D"color:#660">};</span><span style><br><br></span><span=
style=3D"color:#800">// Call Base class' constructor</span><span style=
><br></span><span style=3D"color:#008">class</span><span style> </span><spa=
n style=3D"color:#606">Derived</span><span style> </span><span style=3D"col=
or:#660">:</span><span style> </span><span style=3D"color:#008">public</spa=
n><span style> </span><span style=3D"color:#606">Base</span><span style=3D"=
color:#660">(</span><span style=3D"color:#080">"Derived"</span><s=
pan style=3D"color:#660">)</span><span style> </span><span style=3D"color:#=
660">{</span><span style><br>
=A0 =A0 </span><span style=3D"color:#606">Derived</span><span style=3D"colo=
r:#660">(</span><span style> </span><span style=3D"color:#008">int</span><s=
pan style> foo </span><span style=3D"color:#660">)</span><span style> </spa=
n><span style=3D"color:#660">{}</span><span style><br>
</span><span style=3D"color:#660">};</span><span style><br><br></span><span=
style=3D"color:#800">// This would be syntactic sugar for calling the base=
class's constructor for</span><span style><br></span><span style=3D"co=
lor:#800">// each of the Derived class's constructors.</span><span styl=
e><br>
</span><span style=3D"color:#008">class</span><span style> </span><span sty=
le=3D"color:#606">Derived</span><span style> </span><span style=3D"color:#6=
60">:</span><span style> </span><span style=3D"color:#008">public</span><sp=
an style> </span><span style=3D"color:#606">Base</span><span style> </span>=
<span style=3D"color:#660">{</span><span style><br>
=A0 =A0 </span><span style=3D"color:#606">Derived</span><span style=3D"colo=
r:#660">()</span><span style> </span><span style=3D"color:#660">:</span><sp=
an style> </span><span style=3D"color:#606">Base</span><span style=3D"color=
:#660">(</span><span style=3D"color:#080">"Derived"</span><span s=
tyle=3D"color:#660">)</span><span style> </span><span style=3D"color:#660">=
{}</span><span style><br>
=A0 =A0 </span><span style=3D"color:#606">Derived</span><span style=3D"colo=
r:#660">(</span><span style> </span><span style=3D"color:#008">int</span><s=
pan style> foo </span><span style=3D"color:#660">)</span><span style> </spa=
n><span style=3D"color:#660">:</span><span style> </span><span style=3D"col=
or:#606">Base</span><span style=3D"color:#660">(</span><span style=3D"color=
:#080">"Derived"</span><span style=3D"color:#660">)</span><span s=
tyle> </span><span style=3D"color:#660">{}</span><span style><br>
</span><span style=3D"color:#660">};</span><span style><br></span></div></c=
ode></div><br></blockquote></div><div><br>Interesting, it's analogous t=
o non-static data member initializers, which say how to initialize the memb=
er when it doesn't appear explicitly in a ctor-init-list.<br>
</div></blockquote><div><br>+1 if that is the intended behavior (assuming t=
here are no syntax issues as a result of it, of course).<br clear=3D"all"><=
/div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e0160b6244b537504df865282--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 19 Jun 2013 14:57:51 -0400
Raw View
On Wed, Jun 19, 2013 at 2:51 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>>> class Derived : public Base("Derived") {
>>> Derived( int foo ) {}
>>> };
> +1 if that is the intended behavior (assuming there are no syntax issues as
> a result of it, of course).
> --
The constructor `try` block does not work with this syntax. How we fix that?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 19 Jun 2013 15:08:05 -0400
Raw View
On Wed, Jun 19, 2013 at 2:57 PM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Wed, Jun 19, 2013 at 2:51 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>>>> class Derived : public Base("Derived") {
>>>> Derived( int foo ) {}
>>>> };
>
> The constructor `try` block does not work with this syntax. How we fix that?
I mean, although a constructor try block will just cover the exception
thrown from any subobject, but after the call to be base ctor is move
to the inheritance list, syntactically it's too far from the `try :`...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Wed, 19 Jun 2013 12:12:58 -0700 (PDT)
Raw View
------=_Part_6559_11043326.1371669178603
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, June 19, 2013 8:08:05 PM UTC+1, Zhihao Yuan wrote:
> >
> > The constructor `try` block does not work with this syntax. How we fix
> that?
>
> I mean, although a constructor try block will just cover the exception
> thrown from any subobject, but after the call to be base ctor is move
> to the inheritance list, syntactically it's too far from the `try :`...
>
>
Why is it different to non-static data member initializers that might throw?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6559_11043326.1371669178603
Content-Type: text/html; charset=ISO-8859-1
On Wednesday, June 19, 2013 8:08:05 PM UTC+1, Zhihao Yuan wrote:<br><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>
<br>> The constructor `try` block does not work with this syntax. How we fix that?
<br>
<br>I mean, although a constructor try block will just cover the exception
<br>thrown from any subobject, but after the call to be base ctor is move
<br>to the inheritance list, syntactically it's too far from the `try :`...
<br>
<br></blockquote><div><br></div><div>Why is it different to non-static data member initializers that might throw?</div><div><br></div><div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
<br />
<br />
------=_Part_6559_11043326.1371669178603--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 19 Jun 2013 15:28:22 -0400
Raw View
--089e0158c76c35d4e904df86d503
Content-Type: text/plain; charset=ISO-8859-1
Well, you win :)
--
Zhihao Yuan
On Jun 19, 2013 3:13 PM, "Jonathan Wakely" <cxx@kayari.org> wrote:
> On Wednesday, June 19, 2013 8:08:05 PM UTC+1, Zhihao Yuan wrote:
>
>> >
>> > The constructor `try` block does not work with this syntax. How we fix
>> that?
>>
>> I mean, although a constructor try block will just cover the exception
>> thrown from any subobject, but after the call to be base ctor is move
>> to the inheritance list, syntactically it's too far from the `try :`...
>>
>>
> Why is it different to non-static data member initializers that might
> throw?
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0158c76c35d4e904df86d503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p>Well, you win :)</p>
<p>--<br>
Zhihao Yuan</p>
<div class=3D"gmail_quote">On Jun 19, 2013 3:13 PM, "Jonathan Wakely&q=
uot; <<a href=3D"mailto:cxx@kayari.org">cxx@kayari.org</a>> wrote:<br=
type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wednesday, June 19, 2013 8:08:05 PM UTC+1, Zhihao Yuan wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">>
<br>> The constructor `try` block does not work with this syntax. =A0How=
we fix that?
<br>
<br>I mean, although a constructor try block will just cover the exception
<br>thrown from any subobject, but after the call to be base ctor is move
<br>to the inheritance list, syntactically it's too far from the `try :=
`...
<br>
<br></blockquote><div><br></div><div>Why is it different to non-static data=
member initializers that might throw?</div><div><br></div><div><br></div>
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
=A0<br>
=A0<br>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e0158c76c35d4e904df86d503--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 19 Jun 2013 12:28:39 -0700
Raw View
On Wed, Jun 19, 2013 at 11:22 AM, Dan Hatch <danhatch333@gmail.com> wrote:
> I'm looking for some feedback on whether something like this is a good idea.
> In my opinion, it makes the code more terse and easier to understand.
>
> class Base {
> explicit Base ( const char* name ) : className( name ) {}
> const char* getClassName() { return className; }
> const char* className = "Base";
> };
>
> // Call Base class' constructor
> class Derived : public Base("Derived") {
> Derived( int foo ) {}
> };
>
> // This would be syntactic sugar for calling the base class's constructor
> for
> // each of the Derived class's constructors.
> class Derived : public Base {
> Derived() : Base("Derived") {}
> Derived( int foo ) : Base("Derived") {}
> };
Generally, I think this is a problem worth solving, and the implied
semantics (just like a default initializer for a non-static data
member) seem exactly right. I also like that this would fix a hole in
inheriting constructors (that you cannot specify how to construct the
other base classes). Two things here give me pause:
1) Default initializers were designed such that they would be parsed
within the completed class scope, behaving exactly as if they appeared
within a constructor body, and I think this proposal should aim to
harmonize with them where reasonable. It's not obvious to me whether
we would want the same delayed-parsing behavior here: if we do, it
seems surprising syntactically to be able to refer to members of the
class from before we reach the class's "{', and if we don't, we have
an unfortunate asymmetry.
2) The concrete syntax does not support direct-list-initialization.
For instance:
struct A : B { /* default initializer for B base class, or class body? */ };
We could disallow direct-list-initialization here (just as we disallow
direct non-list initialization for default initializers of non-static
data members), but again, the asymmetry is unfortunate.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Wed, 19 Jun 2013 14:12:55 -0700 (PDT)
Raw View
------=_Part_627_3339347.1371676375772
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, June 19, 2013 8:28:39 PM UTC+1, Richard Smith wrote:
>
> On Wed, Jun 19, 2013 at 11:22 AM, Dan Hatch <danha...@gmail.com<javascript:>>
> wrote:
> > I'm looking for some feedback on whether something like this is a good
> idea.
> > In my opinion, it makes the code more terse and easier to understand.
> >
> > class Base {
> > explicit Base ( const char* name ) : className( name ) {}
> > const char* getClassName() { return className; }
> > const char* className = "Base";
> > };
> >
> > // Call Base class' constructor
> > class Derived : public Base("Derived") {
> > Derived( int foo ) {}
> > };
> >
> > // This would be syntactic sugar for calling the base class's
> constructor
> > for
> > // each of the Derived class's constructors.
> > class Derived : public Base {
> > Derived() : Base("Derived") {}
> > Derived( int foo ) : Base("Derived") {}
> > };
>
> Generally, I think this is a problem worth solving, and the implied
> semantics (just like a default initializer for a non-static data
> member) seem exactly right.
Yes, I like the general idea.
> I also like that this would fix a hole in
> inheriting constructors (that you cannot specify how to construct the
> other base classes). Two things here give me pause:
>
> 1) Default initializers were designed such that they would be parsed
> within the completed class scope, behaving exactly as if they appeared
> within a constructor body, and I think this proposal should aim to
> harmonize with them where reasonable. It's not obvious to me whether
> we would want the same delayed-parsing behavior here: if we do, it
> seems surprising syntactically to be able to refer to members of the
> class from before we reach the class's "{', and if we don't, we have
> an unfortunate asymmetry.
>
> 2) The concrete syntax does not support direct-list-initialization.
> For instance:
>
> struct A : B { /* default initializer for B base class, or class body? */
> };
>
> We could disallow direct-list-initialization here (just as we disallow
> direct non-list initialization for default initializers of non-static
> data members), but again, the asymmetry is unfortunate.
>
How about a using directive at class scope, followed by a
brace-or-equal-init:
class Derived {
using Base = "Derived";
Derived() = default;
};
class Derived {
using Base{"Derived"};
Derived() = default;
};
The brace-or-equal-init shouldn't clash with inheriting constructors or
using directives, right?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_627_3339347.1371676375772
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, June 19, 2013 8:28:39 PM UTC+1, Richard Smith wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 11:22 A=
M, Dan Hatch <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"_2Gl3uVqHocJ">danha...@gmail.com</a>> wrote:
<br>> I'm looking for some feedback on whether something like this is a =
good idea.
<br>> In my opinion, it makes the code more terse and easier to understa=
nd.
<br>>
<br>> class Base {
<br>> explicit Base ( const char* name ) : className( name=
) {}
<br>> const char* getClassName() { return className; }
<br>> const char* className =3D "Base";
<br>> };
<br>>
<br>> // Call Base class' constructor
<br>> class Derived : public Base("Derived") {
<br>> Derived( int foo ) {}
<br>> };
<br>>
<br>> // This would be syntactic sugar for calling the base class's cons=
tructor
<br>> for
<br>> // each of the Derived class's constructors.
<br>> class Derived : public Base {
<br>> Derived() : Base("Derived") {}
<br>> Derived( int foo ) : Base("Derived") {}
<br>> };
<br>
<br>Generally, I think this is a problem worth solving, and the implied
<br>semantics (just like a default initializer for a non-static data
<br>member) seem exactly right.</blockquote><div><br></div><div>Yes, I like=
the general idea.</div><div> </div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"> I also like that this would fix a hole in
<br>inheriting constructors (that you cannot specify how to construct the
<br>other base classes). Two things here give me pause:
<br>
<br>1) Default initializers were designed such that they would be parsed
<br>within the completed class scope, behaving exactly as if they appeared
<br>within a constructor body, and I think this proposal should aim to
<br>harmonize with them where reasonable. It's not obvious to me whether
<br>we would want the same delayed-parsing behavior here: if we do, it
<br>seems surprising syntactically to be able to refer to members of the
<br>class from before we reach the class's "{', and if we don't, we have
<br>an unfortunate asymmetry.
<br>
<br>2) The concrete syntax does not support direct-list-initialization.
<br>For instance:
<br>
<br>struct A : B { /* default initializer for B base class, or class body? =
*/ };
<br>
<br>We could disallow direct-list-initialization here (just as we disallow
<br>direct non-list initialization for default initializers of non-static
<br>data members), but again, the asymmetry is unfortunate.
<br></blockquote><div><br></div><div><br></div><div>How about a using direc=
tive at class scope, followed by a brace-or-equal-init:</div><div><br></div=
><div>class Derived {</div><div> using Base =3D "Derived";<br></div><=
div> Derived() =3D default;<br></div><div>};</div><div><div><br></div=
><div>class Derived {</div><div> using Base{"Derived"};<br></div><div=
> Derived() =3D default;<br></div><div>};</div></div><div><br></div><=
div>The brace-or-equal-init shouldn't clash with inheriting constructors or=
using directives, right?</div><div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_627_3339347.1371676375772--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Wed, 19 Jun 2013 14:15:50 -0700 (PDT)
Raw View
------=_Part_3851_29945045.1371676550316
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, June 19, 2013 10:12:55 PM UTC+1, Jonathan Wakely wrote:
>
>
> How about a using directive at class scope, followed by a
> brace-or-equal-init:
>
> class Derived {
> using Base = "Derived";
> Derived() = default;
> };
>
> class Derived {
> using Base{"Derived"};
> Derived() = default;
> };
>
> The brace-or-equal-init shouldn't clash with inheriting constructors or
> using directives, right?
>
Oops, obviously I meant for Derived to actually be derived from Base:
class Derived : Base {
using Base{"Derived"};
Derived() = default;
};
This would *not* allow Base("Derived"), as the original proposal used,
because that isn't a brace-or-equal-init. It might be possible to allow it,
but would be inconsistent with non-static data member initializers.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3851_29945045.1371676550316
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>On Wednesday, June 19, 2013 10:12:55 PM UTC+1, Jonathan Wakely wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><br><div>How about a using direc=
tive at class scope, followed by a brace-or-equal-init:</div><div><br></div=
><div>class Derived {</div><div> using Base =3D "Derived";<br></div><=
div> Derived() =3D default;<br></div><div>};</div><div><div><br></div=
><div>class Derived {</div><div> using Base{"Derived"};<br></div><div=
> Derived() =3D default;<br></div><div>};</div></div><div><br></div><=
div>The brace-or-equal-init shouldn't clash with inheriting constructors or=
using directives, right?</div></blockquote><div><br></div><div>Oops, obvio=
usly I meant for Derived to actually be derived from Base:</div><div><br></=
div><div><div><div>class Derived : Base {</div><div> using Base{"Deri=
ved"};<br></div><div> Derived() =3D default;<br></div><div>};</div></=
div></div><div><br></div><div>This would *not* allow Base("Derived"), as th=
e original proposal used, because that isn't a brace-or-equal-init. It migh=
t be possible to allow it, but would be inconsistent with non-static data m=
ember initializers.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_3851_29945045.1371676550316--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 19 Jun 2013 14:18:52 -0700
Raw View
On Wed, Jun 19, 2013 at 2:12 PM, Jonathan Wakely <cxx@kayari.org> wrote:
> On Wednesday, June 19, 2013 8:28:39 PM UTC+1, Richard Smith wrote:
>> On Wed, Jun 19, 2013 at 11:22 AM, Dan Hatch <danha...@gmail.com> wrote:
>> > I'm looking for some feedback on whether something like this is a good
>> > idea.
>> > In my opinion, it makes the code more terse and easier to understand.
>> >
>> > class Base {
>> > explicit Base ( const char* name ) : className( name ) {}
>> > const char* getClassName() { return className; }
>> > const char* className = "Base";
>> > };
>> >
>> > // Call Base class' constructor
>> > class Derived : public Base("Derived") {
>> > Derived( int foo ) {}
>> > };
>> >
>> > // This would be syntactic sugar for calling the base class's
>> > constructor
>> > for
>> > // each of the Derived class's constructors.
>> > class Derived : public Base {
>> > Derived() : Base("Derived") {}
>> > Derived( int foo ) : Base("Derived") {}
>> > };
>>
>> Generally, I think this is a problem worth solving, and the implied
>> semantics (just like a default initializer for a non-static data
>> member) seem exactly right.
>
>
> Yes, I like the general idea.
>
>>
>> I also like that this would fix a hole in
>> inheriting constructors (that you cannot specify how to construct the
>> other base classes). Two things here give me pause:
>>
>> 1) Default initializers were designed such that they would be parsed
>> within the completed class scope, behaving exactly as if they appeared
>> within a constructor body, and I think this proposal should aim to
>> harmonize with them where reasonable. It's not obvious to me whether
>> we would want the same delayed-parsing behavior here: if we do, it
>> seems surprising syntactically to be able to refer to members of the
>> class from before we reach the class's "{', and if we don't, we have
>> an unfortunate asymmetry.
>>
>> 2) The concrete syntax does not support direct-list-initialization.
>> For instance:
>>
>> struct A : B { /* default initializer for B base class, or class body? */
>> };
>>
>> We could disallow direct-list-initialization here (just as we disallow
>> direct non-list initialization for default initializers of non-static
>> data members), but again, the asymmetry is unfortunate.
>
>
>
> How about a using directive at class scope, followed by a
> brace-or-equal-init:
>
> class Derived {
> using Base = "Derived";
> Derived() = default;
> };
>
> class Derived {
> using Base{"Derived"};
> Derived() = default;
> };
>
> The brace-or-equal-init shouldn't clash with inheriting constructors or
> using directives, right?
You get fun new ambiguities with alias-declarations.
template<typename T>
struct Derived : Base {
using Base = typename T::x();
};
Is that declaring a typedef-name Base, which is a function type
returning T::x, or declaring a default initializer for the 'Base' base
class that constructs it from a value-initialized object of type T::x?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Wed, 19 Jun 2013 14:43:45 -0700 (PDT)
Raw View
------=_Part_1816_32917134.1371678225940
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, June 19, 2013 10:18:52 PM UTC+1, Richard Smith wrote:
> On Wed, Jun 19, 2013 at 2:12 PM, Jonathan Wakely <c...@kayari.org<javascript:>>
> wrote:
> > The brace-or-equal-init shouldn't clash with inheriting constructors or
> > using directives, right?
>
> You get fun new ambiguities with alias-declarations.
>
> template<typename T>
> struct Derived : Base {
> using Base = typename T::x();
> };
>
> Is that declaring a typedef-name Base, which is a function type
> returning T::x, or declaring a default initializer for the 'Base' base
> class that constructs it from a value-initialized object of type T::x?
>
Gah, of course you do.
And if you only allow a braced-init-list there are certain constructors
that can't be called.
I hope someone smarter than me can devise a good syntax, because I like the
idea.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1816_32917134.1371678225940
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, June 19, 2013 10:18:52 PM UTC+1, Richard Smith wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 2:12 PM, J=
onathan Wakely <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"NfXJLh6V4hAJ">c...@kayari.org</a>> wrote:
<br>> The brace-or-equal-init shouldn't clash with inheriting constructo=
rs or
<br>> using directives, right?
<br>
<br>You get fun new ambiguities with alias-declarations.
<br>
<br>template<typename T>
<br>struct Derived : Base {
<br> using Base =3D typename T::x();
<br>};
<br>
<br>Is that declaring a typedef-name Base, which is a function type
<br>returning T::x, or declaring a default initializer for the 'Base' base
<br>class that constructs it from a value-initialized object of type T::x?
<br></blockquote><div><br></div><div>Gah, of course you do. </div><div=
><br></div><div>And if you only allow a braced-init-list there are certain =
constructors that can't be called.</div><div><br></div><div>I hope someone =
smarter than me can devise a good syntax, because I like the idea.</div><di=
v><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_1816_32917134.1371678225940--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 19 Jun 2013 17:56:09 -0400
Raw View
On Wed, Jun 19, 2013 at 3:28 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> struct A : B { /* default initializer for B base class, or class body? */ };
This syntax is very intuitive, but list init killed it... I guess it not
the first victim of the overuse of {}...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Alex B <devalexb@gmail.com>
Date: Wed, 19 Jun 2013 20:19:53 -0700 (PDT)
Raw View
------=_Part_4829_4122517.1371698393575
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, June 19, 2013 5:56:09 PM UTC-4, Zhihao Yuan wrote:
>
> On Wed, Jun 19, 2013 at 3:28 PM, Richard Smith <ric...@metafoo.co.uk<javascript:>>
> wrote:
> > struct A : B { /* default initializer for B base class, or class body?
> */ };
>
> This syntax is very intuitive, but list init killed it... I guess it not
> the first victim of the overuse of {}...
>
>
Does it really kill it? I see two possibilities for a compiler to detect:
struct A : B { /*default initializer for B base class*/ } { /*class body*/
};
struct A : B { /*class body*/ };
I don't think there is a real ambiguity.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4829_4122517.1371698393575
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, June 19, 2013 5:56:09 PM UTC-4, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jun 19, 2013 at 3:28 PM, =
Richard Smith <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"qfe7wxSuDlsJ">ric...@metafoo.co.uk</a>> wrote:
<br>> struct A : B { /* default initializer for B base class, or class b=
ody? */ };
<br>
<br>This syntax is very intuitive, but list init killed it... I guess=
it not
<br>the first victim of the overuse of {}...
<br><br></blockquote><div><br></div><div>Does it really kill it? I see two =
possibilities for a compiler to detect:</div><div><br></div><div>struct A :=
B { /*default initializer for B base class*/ } { /*class body*/ };</div><d=
iv><br></div><div>struct A : B { /*class body*/ };</div><div><br></div><div=
>I don't think there is a real ambiguity.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_4829_4122517.1371698393575--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 19 Jun 2013 20:31:32 -0700
Raw View
On Wed, Jun 19, 2013 at 8:19 PM, Alex B <devalexb@gmail.com> wrote:
> On Wednesday, June 19, 2013 5:56:09 PM UTC-4, Zhihao Yuan wrote:
>> On Wed, Jun 19, 2013 at 3:28 PM, Richard Smith <ric...@metafoo.co.uk>
>> wrote:
>> > struct A : B { /* default initializer for B base class, or class body?
>> > */ };
>>
>> This syntax is very intuitive, but list init killed it... I guess it not
>> the first victim of the overuse of {}...
>>
>
> Does it really kill it? I see two possibilities for a compiler to detect:
>
> struct A : B { /*default initializer for B base class*/ } { /*class body*/
> };
>
> struct A : B { /*class body*/ };
>
> I don't think there is a real ambiguity.
It does not seem reasonable to require a compiler to look ahead over
an entire class body to detect the rare case where we actually have a
default initializer.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 19 Jun 2013 20:32:17 -0700
Raw View
On Wed, Jun 19, 2013 at 8:31 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> On Wed, Jun 19, 2013 at 8:19 PM, Alex B <devalexb@gmail.com> wrote:
>> On Wednesday, June 19, 2013 5:56:09 PM UTC-4, Zhihao Yuan wrote:
>>> On Wed, Jun 19, 2013 at 3:28 PM, Richard Smith <ric...@metafoo.co.uk>
>>> wrote:
>>> > struct A : B { /* default initializer for B base class, or class body?
>>> > */ };
>>>
>>> This syntax is very intuitive, but list init killed it... I guess it not
>>> the first victim of the overuse of {}...
>>>
>>
>> Does it really kill it? I see two possibilities for a compiler to detect:
>>
>> struct A : B { /*default initializer for B base class*/ } { /*class body*/
>> };
>>
>> struct A : B { /*class body*/ };
>>
>> I don't think there is a real ambiguity.
>
> It does not seem reasonable to require a compiler to look ahead over
> an entire class body to detect the rare case where we actually have a
> default initializer.
Oh, and...
struct A : B { ... } final { ... };
.... is genuinely ambiguous. :-)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Wed, 19 Jun 2013 23:44:33 -0400
Raw View
On Wed, Jun 19, 2013 at 11:31 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>> struct A : B { /*default initializer for B base class*/ } { /*class body*/
>> };
>>
>> struct A : B { /*class body*/ };
>>
>> I don't think there is a real ambiguity.
>
> It does not seem reasonable to require a compiler to look ahead over
> an entire class body to detect the rare case where we actually have a
> default initializer.
Hmm, wait, it might be doable. class body is consist of
statements, and initializer is consist of comma separated
expressions. And a class declaration is not allowed to
have an inheritance list. It should work.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 20 Jun 2013 00:05:34 -0400
Raw View
On Wed, Jun 19, 2013 at 11:19 PM, Alex B <devalexb@gmail.com> wrote:
> struct A : B { /*default initializer for B base class*/ } { /*class body*/
> };
>
> struct A : B { /*class body*/ };
I found something interesting:
struct N : A {} B {}; // valid C++11
struct N : A {}, B {}; // invalid
struct N : A {} B {}, C {}; // default init base A, empty class
body, define B, C
struct N : A {}, B {} C {}; // value init base A, default init B,
empty class body, define C
So it's all about how you put commas LOOOL
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.