Topic: Relaxing constraints on base class for aggregate types
Author: corentin.schreiber@cea.fr
Date: Sun, 15 Dec 2013 05:34:34 -0800 (PST)
Raw View
------=_Part_1185_29468456.1387114474434
Content-Type: text/plain; charset=ISO-8859-1
Hello,
I have encountered a situation where the wording for [dcl.init.aggr] seems
too restrictive, and I was wondering if it would be possible to change it.
Maybe this concept already exists in the norm, but let's define an "empty"
class as a trivial class having no member variable, no (virtual?) member
functions and no non-empty base class.
I suggest that aggregates can have base classes provided that they are
empty.
Here is a dumb example:
struct test1 {
int i, j;
};
struct base {
// could contain static variables & functions, typedefs (and non-virtual member functions?)
// but no non-trivial constructor or member variables
};
struct test2 : base {
int i, j;
};
int main() {
test1 t1{0,1}; // ok in C++11
test2 t2{0,1}; // not ok in C++11
return 0;
}
The point is that I often use empty base classes as a way to factorize
code. For example, if I want to assign a given ID to a class:
template<int N>
struct struct_id {
static const int ID = N;
};
struct test : struct_id<5> {
int i, j;
};
In the example above, the "test" struct should still be an aggregate, but
the current wording prevents it.
One way out is to explicitly write the constructor:
struct test2 : base {
test2() = default; // needed for default initialization
test2(int i_, int j_) : i(i_), j(j_) {}
int i, j;
};
But this is wrong for obvious reasons. Even if trivial:
1. it is tedious to write if the class has many data members, and also
implies the declaration of a default constructor,
2. it is tedious to maintain, as adding a new data member also implies
modifying the constructor,
3. it is error prone, as one could easily do the initialization wrong
(by missing a variable for example).
I could not find any proposal that would already address this issue. Does
this seem reasonable to you?
--
---
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_1185_29468456.1387114474434
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello, <br><br>I have encountered a situation where the wo=
rding for [dcl.init.aggr] seems too restrictive, and I was wondering if it =
would be possible to change it.<br>Maybe this concept already exists in the=
norm, but let's define an "empty" class as a trivial class having no membe=
r variable, no (virtual?) member functions and no non-empty base class.<br>=
I suggest that aggregates can have base classes provided that they are empt=
y.<br><br>Here is a dumb example:<br><code class=3D"prettyprint"><pre class=
=3D"alt2" dir=3D"ltr" style=3D"clear: both; margin: 0px; padding: 6px; bord=
er: 1px inset; width: 1621px; height: 134px; text-align: left; overflow: au=
to;"><pre style=3D"margin: 0"><span style=3D"color: #0000ff"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">struct</span></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> test1 </span><span class=3D=
"br0"><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &n=
bsp; </span><span style=3D"color: #0000ff"><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> j</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span class=3D"br0"><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">struct<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">base</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{<br> // could contain static va=
riables & functions, typedefs (and non-virtual member functions?)<br> =
// but no non-trivial constructor or member variables<br>};</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> test2 </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">base</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> j</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br> <br></span><span style=3D"color: #0=
000ff"><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span>=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> main</spa=
n><span class=3D"br0"><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span></span><span class=3D"br0"><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span class=3D"br0"><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span></span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br> test1 t1</span><span cla=
ss=3D"br0"><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n></span><span style=3D"color: #cc66cc;"><span style=3D"color: #066;" class=
=3D"styled-by-prettify">0</span></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #cc66cc;"><span style=
=3D"color: #066;" class=3D"styled-by-prettify">1</span></span><span class=
=3D"br0"><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> // ok in C++11<br>=
test2 t2{0,1}; // not ok in C++11<br> </span><span style=
=3D"color: #0000ff"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span></span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #cc66cc;"><span style=3D"color: #066;" =
class=3D"styled-by-prettify">0</span></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span class=3D"br0"><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span></span></pre></pre></code><br>The p=
oint is that I often use empty base classes as a way to factorize code. For=
example, if I want to assign a given ID to a class:<br><code class=3D"pret=
typrint"><pre class=3D"alt2" dir=3D"ltr" style=3D"clear: both; margin: 0px;=
padding: 6px; border: 1px inset; width: 1621px; height: 134px; text-align:=
left; overflow: auto;"><pre style=3D"margin: 0"><span style=3D"color: #000=
0ff"><span style=3D"color: #008;" class=3D"styled-by-prettify">template<=
int N><br>struct struct_id {<br> static const int ID =3D N;<br>};<br>=
<br>struct test : struct_id<5> {<br> int i, j;<br>};<br></span></s=
pan><span class=3D"br0"><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify"></span></span></pre></pre></code> <br>In the example above, the "tes=
t" struct should still be an aggregate, but the current wording prevents it=
..<br><br>One way out is to explicitly write the constructor:<br><code class=
=3D"prettyprint"><pre class=3D"alt2" dir=3D"ltr" style=3D"clear: both; marg=
in: 0px; padding: 6px; border: 1px inset; width: 1621px; height: 134px; tex=
t-align: left; overflow: auto;"><pre style=3D"margin: 0"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> test2 </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">base</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> t=
est2() =3D default; // needed for default initialization<br> test2(int i=
_, int j_) : i(i_), j(j_) {}<br> </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> j</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></pre></=
pre></code><br>But this is wrong for obvious reasons. Even if trivial:<br><=
ol><li>it is tedious to write if the class has many data members, and also =
implies the declaration of a default constructor,<br></li><li>it is tedious=
to maintain, as adding a new data member also implies modifying the constr=
uctor,<br></li><li>it is error prone, as one could easily do the initializa=
tion wrong (by missing a variable for example).</li></ol><p>I could not fin=
d any proposal that would already address this issue. Does this seem reason=
able to you?<br></p><mytubeelement data=3D"{"bundle":{"label=
_delimitor":":","percentage":"%","s=
mart_buffer":"Smart Buffer","start_playing_when_buffere=
d":"Start playing when buffered","sound":"Sou=
nd","desktop_notification":"Desktop Notification",=
"continuation_on_next_line":"-","loop":"=
Loop","only_notify":"Only Notify","estimated_=
time":"Estimated Time","global_preferences":"=
Global Preferences","no_notification_supported_on_your_browser&qu=
ot;:"No notification style supported on your browser version",&qu=
ot;video_buffered":"Video Buffered","buffered":&qu=
ot;Buffered","hyphen":"-","buffered_message&q=
uot;:"The video has been buffered as requested and is ready to play.&q=
uot;,"not_supported":"Not Supported","on":&qu=
ot;On","off":"Off","click_to_enable_for_this_=
site":"Click to enable for this site","desktop_notifica=
tion_denied":"You have denied permission for desktop notification=
for this site","notification_status_delimitor":";"=
;,"error":"Error","adblock_interferance_message&qu=
ot;:"Adblock (or similar extension) is known to interfere with SmartVi=
deo. Please add this url to adblock whitelist.","calculating"=
;:"Calculating","waiting":"Waiting","wil=
l_start_buffering_when_initialized":"Will start buffering when in=
itialized","will_start_playing_when_initialized":"Will =
start playing when initialized","completed":"Completed&=
quot;,"buffering_stalled":"Buffering is stalled. Will stop.&=
quot;,"stopped":"Stopped","hr":"Hr"=
,"min":"Min","sec":"Sec","any_=
moment":"Any Moment","popup_donate_to":"Donat=
e to","extension_id":null},"prefs":{"desktopN=
otification":true,"soundNotification":false,"logLevel&q=
uot;:0,"enable":true,"loop":false,"hidePopup"=
:false,"autoPlay":false,"autoBuffer":false,"autoPl=
ayOnBuffer":false,"autoPlayOnBufferPercentage":42,"auto=
PlayOnSmartBuffer":true,"quality":"default","=
fshd":false,"onlyNotification":true,"enableFullScreen&q=
uot;:true,"saveBandwidth":false,"hideAnnotations":true,=
"turnOffPagedBuffering":true}}" event=3D"preferencesUpdated" id=
=3D"myTubeRelayElementToPage"></mytubeelement><mytubeelement data=3D"{"=
;loadBundle":true}" event=3D"relayPrefs" id=3D"myTubeRelayElementToTab=
"></mytubeelement></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 />
------=_Part_1185_29468456.1387114474434--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 15 Dec 2013 15:51:34 +0200
Raw View
On 15 December 2013 15:34, <corentin.schreiber@cea.fr> wrote:
> But this is wrong for obvious reasons. Even if trivial:
>
> it is tedious to write if the class has many data members, and also implies
> the declaration of a default constructor,
> it is tedious to maintain, as adding a new data member also implies
> modifying the constructor,
> it is error prone, as one could easily do the initialization wrong (by
> missing a variable for example).
>
> I could not find any proposal that would already address this issue. Does
> this seem reasonable to you?
I wouldn't mind being able to do it, but perhaps it's targeting a rather narrow
case. You can make sure that you don't miss initializations by using non-static
data member initializers, which are now allowed for aggregates.
--
---
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: David Krauss <potswa@gmail.com>
Date: Sun, 15 Dec 2013 22:18:43 +0800
Raw View
This is a multi-part message in MIME format.
--------------040805040107000500000007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 12/15/13 9:34 PM, corentin.schreiber@cea.fr wrote:
> Hello,
>
> I have encountered a situation where the wording for [dcl.init.aggr] seems
> too restrictive, and I was wondering if it would be possible to change it.
> Maybe this concept already exists in the norm, but let's define an "empty"
> class as a trivial class having no member variable, no (virtual?) member
> functions and no non-empty base class.
> I suggest that aggregates can have base classes provided that they are
> empty.
The concept of an empty class already exists as part of the
specification of the standard layout property, where they are allowed as
bases.
It's also available as the type trait std::is_empty which is true for
conditions similar to what you mention:
T is a class type, but not a union type, with no non-static data members
other than bit-fields of length 0, no virtual member functions, no
virtual base classes, and no base class B for which is_empty<B>::value
is false.
C++ International Standard I think that allowing such bases for
aggregates would be wonderful. I seem to recall being annoyed by the
restriction in the past. Standard layout was introduced in C++11 so the
empty base semantic perhaps has yet to integrate fully into the language.
Also, perhaps empty bases should be allowed for unions. The idea just
occurred to me; I haven't really considered this.
--
---
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/.
--------------040805040107000500000007
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/15/13 9:34 PM,
<a class="moz-txt-link-abbreviated" href="mailto:corentin.schreiber@cea.fr">corentin.schreiber@cea.fr</a> wrote:<br>
</div>
<blockquote
cite="mid:88f5c95b-96d8-435b-ab68-b6d953d8b979@isocpp.org"
type="cite">
<pre wrap="">Hello,
I have encountered a situation where the wording for [dcl.init.aggr] seems
too restrictive, and I was wondering if it would be possible to change it.
Maybe this concept already exists in the norm, but let's define an "empty"
class as a trivial class having no member variable, no (virtual?) member
functions and no non-empty base class.
I suggest that aggregates can have base classes provided that they are
empty.</pre>
</blockquote>
<br>
The concept of an empty class already exists as part of the
specification of the standard layout property, where they are
allowed as bases.<br>
<br>
It's also available as the type trait std::is_empty which is true
for conditions similar to what you mention:<br>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="page" title="Page 600">
<div class="section">
<div class="layoutArea">
<div class="column">
<p><span style="font-size: 10.000000pt; font-family:
'LMMono10'">T </span><span style="font-size:
10.000000pt; font-family: 'LMRoman10'">is a class type,
but not a
union type, with no
non-static data members
other than bit-fields of
length 0, no virtual
member functions, no
virtual base classes, and
no base class </span><span style="font-size:
10.000000pt; font-family: 'LMMono10'">B </span><span
style="font-size: 10.000000pt; font-family: 'LMRoman10'">for
which
</span><span style="font-size: 10.000000pt; font-family:
'LMMono10'">is_empty<B>::value </span><span
style="font-size: 10.000000pt; font-family: 'LMRoman10'">is
false.
</span></p>
</div>
</div>
</div>
</div>
<title>C++ International Standard</title>
I think that allowing such bases for aggregates would be wonderful.
I seem to recall being annoyed by the restriction in the past.
Standard layout was introduced in C++11 so the empty base semantic
perhaps has yet to integrate fully into the language.<br>
<br>
Also, perhaps empty bases should be allowed for unions. The idea
just occurred to me; I haven't really considered this.<br>
<br>
</body>
</html>
<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 />
--------------040805040107000500000007--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 15 Dec 2013 16:51:50 +0200
Raw View
On 15 December 2013 16:18, David Krauss <potswa@gmail.com> wrote:
> On 12/15/13 9:34 PM, corentin.schreiber@cea.fr wrote:
>
> Hello,
>
> I have encountered a situation where the wording for [dcl.init.aggr] seems
> too restrictive, and I was wondering if it would be possible to change it.
> Maybe this concept already exists in the norm, but let's define an "empty"
> class as a trivial class having no member variable, no (virtual?) member
> functions and no non-empty base class.
> I suggest that aggregates can have base classes provided that they are
> empty.
>
>
> The concept of an empty class already exists as part of the specification of
> the standard layout property, where they are allowed as bases.
>
> It's also available as the type trait std::is_empty which is true for
> conditions similar to what you mention:
>
> T is a class type, but not a union type, with no non-static data members
> other than bit-fields of length 0, no virtual member functions, no virtual
> base classes, and no base class B for which is_empty<B>::value is false.
>
> I think that allowing such bases for aggregates would be wonderful. I seem
> to recall being annoyed by the restriction in the past. Standard layout was
> introduced in C++11 so the empty base semantic perhaps has yet to integrate
> fully into the language.
>
> Also, perhaps empty bases should be allowed for unions. The idea just
> occurred to me; I haven't really considered this.
I wouldn't fnd the following far-fetched:
struct B
{
int i;
int j;
};
struct D : B
{
};
D d{1,2};
Now, 'morally', D didn't really do anything that would make the combination
of D and B a non-aggregate. D could've held B as a member subobject(*)
and it would be able to aggegate-initialize the combination. It seems to me
we're treating base subobjects non-uniformally here.
(*) This is fine:
struct B
{
int i;
int j;
};
struct D
{
B b;
};
D d{1,2};
Alternatively, having an empty B as a data member works fine, the combination
is still an aggregate:
struct B {};
struct D
{
int i;
int j;
B b;
};
D d{1,2};
--
---
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: corentin.schreiber@cea.fr
Date: Sun, 15 Dec 2013 14:31:09 -0800 (PST)
Raw View
------=_Part_1596_29427726.1387146669740
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, December 15, 2013 3:51:50 PM UTC+1, Ville Voutilainen wrote:
>
> On 15 December 2013 16:18, David Krauss <pot...@gmail.com <javascript:>>
> wrote:
> > On 12/15/13 9:34 PM, corentin....@cea.fr <javascript:> wrote:
> >
> > Hello,
> >
> > I have encountered a situation where the wording for [dcl.init.aggr]
> seems
> > too restrictive, and I was wondering if it would be possible to change
> it.
> > Maybe this concept already exists in the norm, but let's define an
> "empty"
> > class as a trivial class having no member variable, no (virtual?) member
> > functions and no non-empty base class.
> > I suggest that aggregates can have base classes provided that they are
> > empty.
> >
> >
> > The concept of an empty class already exists as part of the
> specification of
> > the standard layout property, where they are allowed as bases.
> >
> > It's also available as the type trait std::is_empty which is true for
> > conditions similar to what you mention:
> >
> > T is a class type, but not a union type, with no non-static data members
> > other than bit-fields of length 0, no virtual member functions, no
> virtual
> > base classes, and no base class B for which is_empty<B>::value is false.
> >
> > I think that allowing such bases for aggregates would be wonderful. I
> seem
> > to recall being annoyed by the restriction in the past. Standard layout
> was
> > introduced in C++11 so the empty base semantic perhaps has yet to
> integrate
> > fully into the language.
> >
> > Also, perhaps empty bases should be allowed for unions. The idea just
> > occurred to me; I haven't really considered this.
>
>
> I wouldn't fnd the following far-fetched:
>
> struct B
> {
> int i;
> int j;
> };
>
> struct D : B
> {
> };
>
> D d{1,2};
>
> Now, 'morally', D didn't really do anything that would make the
> combination
> of D and B a non-aggregate. D could've held B as a member subobject(*)
> and it would be able to aggegate-initialize the combination. It seems to
> me
> we're treating base subobjects non-uniformally here.
>
> (*) This is fine:
>
> struct B
> {
> int i;
> int j;
> };
> struct D
> {
> B b;
> };
> D d{1,2};
>
> Alternatively, having an empty B as a data member works fine, the
> combination
> is still an aggregate:
>
> struct B {};
> struct D
> {
> int i;
> int j;
> B b;
> };
> D d{1,2};
>
So in other words, you actually suggest to go further and replace the "has
no base class" requirement by "either has no non-static data members in the
most derived class and at most one base class with non-static data members,
or has no base classes with non-static data members" (borrowed from
[class]/6, defining standard layout classes). I agree that is a more
uniform hence superior solution. Thank you David Krauss for pointing out
std::is_empty and standard layout classes, it is indeed very similar.
--
---
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_1596_29427726.1387146669740
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, December 15, 2013 3:51:50 PM UTC+1, Ville Vouti=
lainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 15 December 20=
13 16:18, David Krauss <<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"OM4Lc-110EcJ" onmousedown=3D"this.href=3D'javascript:';r=
eturn true;" onclick=3D"this.href=3D'javascript:';return true;">pot...@gmai=
l.com</a>> wrote:
<br>> On 12/15/13 9:34 PM, <a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"OM4Lc-110EcJ" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return true;">corentin=
.....@cea.fr</a> wrote:
<br>>
<br>> Hello,
<br>>
<br>> I have encountered a situation where the wording for [dcl.init.agg=
r] seems
<br>> too restrictive, and I was wondering if it would be possible to ch=
ange it.
<br>> Maybe this concept already exists in the norm, but let's define an=
"empty"
<br>> class as a trivial class having no member variable, no (virtual?) =
member
<br>> functions and no non-empty base class.
<br>> I suggest that aggregates can have base classes provided that they=
are
<br>> empty.
<br>>
<br>>
<br>> The concept of an empty class already exists as part of the specif=
ication of
<br>> the standard layout property, where they are allowed as bases.
<br>>
<br>> It's also available as the type trait std::is_empty which is true =
for
<br>> conditions similar to what you mention:
<br>>
<br>> T is a class type, but not a union type, with no non-static data m=
embers
<br>> other than bit-fields of length 0, no virtual member functions, no=
virtual
<br>> base classes, and no base class B for which is_empty<B>::val=
ue is false.
<br>>
<br>> I think that allowing such bases for aggregates would be wonderful=
.. I seem
<br>> to recall being annoyed by the restriction in the past. Standard l=
ayout was
<br>> introduced in C++11 so the empty base semantic perhaps has yet to =
integrate
<br>> fully into the language.
<br>>
<br>> Also, perhaps empty bases should be allowed for unions. The idea j=
ust
<br>> occurred to me; I haven't really considered this.
<br>
<br>
<br>I wouldn't fnd the following far-fetched:
<br>
<br>struct B
<br>{
<br> int i;
<br> int j;
<br>};
<br>
<br>struct D : B
<br>{
<br>};
<br>
<br>D d{1,2};
<br>
<br>Now, 'morally', D didn't really do anything that would make the combina=
tion
<br>of D and B a non-aggregate. D could've held B as a member subobject(*)
<br>and it would be able to aggegate-initialize the combination. It seems t=
o me
<br>we're treating base subobjects non-uniformally here.
<br>
<br>(*) This is fine:
<br>
<br>struct B
<br>{
<br> int i;
<br> int j;
<br>};
<br>struct D
<br>{
<br> B b;
<br>};
<br>D d{1,2};
<br>
<br>Alternatively, having an empty B as a data member works fine, the combi=
nation
<br>is still an aggregate:
<br>
<br>struct B {};
<br>struct D
<br>{
<br> int i;
<br> int j;
<br> B b;
<br>};
<br>D d{1,2};
<br></blockquote><div><br>So in other words, you actually suggest to go fur=
ther and replace the "has no base class" requirement by "either has no non-=
static data members in the most derived class and at most one base class wi=
th
non-static data members, or has no base classes with non-static data memb=
ers" (borrowed from [class]/6, defining standard layout classes). I agree t=
hat is a more uniform hence superior solution. Thank you David Krauss for p=
ointing out std::is_empty and standard layout classes, it is indeed very si=
milar.<br></div><mytubeelement data=3D"{"bundle":{"label_del=
imitor":":","percentage":"%","smart=
_buffer":"Smart Buffer","start_playing_when_buffered&qu=
ot;:"Start playing when buffered","sound":"Sound&q=
uot;,"desktop_notification":"Desktop Notification",&quo=
t;continuation_on_next_line":"-","loop":"Loop=
","only_notify":"Only Notify","estimated_time=
":"Estimated Time","global_preferences":"Glob=
al Preferences","no_notification_supported_on_your_browser":=
"No notification style supported on your browser version","v=
ideo_buffered":"Video Buffered","buffered":"B=
uffered","hyphen":"-","buffered_message"=
:"The video has been buffered as requested and is ready to play."=
,"not_supported":"Not Supported","on":"O=
n","off":"Off","click_to_enable_for_this_site=
":"Click to enable for this site","desktop_notification=
_denied":"You have denied permission for desktop notification for=
this site","notification_status_delimitor":";",&q=
uot;error":"Error","adblock_interferance_message":=
"Adblock (or similar extension) is known to interfere with SmartVideo.=
Please add this url to adblock whitelist.","calculating":&q=
uot;Calculating","waiting":"Waiting","will_st=
art_buffering_when_initialized":"Will start buffering when initia=
lized","will_start_playing_when_initialized":"Will star=
t playing when initialized","completed":"Completed"=
;,"buffering_stalled":"Buffering is stalled. Will stop."=
;,"stopped":"Stopped","hr":"Hr",&qu=
ot;min":"Min","sec":"Sec","any_mome=
nt":"Any Moment","popup_donate_to":"Donate to=
","extension_id":null},"prefs":{"desktopNotif=
ication":true,"soundNotification":false,"logLevel"=
:0,"enable":true,"loop":false,"hidePopup":fal=
se,"autoPlay":false,"autoBuffer":false,"autoPlayOn=
Buffer":false,"autoPlayOnBufferPercentage":42,"autoPlay=
OnSmartBuffer":true,"quality":"default","fshd=
":false,"onlyNotification":true,"enableFullScreen"=
:true,"saveBandwidth":false,"hideAnnotations":true,&quo=
t;turnOffPagedBuffering":true}}" event=3D"preferencesUpdated" id=3D"my=
TubeRelayElementToPage"></mytubeelement><mytubeelement data=3D"{"loadB=
undle":true}" event=3D"relayPrefs" id=3D"myTubeRelayElementToTab"></my=
tubeelement></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 />
------=_Part_1596_29427726.1387146669740--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 16 Dec 2013 06:36:25 +0800
Raw View
On 12/15/13 9:51 PM, Ville Voutilainen wrote:
> On 15 December 2013 15:34, <corentin.schreiber@cea.fr> wrote:
>> But this is wrong for obvious reasons. Even if trivial:
>>
>> it is tedious to write if the class has many data members, and also implies
>> the declaration of a default constructor,
>> it is tedious to maintain, as adding a new data member also implies
>> modifying the constructor,
>> it is error prone, as one could easily do the initialization wrong (by
>> missing a variable for example).
>>
>> I could not find any proposal that would already address this issue. Does
>> this seem reasonable to you?
>
> I wouldn't mind being able to do it, but perhaps it's targeting a rather narrow
> case. You can make sure that you don't miss initializations by using non-static
> data member initializers, which are now allowed for aggregates.
>
I think he's referring to duplicating the aggregate initialization
semantics, which at a minimum demands declaration of a constructor with
a parameter for each nonstatic data member.
Aggregate initialization allows omission of trailing members though, so
each constructor parameter should get a default argument of {}.
However, this idiom is imperfect because copy-list-initialization from
an empty list requires a non-explicit default constructor:
1. Each parameter must have a non-explicit default constructor to be
used with {}, or else you have to manually write = member_type(), which
is copy initialization and relies on copy elision. So the requirement is
either implicit default constructible or move constructible.
2. If the would-be aggregate constructor is implicit, it will perform
conversion unlike aggregate semantics. If it is explicit, it will not
work with copy-list-initialization. Implicit constructors for N != 1
arguments and explicit for N == 1 provides the best fidelity, but you
cannot emulate an aggregate and initialize from a one-element
braced-init-list without allowing implicit conversion.
Aggregate semantics are very nice so it would be a plus to support
migration from an aggregate to some constructor idiom without any
knock-on effects.
--
---
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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 16 Dec 2013 00:59:31 +0200
Raw View
On 16 December 2013 00:31, <corentin.schreiber@cea.fr> wrote:
> On Sunday, December 15, 2013 3:51:50 PM UTC+1, Ville Voutilainen wrote:
>>
>> On 15 December 2013 16:18, David Krauss <pot...@gmail.com> wrote:
>> > On 12/15/13 9:34 PM, corentin....@cea.fr wrote:
>> >
>> > Hello,
>> >
>> > I have encountered a situation where the wording for [dcl.init.aggr]
>> > seems
>> > too restrictive, and I was wondering if it would be possible to change
>> > it.
>> > Maybe this concept already exists in the norm, but let's define an
>> > "empty"
>> > class as a trivial class having no member variable, no (virtual?) member
>> > functions and no non-empty base class.
>> > I suggest that aggregates can have base classes provided that they are
>> > empty.
>> >
>> >
>> > The concept of an empty class already exists as part of the
>> > specification of
>> > the standard layout property, where they are allowed as bases.
>> >
>> > It's also available as the type trait std::is_empty which is true for
>> > conditions similar to what you mention:
>> >
>> > T is a class type, but not a union type, with no non-static data members
>> > other than bit-fields of length 0, no virtual member functions, no
>> > virtual
>> > base classes, and no base class B for which is_empty<B>::value is false.
>> >
>> > I think that allowing such bases for aggregates would be wonderful. I
>> > seem
>> > to recall being annoyed by the restriction in the past. Standard layout
>> > was
>> > introduced in C++11 so the empty base semantic perhaps has yet to
>> > integrate
>> > fully into the language.
>> >
>> > Also, perhaps empty bases should be allowed for unions. The idea just
>> > occurred to me; I haven't really considered this.
>>
>>
>> I wouldn't fnd the following far-fetched:
>>
>> struct B
>> {
>> int i;
>> int j;
>> };
>>
>> struct D : B
>> {
>> };
>>
>> D d{1,2};
>>
>> Now, 'morally', D didn't really do anything that would make the
>> combination
>> of D and B a non-aggregate. D could've held B as a member subobject(*)
>> and it would be able to aggegate-initialize the combination. It seems to
>> me
>> we're treating base subobjects non-uniformally here.
>>
>> (*) This is fine:
>>
>> struct B
>> {
>> int i;
>> int j;
>> };
>> struct D
>> {
>> B b;
>> };
>> D d{1,2};
>>
>> Alternatively, having an empty B as a data member works fine, the
>> combination
>> is still an aggregate:
>>
>> struct B {};
>> struct D
>> {
>> int i;
>> int j;
>> B b;
>> };
>> D d{1,2};
>
>
> So in other words, you actually suggest to go further and replace the "has
> no base class" requirement by "either has no non-static data members in the
> most derived class and at most one base class with non-static data members,
> or has no base classes with non-static data members" (borrowed from
> [class]/6, defining standard layout classes). I agree that is a more uniform
> hence superior solution. Thank you David Krauss for pointing out
> std::is_empty and standard layout classes, it is indeed very similar.
To clarify: I would strive for allowing aggregate initialization of
anything that is
standard-layout and accessible, including
struct B
{
protected:
int i;
int j;
};
struct D : B
{
D() : B{1, 2} {} // sure, why not?
};
struct B
{
friend class D;
private:
int i;
int j;
};
struct D : B
{
D() : B{1, 2} {} // sure, why not?
};
Even further, I don't see why we should necessarily stop there; the restriction
that aggregates or standard-layout types can't have virtual functions leads to
a situation where aggregate initialization can't be used for a type that has
virtual functions. That seems overly restrictive to me. Aggregate initialization
runs arbitrarily complex code for aggregates that have non-trivial members
or NSDMIs, I find it hard to reason why it couldn't initialize a virtual table.
--
---
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: David Krauss <potswa@gmail.com>
Date: Mon, 16 Dec 2013 07:12:59 +0800
Raw View
On 12/16/13 6:59 AM, Ville Voutilainen wrote:
> Even further, I don't see why we should necessarily stop there; the
> restriction that aggregates or standard-layout types can't have
> virtual functions leads to a situation where aggregate initialization
> can't be used for a type that has virtual functions. That seems overly
> restrictive to me. Aggregate initialization runs arbitrarily complex
> code for aggregates that have non-trivial members or NSDMIs, I find it
> hard to reason why it couldn't initialize a virtual table.
For that matter, access protected NSDMs with initializers could be allowed.
In C++03 aggregates were a superset of POD classes, but in C++11 they
have been divorced and aggregates are only distinguished by allowing
aggregate initialization.
Another inconsistency of aggregates vs. constructors is compatibility
with inheriting constructors. This would be exacerbated if inheriting
aggregate initialization were allowed by other means.
--
---
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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 16 Dec 2013 01:59:00 +0200
Raw View
On 16 December 2013 01:12, David Krauss <potswa@gmail.com> wrote:
> On 12/16/13 6:59 AM, Ville Voutilainen wrote:
>>
>> Even further, I don't see why we should necessarily stop there; the
>> restriction that aggregates or standard-layout types can't have virtual
>> functions leads to a situation where aggregate initialization can't be used
>> for a type that has virtual functions. That seems overly restrictive to me.
>> Aggregate initialization runs arbitrarily complex code for aggregates that
>> have non-trivial members or NSDMIs, I find it hard to reason why it couldn't
>> initialize a virtual table.
>
>
> For that matter, access protected NSDMs with initializers could be allowed.
Sure, since once you have access and can aggregate-initialize, you can also
omit initializers just like current aggregates with NSDMIs allow you to do,
so that sounds very much like a natural extension.
> Another inconsistency of aggregates vs. constructors is compatibility with
> inheriting constructors. This would be exacerbated if inheriting aggregate
> initialization were allowed by other means.
I'm not sure I know what you mean here, got an example?
--
---
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: David Krauss <potswa@gmail.com>
Date: Mon, 16 Dec 2013 08:52:38 +0800
Raw View
On 12/16/13 7:59 AM, Ville Voutilainen wrote:
> On 16 December 2013 01:12, David Krauss <potswa@gmail.com> wrote:
>> Another inconsistency of aggregates vs. constructors is compatibility with
>> inheriting constructors. This would be exacerbated if inheriting aggregate
>> initialization were allowed by other means.
>
> I'm not sure I know what you mean here, got an example?
>
template< typename basis >
struct adaptor : basis {
#if INHERIT
using basis::basis;
#endif
friend bool operator < ( adaptor const & lhs, adaptor const & rhs );
};
struct intpair { int a, b; }
adaptor< std::pair< int > > x { 1, 2 }; // OK iff INHERIT
adaptor< inpair > y { 1, 2 }; // OK per proposal iff ! INHERIT?
An adaptor or veneer will often inherit constructors. Inheriting
constructors from an aggregate is syntactically valid but has no effect,
since implicitly declared constructors are excluded. The proposal of
aggregate-initializing the base would apply if constructors were not
inherited. Does it apply if constructors are inherited?
My first thought was that the inheriting constructor declaration would
make the derived class non-aggregate. But on second thought, if no
constructors are inherited, then there are no constructor declarations,
so it remains a candidate as an aggregate.
Furthermore, inherited constructors are implicitly defined, not
user-provided, so a nontrivial inheriting constructor declaration also
does not prevent aggregate-ness. Therefore a non-empty base of an
aggregate would need to be an aggregate to exclude user-provided
constructors, which standard layout yet allows. (But that's probably the
most natural way of specifying the feature anyway.)
TL;DR: there doesn't really appear to be an interaction between
aggregate inheritance and inheriting constructors.
--
---
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: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 16 Dec 2013 03:02:34 +0200
Raw View
On 16 December 2013 02:52, David Krauss <potswa@gmail.com> wrote:
> On 12/16/13 7:59 AM, Ville Voutilainen wrote:
>>
>> On 16 December 2013 01:12, David Krauss <potswa@gmail.com> wrote:
>>>
>>> Another inconsistency of aggregates vs. constructors is compatibility
>>> with
>>> inheriting constructors. This would be exacerbated if inheriting
>>> aggregate
>>> initialization were allowed by other means.
>>
>>
>> I'm not sure I know what you mean here, got an example?
>>
>
> template< typename basis >
> struct adaptor : basis {
> #if INHERIT
> using basis::basis;
> #endif
> friend bool operator < ( adaptor const & lhs, adaptor const & rhs );
> };
>
> struct intpair { int a, b; }
>
> adaptor< std::pair< int > > x { 1, 2 }; // OK iff INHERIT
> adaptor< inpair > y { 1, 2 }; // OK per proposal iff ! INHERIT?
I would hope the latter is ok regardless of INHERIT, and does nothing
for a base aggregate or a standard-layout base that has no constructors.
> TL;DR: there doesn't really appear to be an interaction between aggregate
> inheritance and inheriting constructors.
Anyway, it's good to remember inheriting constructors too, as yet another
language facility with which this idea needs to work.
--
---
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: corentin.schreiber@cea.fr
Date: Mon, 20 Jan 2014 12:48:24 -0800 (PST)
Raw View
------=_Part_689_2399674.1390250904461
Content-Type: text/plain; charset=UTF-8
On Sunday, December 15, 2013 11:59:31 PM UTC+1, Ville Voutilainen wrote:
>
> On 16 December 2013 00:31, <corentin....@cea.fr <javascript:>> wrote:
> > On Sunday, December 15, 2013 3:51:50 PM UTC+1, Ville Voutilainen wrote:
> >>
> >> On 15 December 2013 16:18, David Krauss <pot...@gmail.com> wrote:
> >> > On 12/15/13 9:34 PM, corentin....@cea.fr wrote:
> >> >
> >> > Hello,
> >> >
> >> > I have encountered a situation where the wording for [dcl.init.aggr]
> >> > seems
> >> > too restrictive, and I was wondering if it would be possible to
> change
> >> > it.
> >> > Maybe this concept already exists in the norm, but let's define an
> >> > "empty"
> >> > class as a trivial class having no member variable, no (virtual?)
> member
> >> > functions and no non-empty base class.
> >> > I suggest that aggregates can have base classes provided that they
> are
> >> > empty.
> >> >
> >> >
> >> > The concept of an empty class already exists as part of the
> >> > specification of
> >> > the standard layout property, where they are allowed as bases.
> >> >
> >> > It's also available as the type trait std::is_empty which is true for
> >> > conditions similar to what you mention:
> >> >
> >> > T is a class type, but not a union type, with no non-static data
> members
> >> > other than bit-fields of length 0, no virtual member functions, no
> >> > virtual
> >> > base classes, and no base class B for which is_empty<B>::value is
> false.
> >> >
> >> > I think that allowing such bases for aggregates would be wonderful. I
> >> > seem
> >> > to recall being annoyed by the restriction in the past. Standard
> layout
> >> > was
> >> > introduced in C++11 so the empty base semantic perhaps has yet to
> >> > integrate
> >> > fully into the language.
> >> >
> >> > Also, perhaps empty bases should be allowed for unions. The idea just
> >> > occurred to me; I haven't really considered this.
> >>
> >>
> >> I wouldn't fnd the following far-fetched:
> >>
> >> struct B
> >> {
> >> int i;
> >> int j;
> >> };
> >>
> >> struct D : B
> >> {
> >> };
> >>
> >> D d{1,2};
> >>
> >> Now, 'morally', D didn't really do anything that would make the
> >> combination
> >> of D and B a non-aggregate. D could've held B as a member subobject(*)
> >> and it would be able to aggegate-initialize the combination. It seems
> to
> >> me
> >> we're treating base subobjects non-uniformally here.
> >>
> >> (*) This is fine:
> >>
> >> struct B
> >> {
> >> int i;
> >> int j;
> >> };
> >> struct D
> >> {
> >> B b;
> >> };
> >> D d{1,2};
> >>
> >> Alternatively, having an empty B as a data member works fine, the
> >> combination
> >> is still an aggregate:
> >>
> >> struct B {};
> >> struct D
> >> {
> >> int i;
> >> int j;
> >> B b;
> >> };
> >> D d{1,2};
> >
> >
> > So in other words, you actually suggest to go further and replace the
> "has
> > no base class" requirement by "either has no non-static data members in
> the
> > most derived class and at most one base class with non-static data
> members,
> > or has no base classes with non-static data members" (borrowed from
> > [class]/6, defining standard layout classes). I agree that is a more
> uniform
> > hence superior solution. Thank you David Krauss for pointing out
> > std::is_empty and standard layout classes, it is indeed very similar.
>
>
> To clarify: I would strive for allowing aggregate initialization of
> anything that is
> standard-layout and accessible, including
>
> struct B
> {
> protected:
> int i;
> int j;
> };
>
> struct D : B
> {
> D() : B{1, 2} {} // sure, why not?
> };
>
> struct B
> {
> friend class D;
> private:
> int i;
> int j;
> };
>
> struct D : B
> {
> D() : B{1, 2} {} // sure, why not?
> };
>
> Even further, I don't see why we should necessarily stop there; the
> restriction
> that aggregates or standard-layout types can't have virtual functions
> leads to
> a situation where aggregate initialization can't be used for a type that
> has
> virtual functions. That seems overly restrictive to me. Aggregate
> initialization
> runs arbitrarily complex code for aggregates that have non-trivial members
> or NSDMIs, I find it hard to reason why it couldn't initialize a virtual
> table.
>
Coming back to this suggestion, I agree on both points: 1) members need no
be
public (but need the same access scope, as for standard layout classes),
and 2)
aggregate classes can have virtual functions.
Regarding point 1), the rule of having all members in the same access scope
(public, protected or private) is necessary in order not to end up with
confusing
situations where the number of values in an initialization list depends on
the
scope. For example, if you have a case like:
struct A {
int i;
protected:
int j;
public:
int k;
}
Friend or derived classes could be allowed to initialize A like:
A a{/*i=*/1,/*j=*/2,/*k=*/3}; // case a)
On the other hand, in any other places you would only be able to initialize
the
public members as if the protected/private members did not exist, i.e.:
A a{/*i=*/1,/*k=*/3}; // case b)
I don't know if this is desirable. An alternative would be to only allow
aggregate initialization of the "most public" members (if, of course, they
are
accessible). In the example above, both cases a) and b) would thus be
identical in the sense that they would only be able to initialize public
members
"i" and "k". One drawback I can see with this solution is that adding a
single
public member to a class that previously had only private/protected members
changes completely the allowed initialization. I'm not sure this is a good
thing
either.
Another thing that comes to my mind, things would much simpler if we were
to allow designated initializers like in C:
A a{.i=0, .k=2}; // compiles everywhere
A a{.i=0, .j=1, .k=2}; // compiles within friend or derived classes
This syntax could be allowed for any class, regardless of its inheritance
chain
and of the type of is members, as far as I can tell. I see that this has
already
been proposed here:
https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ
It seems that they are only targeting aggregate types, so we might cooperate
to make things better in both worlds, since I'm sure they don't need the
current
restrictions of aggregate types and would beneficiate from relaxing these
as we
are discussing here.
As for point 2), correct me if I'm wrong, but aggregate classes are only
marked
as such to allow aggregate initialization, which is purely syntactic sugar.
Since
non static data members have to reside in a single class within the
inheritance
chain, there is no ambiguity with respect to how base classes are
initialized: if
they do not contain any data member then their initialization is trivial,
else the
initialization arguments are simply forwarded to them.
--
---
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_689_2399674.1390250904461
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, December 15, 2013 11:59:31 PM UTC+1, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 16 December 2=
013 00:31, <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"qe7bwzyHR-QJ" onmousedown=3D"this.href=3D'javascript:';return =
true;" onclick=3D"this.href=3D'javascript:';return true;">corentin....@cea.=
fr</a>> wrote:
<br>> On Sunday, December 15, 2013 3:51:50 PM UTC+1, Ville Voutilainen w=
rote:
<br>>>
<br>>> On 15 December 2013 16:18, David Krauss <<a>pot...@gmail.co=
m</a>> wrote:
<br>>> > On 12/15/13 9:34 PM, <a>corentin....@cea.fr</a> wrote:
<br>>> >
<br>>> > Hello,
<br>>> >
<br>>> > I have encountered a situation where the wording for [dcl=
..init.aggr]
<br>>> > seems
<br>>> > too restrictive, and I was wondering if it would be possi=
ble to change
<br>>> > it.
<br>>> > Maybe this concept already exists in the norm, but let's =
define an
<br>>> > "empty"
<br>>> > class as a trivial class having no member variable, no (v=
irtual?) member
<br>>> > functions and no non-empty base class.
<br>>> > I suggest that aggregates can have base classes provided =
that they are
<br>>> > empty.
<br>>> >
<br>>> >
<br>>> > The concept of an empty class already exists as part of t=
he
<br>>> > specification of
<br>>> > the standard layout property, where they are allowed as b=
ases.
<br>>> >
<br>>> > It's also available as the type trait std::is_empty which=
is true for
<br>>> > conditions similar to what you mention:
<br>>> >
<br>>> > T is a class type, but not a union type, with no non-stat=
ic data members
<br>>> > other than bit-fields of length 0, no virtual member func=
tions, no
<br>>> > virtual
<br>>> > base classes, and no base class B for which is_empty<B=
>::value is false.
<br>>> >
<br>>> > I think that allowing such bases for aggregates would be =
wonderful. I
<br>>> > seem
<br>>> > to recall being annoyed by the restriction in the past. S=
tandard layout
<br>>> > was
<br>>> > introduced in C++11 so the empty base semantic perhaps ha=
s yet to
<br>>> > integrate
<br>>> > fully into the language.
<br>>> >
<br>>> > Also, perhaps empty bases should be allowed for unions. T=
he idea just
<br>>> > occurred to me; I haven't really considered this.
<br>>>
<br>>>
<br>>> I wouldn't fnd the following far-fetched:
<br>>>
<br>>> struct B
<br>>> {
<br>>> int i;
<br>>> int j;
<br>>> };
<br>>>
<br>>> struct D : B
<br>>> {
<br>>> };
<br>>>
<br>>> D d{1,2};
<br>>>
<br>>> Now, 'morally', D didn't really do anything that would make th=
e
<br>>> combination
<br>>> of D and B a non-aggregate. D could've held B as a member subo=
bject(*)
<br>>> and it would be able to aggegate-initialize the combination. I=
t seems to
<br>>> me
<br>>> we're treating base subobjects non-uniformally here.
<br>>>
<br>>> (*) This is fine:
<br>>>
<br>>> struct B
<br>>> {
<br>>> int i;
<br>>> int j;
<br>>> };
<br>>> struct D
<br>>> {
<br>>> B b;
<br>>> };
<br>>> D d{1,2};
<br>>>
<br>>> Alternatively, having an empty B as a data member works fine, =
the
<br>>> combination
<br>>> is still an aggregate:
<br>>>
<br>>> struct B {};
<br>>> struct D
<br>>> {
<br>>> int i;
<br>>> int j;
<br>>> B b;
<br>>> };
<br>>> D d{1,2};
<br>>
<br>>
<br>> So in other words, you actually suggest to go further and replace =
the "has
<br>> no base class" requirement by "either has no non-static data membe=
rs in the
<br>> most derived class and at most one base class with non-static data=
members,
<br>> or has no base classes with non-static data members" (borrowed fro=
m
<br>> [class]/6, defining standard layout classes). I agree that is a mo=
re uniform
<br>> hence superior solution. Thank you David Krauss for pointing out
<br>> std::is_empty and standard layout classes, it is indeed very simil=
ar.
<br>
<br>
<br>To clarify: I would strive for allowing aggregate initialization of
<br>anything that is
<br>standard-layout and accessible, including
<br>
<br>struct B
<br>{
<br>protected:
<br> int i;
<br> int j;
<br>};
<br>
<br>struct D : B
<br>{
<br> D() : B{1, 2} {} // sure, why not?
<br>};
<br>
<br>struct B
<br>{
<br> friend class D;
<br>private:
<br> int i;
<br> int j;
<br>};
<br>
<br>struct D : B
<br>{
<br> D() : B{1, 2} {} // sure, why not?
<br>};
<br>
<br>Even further, I don't see why we should necessarily stop there; the res=
triction
<br>that aggregates or standard-layout types can't have virtual functions l=
eads to
<br>a situation where aggregate initialization can't be used for a type tha=
t has
<br>virtual functions. That seems overly restrictive to me. Aggregate initi=
alization
<br>runs arbitrarily complex code for aggregates that have non-trivial memb=
ers
<br>or NSDMIs, I find it hard to reason why it couldn't initialize a virtua=
l table.
<br></blockquote><div><br>Coming back to this suggestion, I agree on both p=
oints: 1) members need no be<br>public (but need the same access scope, as =
for standard layout classes), and 2)<br>aggregate classes can have virtual =
functions.<br><br>Regarding point 1), the rule of having all members in the=
same access scope<br>(public, protected or private) is necessary in order =
not to end up with confusing<br>situations where the number of values in an=
initialization list depends on the<br>scope. For example, if you have a ca=
se like:<br><br> struct A {<br> &n=
bsp; int i;<br> protected:<br> &nb=
sp; int j;<br> public:<br> &=
nbsp; int k;<br> }<br><br>F=
riend or derived classes could be allowed to initialize A like:<br><br>&nbs=
p; A a{/*i=3D*/1,/*j=3D*/2,/*k=3D*/3}; // case a)<br><br>On the=
other hand, in any other places you would only be able to initialize the<b=
r>public members as if the protected/private members did not exist, i.e.:<b=
r><br> A a{/*i=3D*/1,/*k=3D*/3}; // case b)<br><br>I don'=
t know if this is desirable. An alternative would be to only allow<br>aggre=
gate initialization of the "most public" members (if, of course, they are <=
br>accessible). In the example above, both cases a) and b) would thus be<br=
>identical in the sense that they would only be able to initialize public m=
embers<br>"i" and "k". One drawback I can see with this solution is that ad=
ding a single<br>public member to a class that previously had only private/=
protected members<br>changes completely the allowed initialization. I'm not=
sure this is a good thing<br>either.<br><br>Another thing that comes to my=
mind, things would much simpler if we were<br>to allow designated initiali=
zers like in C:<br><br> A a{.i=3D0, .k=3D2}; // compiles =
everywhere<br> A a{.i=3D0, .j=3D1, .k=3D2}; // compiles w=
ithin friend or derived classes<br><br>This syntax could be allowed for any=
class, regardless of its inheritance chain<br>and of the type of is member=
s, as far as I can tell. I see that this has already<br>been proposed here:=
<br>https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqK=
jKlRs/CGARpDJy9JsJ<br>It seems that they are only targeting aggregate types=
, so we might cooperate<br>to make things better in both worlds, since I'm =
sure they don't need the current<br>restrictions of aggregate types and wou=
ld beneficiate from relaxing these as we<br>are discussing here.<br><br>As =
for point 2), correct me if I'm wrong, but aggregate classes are only marke=
d<br>as such to allow aggregate initialization, which is purely syntactic s=
ugar. Since<br>non static data members have to reside in a single class wit=
hin the inheritance<br>chain, there is no ambiguity with respect to how bas=
e classes are initialized: if<br>they do not contain any data member then t=
heir initialization is trivial, else the <br>initialization arguments are s=
imply forwarded to them.<br></div><mytubeelement data=3D"{"bundle"=
;:{"label_delimitor":":","percentage":"%=
","smart_buffer":"Smart Buffer","start_playin=
g_when_buffered":"Start playing when buffered","sound&q=
uot;:"Sound","desktop_notification":"Desktop Notif=
ication","continuation_on_next_line":"-","loo=
p":"Loop","only_notify":"Only Notify",&q=
uot;estimated_time":"Estimated Time","global_preference=
s":"Global Preferences","no_notification_supported_on_y=
our_browser":"No notification style supported on your browser ver=
sion","video_buffered":"Video Buffered","buff=
ered":"Buffered","hyphen":"-","buff=
ered_message":"The video has been buffered as requested and is re=
ady to play.","not_supported":"Not Supported",&quo=
t;on":"On","off":"Off","click_to_en=
able_for_this_site":"Click to enable for this site","de=
sktop_notification_denied":"You have denied permission for deskto=
p notification for this site","notification_status_delimitor"=
;:";","error":"Error","adblock_interfera=
nce_message":"Adblock (or similar extension) is known to interfer=
e with SmartVideo. Please add this url to adblock whitelist.","ca=
lculating":"Calculating","waiting":"Waiting&q=
uot;,"will_start_buffering_when_initialized":"Will start buf=
fering when initialized","will_start_playing_when_initialized&quo=
t;:"Will start playing when initialized","completed":&q=
uot;Completed","buffering_stalled":"Buffering is stalle=
d. Will stop.","stopped":"Stopped","hr":=
"Hr","min":"Min","sec":"Sec&qu=
ot;,"any_moment":"Any Moment","popup_donate_to&quo=
t;:"Donate to","extension_id":null},"prefs":{=
"desktopNotification":true,"soundNotification":false,&q=
uot;logLevel":0,"enable":true,"loop":false,"h=
idePopup":false,"autoPlay":false,"autoBuffer":fals=
e,"autoPlayOnBuffer":false,"autoPlayOnBufferPercentage"=
:42,"autoPlayOnSmartBuffer":true,"quality":"defaul=
t","fshd":false,"onlyNotification":true,"enab=
leFullScreen":true,"saveBandwidth":false,"hideAnnotatio=
ns":true,"turnOffPagedBuffering":true}}" event=3D"preference=
sUpdated" id=3D"myTubeRelayElementToPage"></mytubeelement><mytubeelement da=
ta=3D"{"loadBundle":true}" event=3D"relayPrefs" id=3D"myTubeRelay=
ElementToTab"></mytubeelement></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 />
------=_Part_689_2399674.1390250904461--
.
Author: Daryle Walker <darylew@gmail.com>
Date: Wed, 22 Jan 2014 17:06:03 -0800 (PST)
Raw View
------=_Part_1947_23681563.1390439163409
Content-Type: text/plain; charset=UTF-8
On Monday, January 20, 2014 3:48:24 PM UTC-5, corentin....@cea.fr wrote:
>
> Another thing that comes to my mind, things would much simpler if we were
> to allow designated initializers like in C:
>
> A a{.i=0, .k=2}; // compiles everywhere
> A a{.i=0, .j=1, .k=2}; // compiles within friend or derived classes
>
> This syntax could be allowed for any class, regardless of its inheritance
> chain
> and of the type of is members, as far as I can tell. I see that this has
> already
> been proposed here:
>
> https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ
> It seems that they are only targeting aggregate types, so we might
> cooperate
> to make things better in both worlds, since I'm sure they don't need the
> current
> restrictions of aggregate types and would beneficiate from relaxing these
> as we
> are discussing here.
>
I'm the writer of that proposal, and I added trial prose about expanded
aggregates, based on this thread. But I'm going to undo that draft and
propose expanded aggregates separately, as doing them together showed that
the mix was a bad idea. The aggregate expansion prose mostly gets lost in
the designated initializer prose, except for the parts that stick out
badly. Both proposals will be independently based off the latest C++ draft,
and can't reference each other (yet).
Daryle W.
--
---
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_1947_23681563.1390439163409
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, January 20, 2014 3:48:24 PM UTC-5, corentin....=
@cea.fr wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Another th=
ing that comes to my mind, things would much simpler if we were<br>to allow=
designated initializers like in C:<br><br> A a{.i=3D0, .=
k=3D2}; // compiles everywhere<br> A a{.i=3D0, .j=3D1, .k=
=3D2}; // compiles within friend or derived classes<br><br>This syntax coul=
d be allowed for any class, regardless of its inheritance chain<br>and of t=
he type of is members, as far as I can tell. I see that this has already<br=
>been proposed here:<br><a onmousedown=3D"this.href=3D'https://groups.googl=
e.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ';retu=
rn true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/fo=
rum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ';return true;" href=3D"htt=
ps://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/C=
GARpDJy9JsJ" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/=
forum/#!msg/std-<wbr>proposals/IgDFqKjKlRs/<wbr>CGARpDJy9JsJ</a><br>It seem=
s that they are only targeting aggregate types, so we might cooperate<br>to=
make things better in both worlds, since I'm sure they don't need the curr=
ent<br>restrictions of aggregate types and would beneficiate from relaxing =
these as we<br>are discussing here.<br></div></div></blockquote><div><br></=
div><div>I'm the writer of that proposal, and I added trial prose abou=
t expanded aggregates, based on this thread. But I'm going to undo that dra=
ft and propose expanded aggregates separately, as doing them together =
showed that the mix was a bad idea. The aggregate expansion prose mostly ge=
ts lost in the designated initializer prose, except for the parts that stic=
k out badly. Both proposals will be independently based off the latest C++ =
draft, and can't reference each other (yet).</div><div><br></div><div>Daryl=
e W.</div><div><br></div></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 />
------=_Part_1947_23681563.1390439163409--
.
Author: Daryle Walker <darylew@gmail.com>
Date: Thu, 23 Jan 2014 01:15:11 -0800 (PST)
Raw View
------=_Part_3_22597956.1390468511894
Content-Type: text/plain; charset=UTF-8
On Wednesday, January 22, 2014 8:06:03 PM UTC-5, Daryle Walker wrote:
>
> On Monday, January 20, 2014 3:48:24 PM UTC-5, corentin....@cea.fr wrote:
>>
>> Another thing that comes to my mind, things would much simpler if we were
>> to allow designated initializers like in C:
>>
>> A a{.i=0, .k=2}; // compiles everywhere
>> A a{.i=0, .j=1, .k=2}; // compiles within friend or derived classes
>>
>> This syntax could be allowed for any class, regardless of its inheritance
>> chain
>> and of the type of is members, as far as I can tell. I see that this has
>> already
>> been proposed here:
>>
>> https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ
>> It seems that they are only targeting aggregate types, so we might
>> cooperate
>> to make things better in both worlds, since I'm sure they don't need the
>> current
>> restrictions of aggregate types and would beneficiate from relaxing these
>> as we
>> are discussing here.
>>
>
> I'm the writer of that proposal, and I added trial prose about expanded
> aggregates, based on this thread. But I'm going to undo that draft and
> propose expanded aggregates separately, as doing them together showed that
> the mix was a bad idea. The aggregate expansion prose mostly gets lost in
> the designated initializer prose, except for the parts that stick out
> badly. Both proposals will be independently based off the latest C++ draft,
> and can't reference each other (yet).
>
I've uploaded a draft proposal for expanded aggregates<http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/expanded-aggregate-proposal.html>
now.
Daryle W.
--
---
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_3_22597956.1390468511894
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, January 22, 2014 8:06:03 PM UTC-5, Daryle Wa=
lker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Monday, January=
20, 2014 3:48:24 PM UTC-5, <a>corentin....@cea.fr</a> wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;"><div dir=3D"ltr"><div>Another thing that comes to my mind, t=
hings would much simpler if we were<br>to allow designated initializers lik=
e in C:<br><br> A a{.i=3D0, .k=3D2}; // compiles everywhe=
re<br> A a{.i=3D0, .j=3D1, .k=3D2}; // compiles within fr=
iend or derived classes<br><br>This syntax could be allowed for any class, =
regardless of its inheritance chain<br>and of the type of is members, as fa=
r as I can tell. I see that this has already<br>been proposed here:<br><a o=
nmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!m=
sg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ';return true;" onclick=3D"this.hr=
ef=3D'https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDF=
qKjKlRs/CGARpDJy9JsJ';return true;" href=3D"https://groups.google.com/a/iso=
cpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/forum/#!msg/std-<wbr>proposa=
ls/IgDFqKjKlRs/<wbr>CGARpDJy9JsJ</a><br>It seems that they are only targeti=
ng aggregate types, so we might cooperate<br>to make things better in both =
worlds, since I'm sure they don't need the current<br>restrictions of aggre=
gate types and would beneficiate from relaxing these as we<br>are discussin=
g here.<br></div></div></blockquote><div><br></div><div>I'm the writer of t=
hat proposal, and I added trial prose about expanded aggregates, based=
on this thread. But I'm going to undo that draft and propose expanded aggr=
egates separately, as doing them together showed that the mix was a ba=
d idea. The aggregate expansion prose mostly gets lost in the designated in=
itializer prose, except for the parts that stick out badly. Both proposals =
will be independently based off the latest C++ draft, and can't reference e=
ach other (yet).<br></div></div></blockquote><div><br></div><div>I've uploa=
ded a <a href=3D"http://htmlpreview.github.io/?https://raw.github.com/CTMac=
User/multiarray-iso-proposal/master/expanded-aggregate-proposal.html">draft=
proposal for expanded aggregates</a> now.</div><div><br></div><div>Da=
ryle W.</div><div> </div></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 />
------=_Part_3_22597956.1390468511894--
.
Author: corentin.schreiber@cea.fr
Date: Thu, 23 Jan 2014 12:49:17 -0800 (PST)
Raw View
------=_Part_104_16381679.1390510157542
Content-Type: text/plain; charset=UTF-8
On Thursday, January 23, 2014 10:15:11 AM UTC+1, Daryle Walker wrote:
>
> On Wednesday, January 22, 2014 8:06:03 PM UTC-5, Daryle Walker wrote:
>>
>> On Monday, January 20, 2014 3:48:24 PM UTC-5, corentin....@cea.fr wrote:
>>>
>>> Another thing that comes to my mind, things would much simpler if we were
>>> to allow designated initializers like in C:
>>>
>>> A a{.i=0, .k=2}; // compiles everywhere
>>> A a{.i=0, .j=1, .k=2}; // compiles within friend or derived classes
>>>
>>> This syntax could be allowed for any class, regardless of its
>>> inheritance chain
>>> and of the type of is members, as far as I can tell. I see that this has
>>> already
>>> been proposed here:
>>>
>>> https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ
>>> It seems that they are only targeting aggregate types, so we might
>>> cooperate
>>> to make things better in both worlds, since I'm sure they don't need the
>>> current
>>> restrictions of aggregate types and would beneficiate from relaxing
>>> these as we
>>> are discussing here.
>>>
>>
>> I'm the writer of that proposal, and I added trial prose about expanded
>> aggregates, based on this thread. But I'm going to undo that draft and
>> propose expanded aggregates separately, as doing them together showed that
>> the mix was a bad idea. The aggregate expansion prose mostly gets lost in
>> the designated initializer prose, except for the parts that stick out
>> badly. Both proposals will be independently based off the latest C++ draft,
>> and can't reference each other (yet).
>>
>
> I've uploaded a draft proposal for expanded aggregates<http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/expanded-aggregate-proposal.html>
> now.
>
> Daryle W.
>
>
Great! Thank you.
I'm not an expert norm reader, but it looks like it takes into account most
of what has been said here so far.
The "set of source classes" is a good idea to make things simpler. Can you
clarify what you mean by a class "sourcing" another one?
Regarding your interrogation on the "most derived class", I may be wrong
but I think it actually refers to the class being tested for being standard
layout. The issue is that inherited members are also members of the tested
class, so simply saying "has no non-static data member" would prevent any
base class from having non-static data members as well, hence the emphasis
on "most derived". It should probably be read like "does not declare any
non-static data member", but I agree the wording is confusing.
Oh and my name is Corentin Schreiber, by the way.
--
---
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_104_16381679.1390510157542
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, January 23, 2014 10:15:11 AM UTC+1, Daryle Wa=
lker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On=
Wednesday, January 22, 2014 8:06:03 PM UTC-5, Daryle Walker wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1e=
x;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-styl=
e:solid"><div dir=3D"ltr">On Monday, January 20, 2014 3:48:24 PM UTC-5, <a>=
corentin....@cea.fr</a> wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);=
border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>Anothe=
r thing that comes to my mind, things would much simpler if we were<br>to a=
llow designated initializers like in C:<br><br> A a{.i=3D=
0, .k=3D2}; // compiles everywhere<br> A a{.i=3D0, .j=3D1=
, .k=3D2}; // compiles within friend or derived classes<br><br>This syntax =
could be allowed for any class, regardless of its inheritance chain<br>and =
of the type of is members, as far as I can tell. I see that this has alread=
y<br>been proposed here:<br><a href=3D"https://groups.google.com/a/isocpp.o=
rg/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ" target=3D"_blank" on=
mousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!ms=
g/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ';return true;" onclick=3D"this.hre=
f=3D'https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFq=
KjKlRs/CGARpDJy9JsJ';return true;">https://groups.google.com/a/<wbr>isocpp.=
org/forum/#!msg/std-<wbr>proposals/IgDFqKjKlRs/<wbr>CGARpDJy9JsJ</a><br>It =
seems that they are only targeting aggregate types, so we might cooperate<b=
r>to make things better in both worlds, since I'm sure they don't need the =
current<br>restrictions of aggregate types and would beneficiate from relax=
ing these as we<br>are discussing here.<br></div></div></blockquote><div><b=
r></div><div>I'm the writer of that proposal, and I added trial prose =
about expanded aggregates, based on this thread. But I'm going to undo that=
draft and propose expanded aggregates separately, as doing them toget=
her showed that the mix was a bad idea. The aggregate expansion prose mostl=
y gets lost in the designated initializer prose, except for the parts that =
stick out badly. Both proposals will be independently based off the latest =
C++ draft, and can't reference each other (yet).<br></div></div></blockquot=
e><div><br></div><div>I've uploaded a <a href=3D"http://htmlpreview.github.=
io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/expande=
d-aggregate-proposal.html" target=3D"_blank" onmousedown=3D"this.href=3D'ht=
tp://www.google.com/url?q\75http%3A%2F%2Fhtmlpreview.github.io%2F%3Fhttps%3=
A%2F%2Fraw.github.com%2FCTMacUser%2Fmultiarray-iso-proposal%2Fmaster%2Fexpa=
nded-aggregate-proposal.html\46sa\75D\46sntz\0751\46usg\75AFQjCNETF0wyB7UFs=
YlgcBGvmjHu87Gpgw';return true;" onclick=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fhtmlpreview.github.io%2F%3Fhttps%3A%2F%2Fraw.githu=
b.com%2FCTMacUser%2Fmultiarray-iso-proposal%2Fmaster%2Fexpanded-aggregate-p=
roposal.html\46sa\75D\46sntz\0751\46usg\75AFQjCNETF0wyB7UFsYlgcBGvmjHu87Gpg=
w';return true;">draft proposal for expanded aggregates</a> now.</div>=
<div><br></div><div>Daryle W.</div><div> </div></div></blockquote><div=
><br>Great! Thank you.<br>I'm not an expert norm reader, but it looks like =
it takes into account most of what has been said here so far.<br><br>The "s=
et of source classes" is a good idea to make things simpler. Can you clarif=
y what you mean by a class "sourcing" another one?<br><br>Regarding your in=
terrogation on the "most derived class", I may be wrong but I think it actu=
ally refers to the class being tested for being standard layout. The issue =
is that inherited members are also members of the tested class, so simply s=
aying "has no non-static data member" would prevent any base class from hav=
ing non-static data members as well, hence the emphasis on "most derived". =
It should probably be read like "does not declare any non-static data membe=
r", but I agree the wording is confusing.<br><br>Oh and my name is Corentin=
Schreiber, by the way.<br></div><mytubeelement data=3D"{"bundle"=
:{"label_delimitor":":","percentage":"%&=
quot;,"smart_buffer":"Smart Buffer","start_playing=
_when_buffered":"Start playing when buffered","sound&qu=
ot;:"Sound","desktop_notification":"Desktop Notifi=
cation","continuation_on_next_line":"-","loop=
":"Loop","only_notify":"Only Notify",&qu=
ot;estimated_time":"Estimated Time","global_preferences=
":"Global Preferences","no_notification_supported_on_yo=
ur_browser":"No notification style supported on your browser vers=
ion","video_buffered":"Video Buffered","buffe=
red":"Buffered","hyphen":"-","buffe=
red_message":"The video has been buffered as requested and is rea=
dy to play.","not_supported":"Not Supported","=
;on":"On","off":"Off","click_to_ena=
ble_for_this_site":"Click to enable for this site","des=
ktop_notification_denied":"You have denied permission for desktop=
notification for this site","notification_status_delimitor"=
:";","error":"Error","adblock_interferan=
ce_message":"Adblock (or similar extension) is known to interfere=
with SmartVideo. Please add this url to adblock whitelist.","cal=
culating":"Calculating","waiting":"Waiting&qu=
ot;,"will_start_buffering_when_initialized":"Will start buff=
ering when initialized","will_start_playing_when_initialized"=
;:"Will start playing when initialized","completed":&qu=
ot;Completed","buffering_stalled":"Buffering is stalled=
.. Will stop.","stopped":"Stopped","hr":&=
quot;Hr","min":"Min","sec":"Sec&quo=
t;,"any_moment":"Any Moment","popup_donate_to"=
;:"Donate to","extension_id":null},"prefs":{&=
quot;desktopNotification":true,"soundNotification":false,&qu=
ot;logLevel":0,"enable":true,"loop":false,"hi=
dePopup":false,"autoPlay":false,"autoBuffer":false=
,"autoPlayOnBuffer":false,"autoPlayOnBufferPercentage":=
42,"autoPlayOnSmartBuffer":true,"quality":"default=
","fshd":false,"onlyNotification":true,"enabl=
eFullScreen":true,"saveBandwidth":false,"hideAnnotation=
s":true,"turnOffPagedBuffering":true}}" event=3D"preferences=
Updated" id=3D"myTubeRelayElementToPage"></mytubeelement><mytubeelement dat=
a=3D"{"loadBundle":true}" event=3D"relayPrefs" id=3D"myTubeRelayE=
lementToTab"></mytubeelement></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 />
------=_Part_104_16381679.1390510157542--
.
Author: Daryle Walker <darylew@gmail.com>
Date: Fri, 24 Jan 2014 13:22:20 -0500
Raw View
--e89a8f502fa04bb76e04f0bb700e
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jan 23, 2014 at 3:49 PM, <corentin.schreiber@cea.fr> wrote:
> On Thursday, January 23, 2014 10:15:11 AM UTC+1, Daryle Walker wrote:
>>
>> On Wednesday, January 22, 2014 8:06:03 PM UTC-5, Daryle Walker wrote:
>>>
>>> On Monday, January 20, 2014 3:48:24 PM UTC-5, corentin....@cea.fr wrote:
>>>>
>>>> Another thing that comes to my mind, things would much simpler if we
>>>> were
>>>> to allow designated initializers like in C:
>>>>
>>>> A a{.i=0, .k=2}; // compiles everywhere
>>>> A a{.i=0, .j=1, .k=2}; // compiles within friend or derived classes
>>>>
>>>> This syntax could be allowed for any class, regardless of its
>>>> inheritance chain
>>>> and of the type of is members, as far as I can tell. I see that this
>>>> has already
>>>> been proposed here:
>>>> https://groups.google.com/a/isocpp.org/forum/#!msg/std-
>>>> proposals/IgDFqKjKlRs/CGARpDJy9JsJ
>>>> It seems that they are only targeting aggregate types, so we might
>>>> cooperate
>>>> to make things better in both worlds, since I'm sure they don't need
>>>> the current
>>>> restrictions of aggregate types and would beneficiate from relaxing
>>>> these as we
>>>> are discussing here.
>>>>
>>>
>>> I'm the writer of that proposal, and I added trial prose about expanded
>>> aggregates, based on this thread. But I'm going to undo that draft and
>>> propose expanded aggregates separately, as doing them together showed that
>>> the mix was a bad idea. The aggregate expansion prose mostly gets lost in
>>> the designated initializer prose, except for the parts that stick out
>>> badly. Both proposals will be independently based off the latest C++ draft,
>>> and can't reference each other (yet).
>>>
>>
>> I've uploaded a draft proposal for expanded aggregates<http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/expanded-aggregate-proposal.html>
>> now.
>>
>> Daryle W.
>>
>>
>
> Great! Thank you.
> I'm not an expert norm reader, but it looks like it takes into account
> most of what has been said here so far.
>
> The "set of source classes" is a good idea to make things simpler. Can you
> clarify what you mean by a class "sourcing" another one?
>
If aggregate class A sources aggregate class B, then B contains non-static
data members and A references those same members during its initialization.
Note that A and B may be the same type. If A's set of source classes is
empty, A is still a single-source class and sources itself, so I wouldn't
have to make a special case for completely empty classes. I did not define
"sourcing;" I don't know if I should formally define it or if I should
rephrase those parts of the prose. ("Sourcing" assumes the class is
single-source since its meaning is ambiguous when the set of source class
has more than one element.)
> Regarding your interrogation on the "most derived class", I may be wrong
> but I think it actually refers to the class being tested for being standard
> layout. The issue is that inherited members are also members of the tested
> class, so simply saying "has no non-static data member" would prevent any
> base class from having non-static data members as well, hence the emphasis
> on "most derived". It should probably be read like "does not declare any
> non-static data member", but I agree the wording is confusing.
>
I think the term "most derived class" means the object you have a reference
to is not of the declared class, but it's actually a base-class sub-object
and the full object is of a derived class (from the declared class). The
section about standard-layout classes examine classes as themselves and not
with any associated objects, so the term "most derived class" is
inappropriate in that context. I think an editorial bug should be filed on
it. (But my change obliterates that bug anyway.)
If a class inherits multiply from a base class, and at least one of those
inheritances is not virtual, then the class has multiple copies of that
base class sub-object, and therefore multiple-copies of that base class'
non-static data members. Such a class can't be single-source, since you
couldn't describe all members of all copies in a single aggregate
initialization (without complicating the syntax with a new separator). I
wonder if the writers of the standard-layout section didn't really mean
single-source instead of at-most-one-source-class.
--
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT gmail DOT com
--
---
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/.
--e89a8f502fa04bb76e04f0bb700e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jan 23, 2014 at 3:49 PM, <span dir=3D"ltr"><<a href=3D"mailto:coren=
tin.schreiber@cea.fr" target=3D"_blank">corentin.schreiber@cea.fr</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im">On Thursd=
ay, January 23, 2014 10:15:11 AM UTC+1, Daryle Walker wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex">
<div dir=3D"ltr">On Wednesday, January 22, 2014 8:06:03 PM UTC-5, Daryle Wa=
lker wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1=
px;border-left-style:solid">
<div dir=3D"ltr">On Monday, January 20, 2014 3:48:24 PM UTC-5, <a>corentin.=
....@cea.fr</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-le=
ft-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div>Another thing that comes to my mind, things would muc=
h simpler if we were<br>to allow designated initializers like in C:<br><br>=
=A0=A0=A0 A a{.i=3D0, .k=3D2}; // compiles everywhere<br>=A0=A0=A0 A a{.i=
=3D0, .j=3D1, .k=3D2}; // compiles within friend or derived classes<br>
<br>This syntax could be allowed for any class, regardless of its inheritan=
ce chain<br>and of the type of is members, as far as I can tell. I see that=
this has already<br>been proposed here:<br><a href=3D"https://groups.googl=
e.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ" targ=
et=3D"_blank">https://groups.google.com/a/<u></u>isocpp.org/forum/#!msg/std=
-<u></u>proposals/IgDFqKjKlRs/<u></u>CGARpDJy9JsJ</a><br>
It seems that they are only targeting aggregate types, so we might cooperat=
e<br>to make things better in both worlds, since I'm sure they don'=
t need the current<br>restrictions of aggregate types and would beneficiate=
from relaxing these as we<br>
are discussing here.<br></div></div></blockquote><div><br></div><div>I'=
m the writer of that proposal,=A0and I added trial prose about expanded agg=
regates, based on this thread. But I'm going to undo that draft and pro=
pose expanded aggregates=A0separately, as doing them together showed that t=
he mix was a bad idea. The aggregate expansion prose mostly gets lost in th=
e designated initializer prose, except for the parts that stick out badly. =
Both proposals will be independently based off the latest C++ draft, and ca=
n't reference each other (yet).<br>
</div></div></blockquote><div><br></div><div>I've uploaded a <a href=3D=
"http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-=
iso-proposal/master/expanded-aggregate-proposal.html" target=3D"_blank">dra=
ft proposal for expanded aggregates</a>=A0now.</div>
<div><br></div><div>Daryle W.</div><div>=A0</div></div></blockquote></div><=
div><br>Great! Thank you.<br>I'm not an expert norm reader, but it look=
s like it takes into account most of what has been said here so far.<br><br=
>
The "set of source classes" is a good idea to make things simpler=
.. Can you clarify what you mean by a class "sourcing" another one=
?<br></div></div></blockquote><div><br></div><div>If aggregate class A sour=
ces aggregate class B, then B contains non-static data members and A refere=
nces those same members during its initialization. Note that A and B may be=
the same type. If A's set of source classes is empty, A is still a sin=
gle-source class and sources itself, so I wouldn't have to make a speci=
al case for completely empty classes.=A0 I did not define "sourcing;&q=
uot; I don't know if I should formally define it or if I should rephras=
e those parts of the prose. ("Sourcing" assumes the class is sing=
le-source since its meaning is ambiguous when the set of source class has m=
ore than one element.)<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Re=
garding your interrogation on the "most derived class", I may be =
wrong but I think it actually refers to the class being tested for being st=
andard layout. The issue is that inherited members are also members of the =
tested class, so simply saying "has no non-static data member" wo=
uld prevent any base class from having non-static data members as well, hen=
ce the emphasis on "most derived". It should probably be read lik=
e "does not declare any non-static data member", but I agree the =
wording is confusing.<br>
</div></div></blockquote><div><br></div><div>I think the term "most de=
rived class" means the object you have a reference to is not of the de=
clared class, but it's actually a base-class sub-object and the full ob=
ject is of a derived class (from the declared class). The section about sta=
ndard-layout classes examine classes as themselves and not with any associa=
ted objects, so the term "most derived class" is inappropriate in=
that context. I think an editorial bug should be filed on it. (But my chan=
ge obliterates that bug anyway.)<br>
<br></div><div>If a class inherits multiply from a base class, and at least=
one of those inheritances is not virtual, then the class has multiple copi=
es of that base class sub-object, and therefore multiple-copies of that bas=
e class' non-static data members. Such a class can't be single-sour=
ce, since you couldn't describe all members of all copies in a single a=
ggregate initialization (without complicating the syntax with a new separat=
or). I wonder if the writers of the standard-layout section didn't real=
ly mean single-source instead of at-most-one-source-class.<br>
</div></div><br>-- <br>Daryle Walker<br>Mac, Internet, and Video Game Junki=
e<br>darylew AT gmail DOT com<br><br>
</div></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 />
--e89a8f502fa04bb76e04f0bb700e--
.
Author: Daryle Walker <darylew@gmail.com>
Date: Fri, 24 Jan 2014 21:01:03 -0800 (PST)
Raw View
------=_Part_1224_14933343.1390626063110
Content-Type: text/plain; charset=UTF-8
On Thursday, January 23, 2014 4:15:11 AM UTC-5, Daryle Walker wrote:
>
> On Wednesday, January 22, 2014 8:06:03 PM UTC-5, Daryle Walker wrote:
>>
>> On Monday, January 20, 2014 3:48:24 PM UTC-5, corentin....@cea.fr wrote:
>>>
>>> Another thing that comes to my mind, things would much simpler if we were
>>> to allow designated initializers like in C:
>>>
>>> A a{.i=0, .k=2}; // compiles everywhere
>>> A a{.i=0, .j=1, .k=2}; // compiles within friend or derived classes
>>>
>>> This syntax could be allowed for any class, regardless of its
>>> inheritance chain
>>> and of the type of is members, as far as I can tell. I see that this has
>>> already
>>> been proposed here:
>>>
>>> https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ
>>> It seems that they are only targeting aggregate types, so we might
>>> cooperate
>>> to make things better in both worlds, since I'm sure they don't need the
>>> current
>>> restrictions of aggregate types and would beneficiate from relaxing
>>> these as we
>>> are discussing here.
>>>
>>
>> I'm the writer of that proposal, and I added trial prose about expanded
>> aggregates, based on this thread. But I'm going to undo that draft and
>> propose expanded aggregates separately, as doing them together showed that
>> the mix was a bad idea. The aggregate expansion prose mostly gets lost in
>> the designated initializer prose, except for the parts that stick out
>> badly. Both proposals will be independently based off the latest C++ draft,
>> and can't reference each other (yet).
>>
>
> I've uploaded a draft proposal for expanded aggregates<http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarray-iso-proposal/master/expanded-aggregate-proposal.html>
> now.
>
> Daryle W.
>
>
I uploaded a new version. It adds something I had in my original merged
aggregate/designated-initializer paper, but forgot to transfer. A (new
style) aggregate class that gets its data from a base class is essentially
a proxy for that base class. So when the base class is virtual, the
aggregate class that derives from it, when used as a direct base class
itself, has to have the same restrictions a virtual base class would have.
12.6.2/7 was already amended to say an aggregate base class that derives
from a virtual class is also its base-initializer ignored when the
constructor's class is not the most derived class.
12.6.2/5 is now amended that a constructor's base-initializer section gets
a duplicate member error is there's an initializer for a
data-bearing virtual base class and an aggregate direct base class that
also derives from the virtual base class (or two aggregate direct base
classes that derive from the same virtual base class).
struct A { int a, b = 1; };
struct B : public virtual A { };
struct C : protected virtual A { };
class E;
struct D : protected B, private C { friend class E; D(); };
class E : D { E(); };
The constructor of D can specify at most one of {A, B, C} as a base
initializer. Whichever one is chosen, the constructor of E will ignore it.
No matter if E's constructor explicitly calls D's constructor, E's
constructor must aggregate-initialize A if it doesn't want the A sub-object
default-initialized.
Daryle W.
--
---
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_1224_14933343.1390626063110
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, January 23, 2014 4:15:11 AM UTC-5, Daryle Wal=
ker wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Wednesday, Janua=
ry 22, 2014 8:06:03 PM UTC-5, Daryle Walker wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left=
-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: soli=
d;"><div dir=3D"ltr">On Monday, January 20, 2014 3:48:24 PM UTC-5, <a>coren=
tin....@cea.fr</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div=
>Another thing that comes to my mind, things would much simpler if we were<=
br>to allow designated initializers like in C:<br><br> A =
a{.i=3D0, .k=3D2}; // compiles everywhere<br> A a{.i=3D0,=
.j=3D1, .k=3D2}; // compiles within friend or derived classes<br><br>This =
syntax could be allowed for any class, regardless of its inheritance chain<=
br>and of the type of is members, as far as I can tell. I see that this has=
already<br>been proposed here:<br><a onmousedown=3D"this.href=3D'https://g=
roups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJ=
y9JsJ';return true;" onclick=3D"this.href=3D'https://groups.google.com/a/is=
ocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ';return true;" =
href=3D"https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/Ig=
DFqKjKlRs/CGARpDJy9JsJ" target=3D"_blank">https://groups.google.com/a/<wbr>=
isocpp.org/forum/#!msg/std-<wbr>proposals/IgDFqKjKlRs/<wbr>CGARpDJy9JsJ</a>=
<br>It seems that they are only targeting aggregate types, so we might coop=
erate<br>to make things better in both worlds, since I'm sure they don't ne=
ed the current<br>restrictions of aggregate types and would beneficiate fro=
m relaxing these as we<br>are discussing here.<br></div></div></blockquote>=
<div><br></div><div>I'm the writer of that proposal, and I added trial=
prose about expanded aggregates, based on this thread. But I'm going to un=
do that draft and propose expanded aggregates separately, as doing the=
m together showed that the mix was a bad idea. The aggregate expansion pros=
e mostly gets lost in the designated initializer prose, except for the part=
s that stick out badly. Both proposals will be independently based off the =
latest C++ draft, and can't reference each other (yet).<br></div></div></bl=
ockquote><div><br></div><div>I've uploaded a <a onmousedown=3D"this.href=3D=
'http://www.google.com/url?q\75http%3A%2F%2Fhtmlpreview.github.io%2F%3Fhttp=
s%3A%2F%2Fraw.github.com%2FCTMacUser%2Fmultiarray-iso-proposal%2Fmaster%2Fe=
xpanded-aggregate-proposal.html\46sa\75D\46sntz\0751\46usg\75AFQjCNETF0wyB7=
UFsYlgcBGvmjHu87Gpgw';return true;" onclick=3D"this.href=3D'http://www.goog=
le.com/url?q\75http%3A%2F%2Fhtmlpreview.github.io%2F%3Fhttps%3A%2F%2Fraw.gi=
thub.com%2FCTMacUser%2Fmultiarray-iso-proposal%2Fmaster%2Fexpanded-aggregat=
e-proposal.html\46sa\75D\46sntz\0751\46usg\75AFQjCNETF0wyB7UFsYlgcBGvmjHu87=
Gpgw';return true;" href=3D"http://htmlpreview.github.io/?https://raw.githu=
b.com/CTMacUser/multiarray-iso-proposal/master/expanded-aggregate-proposal.=
html" target=3D"_blank">draft proposal for expanded aggregates</a> now=
..</div><div><br></div><div>Daryle W.</div><div> </div></div></blockquo=
te><div><br></div><div>I uploaded a new version. It adds something I had in=
my original merged aggregate/designated-initializer paper, but forgot to t=
ransfer. A (new style) aggregate class that gets its data from a base class=
is essentially a proxy for that base class. So when the base class is virt=
ual, the aggregate class that derives from it, when used as a direct base c=
lass itself, has to have the same restrictions a virtual base class wo=
uld have.</div><div><br></div><div>12.6.2/7 was already amended to say an a=
ggregate base class that derives from a virtual class is also its base-init=
ializer ignored when the constructor's class is not the most derived class.=
</div><div><br></div><div>12.6.2/5 is now amended that a constructor's base=
-initializer section gets a duplicate member error is there's an initialize=
r for a data-bearing virtual base class and an aggregate direct base c=
lass that also derives from the virtual base class (or two aggregate direct=
base classes that derive from the same virtual base class).</div><div><br>=
</div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 1=
87); border-image: none; -ms-word-wrap: break-word; background-color: rgb(2=
50, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">struct</=
span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> A <=
/span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);"=
>{</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">=
</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);"=
>int</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);=
"> a</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102,=
0);">,</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, =
0);"> b </span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, =
102, 0);">=3D</span><span class=3D"styled-by-prettify" style=3D"color: rgb(=
0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(0=
, 102, 102);">1</span><span class=3D"styled-by-prettify" style=3D"color: rg=
b(102, 102, 0);">;</span><span class=3D"styled-by-prettify" style=3D"color:=
rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"color: =
rgb(102, 102, 0);">};</span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(0, 0, 0);"><br></span><span class=3D"styled-by-prettify" style=3D"c=
olor: rgb(0, 0, 136);">struct</span><span class=3D"styled-by-prettify" styl=
e=3D"color: rgb(0, 0, 0);"> B </span><span class=3D"styled-by-prettify" sty=
le=3D"color: rgb(102, 102, 0);">:</span><span class=3D"styled-by-prettify" =
style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" s=
tyle=3D"color: rgb(0, 0, 136);">public</span><span class=3D"styled-by-prett=
ify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(0, 0, 136);">virtual</span><span class=3D"styled-by=
-prettify" style=3D"color: rgb(0, 0, 0);"> A </span><span class=3D"styled-b=
y-prettify" style=3D"color: rgb(102, 102, 0);">{</span><span class=3D"style=
d-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled=
-by-prettify" style=3D"color: rgb(102, 102, 0);">};</span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br></span><span class=3D"=
styled-by-prettify" style=3D"color: rgb(0, 0, 136);">struct</span><span cla=
ss=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> C </span><span cl=
ass=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">:</span><span=
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span =
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">protected</sp=
an><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </spa=
n><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">virtu=
al</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);">=
A </span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, =
0);">{</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0=
);"> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102=
, 0);">};</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0=
, 0);"><br></span><span class=3D"styled-by-prettify" style=3D"color: rgb(0,=
0, 136);">class</span><span class=3D"styled-by-prettify" style=3D"color: r=
gb(0, 0, 0);"> E</span><span class=3D"styled-by-prettify" style=3D"color: r=
gb(102, 102, 0);">;</span><span class=3D"styled-by-prettify" style=3D"color=
: rgb(0, 0, 0);"><br></span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(0, 0, 136);">struct</span><span class=3D"styled-by-prettify" style=
=3D"color: rgb(0, 0, 0);"> D </span><span class=3D"styled-by-prettify" styl=
e=3D"color: rgb(102, 102, 0);">:</span><span class=3D"styled-by-prettify" s=
tyle=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" st=
yle=3D"color: rgb(0, 0, 136);">protected</span><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(0, 0, 0);"> B</span><span class=3D"styled-by-pre=
ttify" style=3D"color: rgb(102, 102, 0);">,</span><span class=3D"styled-by-=
prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"styled-by-p=
rettify" style=3D"color: rgb(0, 0, 136);">private</span><span class=3D"styl=
ed-by-prettify" style=3D"color: rgb(0, 0, 0);"> C </span><span class=3D"sty=
led-by-prettify" style=3D"color: rgb(102, 102, 0);">{</span><span class=3D"=
styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=3D"s=
tyled-by-prettify" style=3D"color: rgb(0, 0, 136);">friend</span><span clas=
s=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">class</span><span =
class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> E</span><span =
class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">;</span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> D</span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">();</spa=
n><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"> </span=
><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0);">};</=
span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0);"><br>=
</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136);">=
class</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0)=
;"> E </span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 10=
2, 0);">:</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0=
, 0);"> D </span><span class=3D"styled-by-prettify" style=3D"color: rgb(102=
, 102, 0);">{</span><span class=3D"styled-by-prettify" style=3D"color: rgb(=
0, 0, 0);"> E</span><span class=3D"styled-by-prettify" style=3D"color: rgb(=
102, 102, 0);">();</span><span class=3D"styled-by-prettify" style=3D"color:=
rgb(0, 0, 0);"> </span><span class=3D"styled-by-prettify" style=3D"color: =
rgb(102, 102, 0);">};</span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(0, 0, 0);"><br></span></div></code></div><br><div><br></div><div>Th=
e constructor of <font face=3D"courier new,monospace">D</font> can specify =
at most one of <font face=3D"courier new,monospace">{A, B, C}</font> as a b=
ase initializer. Whichever one is chosen, the constructor of <font face=3D"=
courier new,monospace">E</font> will ignore it. No matter if <font face=3D"=
courier new,monospace">E</font>'s constructor explicitly calls <font face=
=3D"courier new,monospace">D</font>'s constructor, <font face=3D"courier ne=
w,monospace">E</font>'s constructor must aggregate-initialize <font face=3D=
"courier new,monospace">A</font> if it doesn't want the <font face=3D"couri=
er new,monospace">A</font> sub-object default-initialized.</div><div><br></=
div><div>Daryle W.</div><div><br></div></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 />
------=_Part_1224_14933343.1390626063110--
.
Author: euloanty@live.com
Date: Sat, 25 Jan 2014 04:53:31 -0800 (PST)
Raw View
------=_Part_1485_16297189.1390654411966
Content-Type: text/plain; charset=UTF-8
Inheritance based polymorphic is bad. It just like "goto", "c-style-array".
It makes us difficult to manage resources, and make C++ slower and
difficult to use. Its implements still have problems
I think concept-based polymorphic is the true polymorphic.
I have put my sample on the skydrive .
*https://skydrive.live.com/redir?resid=FB612199F19B150B%21105*<https://skydrive.live.com/redir?resid=FB612199F19B150B%21105>
--
---
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_1485_16297189.1390654411966
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Inheritance based polymorphic is bad. It just like "g=
oto", "c-style-array".</div><div>It makes us difficult to manage resources,=
and make C++ slower and difficult to use. Its implements still have proble=
ms</div><div><br></div><div>I think concept-based polymorphic is the true p=
olymorphic.</div><div><div style=3D"color: rgb(0, 0, 0);">I have put my sam=
ple on the skydrive .</div><div style=3D"color: rgb(0, 0, 0);"><a tabi=
ndex=3D"-1" href=3D"https://skydrive.live.com/redir?resid=3DFB612199F19B150=
B%21105" target=3D"_parent"><u><font color=3D"#0066cc">https://skydrive.liv=
e.com/redir?resid=3DFB612199F19B150B%21105</font></u></a></div></div></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 />
------=_Part_1485_16297189.1390654411966--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Sat, 25 Jan 2014 06:34:57 -0800 (PST)
Raw View
------=_Part_102_14678661.1390660497923
Content-Type: text/plain; charset=UTF-8
This post is a nice proof why posting rights should be provided after
passing at least some basic programming AND English test.
On Saturday, 25 January 2014 13:53:31 UTC+1, eulo...@live.com wrote:
>
> Inheritance based polymorphic is bad. It just like "goto", "c-style-array".
> It makes us difficult to manage resources, and make C++ slower and
> difficult to use. Its implements still have problems
>
> I think concept-based polymorphic is the true polymorphic.
> I have put my sample on the skydrive .
> *https://skydrive.live.com/redir?resid=FB612199F19B150B%21105*<https://skydrive.live.com/redir?resid=FB612199F19B150B%21105>
>
--
---
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_102_14678661.1390660497923
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This post is a nice proof why posting rights should be pro=
vided after passing at least some basic programming AND English test.<br><b=
r>On Saturday, 25 January 2014 13:53:31 UTC+1, eulo...@live.com wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Inheritance =
based polymorphic is bad. It just like "goto", "c-style-array".</div><div>I=
t makes us difficult to manage resources, and make C++ slower and difficult=
to use. Its implements still have problems</div><div><br></div><div>I thin=
k concept-based polymorphic is the true polymorphic.</div><div><div style=
=3D"color:rgb(0,0,0)">I have put my sample on the skydrive .</div><div=
style=3D"color:rgb(0,0,0)"><a href=3D"https://skydrive.live.com/redir?resi=
d=3DFB612199F19B150B%21105" target=3D"_blank" onmousedown=3D"this.href=3D'h=
ttps://www.google.com/url?q\75https%3A%2F%2Fskydrive.live.com%2Fredir%3Fres=
id%3DFB612199F19B150B%2521105\46sa\75D\46sntz\0751\46usg\75AFQjCNHu4_zpWd0z=
ysc4nt9LnaTb1MqIBQ';return true;" onclick=3D"this.href=3D'https://www.googl=
e.com/url?q\75https%3A%2F%2Fskydrive.live.com%2Fredir%3Fresid%3DFB612199F19=
B150B%2521105\46sa\75D\46sntz\0751\46usg\75AFQjCNHu4_zpWd0zysc4nt9LnaTb1MqI=
BQ';return true;"><u><font color=3D"#0066cc">https://skydrive.live.com/<wbr=
>redir?resid=3DFB612199F19B150B%<wbr>21105</font></u></a></div></div></div>=
</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 />
------=_Part_102_14678661.1390660497923--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 5 Feb 2014 03:46:33 -0800 (PST)
Raw View
------=_Part_228_7190420.1391600793608
Content-Type: text/plain; charset=UTF-8
Supporting base classes without non-static data members and supporting
virtual functions seems simple.
Allowing initialization of base class members seems a bit fragile as you'd
depend on the order of a lot of definitions.
What about supporting classes with default constructors? The default
constructor could be run first after which public data members could be
initialized.
--
---
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_228_7190420.1391600793608
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Supporting base classes without non-static data members an=
d supporting virtual functions seems simple.<br><br>Allowing initialization=
of base class members seems a bit fragile as you'd depend on the order of =
a lot of definitions.<br>What about supporting classes with default constru=
ctors? The default constructor could be run first after which public data m=
embers could be initialized.<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 />
------=_Part_228_7190420.1391600793608--
.
Author: corentin.schreiber@cea.fr
Date: Wed, 27 Aug 2014 14:26:00 -0700 (PDT)
Raw View
------=_Part_5278_1606855940.1409174760681
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le samedi 25 janvier 2014 06:01:03 UTC+1, Daryle Walker a =C3=A9crit :
>
> On Thursday, January 23, 2014 4:15:11 AM UTC-5, Daryle Walker wrote:
>>
>> On Wednesday, January 22, 2014 8:06:03 PM UTC-5, Daryle Walker wrote:
>>>
>>> On Monday, January 20, 2014 3:48:24 PM UTC-5, corentin....@cea.fr wrote=
:
>>>>
>>>> Another thing that comes to my mind, things would much simpler if we=
=20
>>>> were
>>>> to allow designated initializers like in C:
>>>>
>>>> A a{.i=3D0, .k=3D2}; // compiles everywhere
>>>> A a{.i=3D0, .j=3D1, .k=3D2}; // compiles within friend or derived =
classes
>>>>
>>>> This syntax could be allowed for any class, regardless of its=20
>>>> inheritance chain
>>>> and of the type of is members, as far as I can tell. I see that this=
=20
>>>> has already
>>>> been proposed here:
>>>>
>>>> https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFq=
KjKlRs/CGARpDJy9JsJ
>>>> It seems that they are only targeting aggregate types, so we might=20
>>>> cooperate
>>>> to make things better in both worlds, since I'm sure they don't need=
=20
>>>> the current
>>>> restrictions of aggregate types and would beneficiate from relaxing=20
>>>> these as we
>>>> are discussing here.
>>>>
>>>
>>> I'm the writer of that proposal, and I added trial prose about expanded=
=20
>>> aggregates, based on this thread. But I'm going to undo that draft and=
=20
>>> propose expanded aggregates separately, as doing them together showed t=
hat=20
>>> the mix was a bad idea. The aggregate expansion prose mostly gets lost =
in=20
>>> the designated initializer prose, except for the parts that stick out=
=20
>>> badly. Both proposals will be independently based off the latest C++ dr=
aft,=20
>>> and can't reference each other (yet).
>>>
>>
>> I've uploaded a draft proposal for expanded aggregates=20
>> <http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multiarr=
ay-iso-proposal/master/expanded-aggregate-proposal.html>
>> now.
>>
>> Daryle W.
>> =20
>>
>
> I uploaded a new version. It adds something I had in my original merged=
=20
> aggregate/designated-initializer paper, but forgot to transfer. A (new=20
> style) aggregate class that gets its data from a base class is essentiall=
y=20
> a proxy for that base class. So when the base class is virtual, the=20
> aggregate class that derives from it, when used as a direct base class=20
> itself, has to have the same restrictions a virtual base class would have=
..
>
> 12.6.2/7 was already amended to say an aggregate base class that derives=
=20
> from a virtual class is also its base-initializer ignored when the=20
> constructor's class is not the most derived class.
>
> 12.6.2/5 is now amended that a constructor's base-initializer section get=
s=20
> a duplicate member error is there's an initializer for a=20
> data-bearing virtual base class and an aggregate direct base class that=
=20
> also derives from the virtual base class (or two aggregate direct base=20
> classes that derive from the same virtual base class).
>
> struct A { int a, b =3D 1; };
> struct B : public virtual A { };
> struct C : protected virtual A { };
> class E;
> struct D : protected B, private C { friend class E; D(); };
> class E : D { E(); };
>
>
> The constructor of D can specify at most one of {A, B, C} as a base=20
> initializer. Whichever one is chosen, the constructor of E will ignore=20
> it. No matter if E's constructor explicitly calls D's constructor, E's=20
> constructor must aggregate-initialize A if it doesn't want the A=20
> sub-object default-initialized.
>
> Daryle W.
>
>
Hello Daryle.
How is this proposal going? Did you get any feedback?
Best,
Corentin Schreiber.=20
--=20
---=20
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 e=
mail 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-proposa=
ls/.
------=_Part_5278_1606855940.1409174760681
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le samedi 25 janvier 2014 06:01:03 UTC+1, Daryle Walker a =
=C3=A9crit :<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Thursday, January 23, 2014 4:15:11 AM UTC-5, Daryle Walker wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-le=
ft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left=
-style:solid"><div dir=3D"ltr">On Wednesday, January 22, 2014 8:06:03 PM UT=
C-5, Daryle Walker wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);borde=
r-left-width:1px;border-left-style:solid"><div dir=3D"ltr">On Monday, Janua=
ry 20, 2014 3:48:24 PM UTC-5, <a>corentin....@cea.fr</a> wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bo=
rder-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:so=
lid"><div dir=3D"ltr"><div>Another thing that comes to my mind, things woul=
d much simpler if we were<br>to allow designated initializers like in C:<br=
><br> A a{.i=3D0, .k=3D2}; // compiles everywhere<br>&nbs=
p; A a{.i=3D0, .j=3D1, .k=3D2}; // compiles within friend or de=
rived classes<br><br>This syntax could be allowed for any class, regardless=
of its inheritance chain<br>and of the type of is members, as far as I can=
tell. I see that this has already<br>been proposed here:<br><a href=3D"htt=
ps://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/C=
GARpDJy9JsJ" target=3D"_blank" onmousedown=3D"this.href=3D'https://groups.g=
oogle.com/a/isocpp.org/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ';=
return true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.or=
g/forum/#!msg/std-proposals/IgDFqKjKlRs/CGARpDJy9JsJ';return true;">https:/=
/groups.google.com/a/<wbr>isocpp.org/forum/#!msg/std-<wbr>proposals/IgDFqKj=
KlRs/<wbr>CGARpDJy9JsJ</a><br>It seems that they are only targeting aggrega=
te types, so we might cooperate<br>to make things better in both worlds, si=
nce I'm sure they don't need the current<br>restrictions of aggregate types=
and would beneficiate from relaxing these as we<br>are discussing here.<br=
></div></div></blockquote><div><br></div><div>I'm the writer of that propos=
al, and I added trial prose about expanded aggregates, based on this t=
hread. But I'm going to undo that draft and propose expanded aggregates&nbs=
p;separately, as doing them together showed that the mix was a bad idea. Th=
e aggregate expansion prose mostly gets lost in the designated initializer =
prose, except for the parts that stick out badly. Both proposals will be in=
dependently based off the latest C++ draft, and can't reference each other =
(yet).<br></div></div></blockquote><div><br></div><div>I've uploaded a <a h=
ref=3D"http://htmlpreview.github.io/?https://raw.github.com/CTMacUser/multi=
array-iso-proposal/master/expanded-aggregate-proposal.html" target=3D"_blan=
k" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fh=
tmlpreview.github.io%2F%3Fhttps%3A%2F%2Fraw.github.com%2FCTMacUser%2Fmultia=
rray-iso-proposal%2Fmaster%2Fexpanded-aggregate-proposal.html\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNETF0wyB7UFsYlgcBGvmjHu87Gpgw';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fhtmlpreview.git=
hub.io%2F%3Fhttps%3A%2F%2Fraw.github.com%2FCTMacUser%2Fmultiarray-iso-propo=
sal%2Fmaster%2Fexpanded-aggregate-proposal.html\46sa\75D\46sntz\0751\46usg\=
75AFQjCNETF0wyB7UFsYlgcBGvmjHu87Gpgw';return true;">draft proposal for expa=
nded aggregates</a> now.</div><div><br></div><div>Daryle W.</div><div>=
</div></div></blockquote><div><br></div><div>I uploaded a new version=
.. It adds something I had in my original merged aggregate/designated-<wbr>i=
nitializer paper, but forgot to transfer. A (new style) aggregate class tha=
t gets its data from a base class is essentially a proxy for that base clas=
s. So when the base class is virtual, the aggregate class that derives from=
it, when used as a direct base class itself, has to have the same res=
trictions a virtual base class would have.</div><div><br></div><div>12.6.2/=
7 was already amended to say an aggregate base class that derives from a vi=
rtual class is also its base-initializer ignored when the constructor's cla=
ss is not the most derived class.</div><div><br></div><div>12.6.2/5 is now =
amended that a constructor's base-initializer section gets a duplicate memb=
er error is there's an initializer for a data-bearing virtual base cla=
ss and an aggregate direct base class that also derives from the virtual ba=
se class (or two aggregate direct base classes that derive from the same vi=
rtual base class).</div><div><br></div><div style=3D"border:1px solid rgb(1=
87,187,187);background-color:rgb(250,250,250)"><code><div><span style=3D"co=
lor:rgb(0,0,136)">struct</span><span style=3D"color:rgb(0,0,0)"> A </span><=
span style=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)=
"> </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color=
:rgb(0,0,0)"> a</span><span style=3D"color:rgb(102,102,0)">,</span><span st=
yle=3D"color:rgb(0,0,0)"> b </span><span style=3D"color:rgb(102,102,0)">=3D=
</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,=
102,102)">1</span><span style=3D"color:rgb(102,102,0)">;</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">};</span=
><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,0,1=
36)">struct</span><span style=3D"color:rgb(0,0,0)"> B </span><span style=3D=
"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"> </span><sp=
an style=3D"color:rgb(0,0,136)">public</span><span style=3D"color:rgb(0,0,0=
)"> </span><span style=3D"color:rgb(0,0,136)">virtual</span><span style=3D"=
color:rgb(0,0,0)"> A </span><span style=3D"color:rgb(102,102,0)">{</span><s=
pan style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)"=
>};</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:=
rgb(0,0,136)">struct</span><span style=3D"color:rgb(0,0,0)"> C </span><span=
style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"> <=
/span><span style=3D"color:rgb(0,0,136)">protected</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">virtual</span><sp=
an style=3D"color:rgb(0,0,0)"> A </span><span style=3D"color:rgb(102,102,0)=
">{</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb=
(102,102,0)">};</span><span style=3D"color:rgb(0,0,0)"><br></span><span sty=
le=3D"color:rgb(0,0,136)">class</span><span style=3D"color:rgb(0,0,0)"> E</=
span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(=
0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">struct</span><span st=
yle=3D"color:rgb(0,0,0)"> D </span><span style=3D"color:rgb(102,102,0)">:</=
span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,=
136)">protected</span><span style=3D"color:rgb(0,0,0)"> B</span><span style=
=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(0,0,136)">private</span><span style=3D"color:rgb(0=
,0,0)"> C </span><span style=3D"color:rgb(102,102,0)">{</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">friend</sp=
an><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,13=
6)">class</span><span style=3D"color:rgb(0,0,0)"> E</span><span style=3D"co=
lor:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> D</span><span=
style=3D"color:rgb(102,102,0)">();</span><span style=3D"color:rgb(0,0,0)">=
</span><span style=3D"color:rgb(102,102,0)">};</span><span style=3D"color:=
rgb(0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">class</span><span=
style=3D"color:rgb(0,0,0)"> E </span><span style=3D"color:rgb(102,102,0)">=
:</span><span style=3D"color:rgb(0,0,0)"> D </span><span style=3D"color:rgb=
(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"> E</span><span style=
=3D"color:rgb(102,102,0)">();</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(102,102,0)">};</span><span style=3D"color:rgb(0,=
0,0)"><br></span></div></code></div><br><div><br></div><div>The constructor=
of <font face=3D"courier new,monospace">D</font> can specify at most one o=
f <font face=3D"courier new,monospace">{A, B, C}</font> as a base initializ=
er. Whichever one is chosen, the constructor of <font face=3D"courier new,m=
onospace">E</font> will ignore it. No matter if <font face=3D"courier new,m=
onospace">E</font>'s constructor explicitly calls <font face=3D"courier new=
,monospace">D</font>'s constructor, <font face=3D"courier new,monospace">E<=
/font>'s constructor must aggregate-initialize <font face=3D"courier new,mo=
nospace">A</font> if it doesn't want the <font face=3D"courier new,monospac=
e">A</font> sub-object default-initialized.</div><div><br></div><div>Daryle=
W.</div><div><br></div></div></blockquote><div><br>Hello Daryle.<br><br>Ho=
w is this proposal going? Did you get any feedback?<br><br>Best,<br>Corenti=
n Schreiber. <br></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
------=_Part_5278_1606855940.1409174760681--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 28 Aug 2014 00:30:59 +0300
Raw View
On 28 August 2014 00:26, <corentin.schreiber@cea.fr> wrote:
> Hello Daryle.
>
> How is this proposal going? Did you get any feedback?
It hasn't been presented to the committee, but EWG is interested:
http://cplusplus.github.io/EWG/ewg-active.html#108
--
---
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: Daryle Walker <darylew@gmail.com>
Date: Thu, 18 Sep 2014 06:27:48 -0400
Raw View
--047d7bb04d529ef5db0503546fd4
Content-Type: text/plain; charset=UTF-8
Oh, I haven't touched this stuff since the spring. And just checked my
e-mail now. Does anyone see any problems with the proposal?
I don't know if Gabriel Dos Reis has tried to contact me.
On Wed, Aug 27, 2014 at 5:30 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 28 August 2014 00:26, <corentin.schreiber@cea.fr> wrote:
> > Hello Daryle.
> >
> > How is this proposal going? Did you get any feedback?
>
> It hasn't been presented to the committee, but EWG is interested:
> http://cplusplus.github.io/EWG/ewg-active.html#108
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/77IY0cAlYR8/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>
--
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT gmail DOT com
--
---
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/.
--047d7bb04d529ef5db0503546fd4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Oh, I haven't touched this stuff since the spring. And=
just checked my e-mail now. Does anyone see any problems with the proposal=
?<div><br></div><div>I don't know if=C2=A0Gabriel Dos Reis has tried to=
contact me.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Wed, Aug 27, 2014 at 5:30 PM, Ville Voutilainen <span dir=3D"ltr"=
><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville=
..voutilainen@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span class=3D"">On 28 August 2014 00:26,=C2=A0 <<a href=3D"mailto:c=
orentin.schreiber@cea.fr">corentin.schreiber@cea.fr</a>> wrote:<br>
> Hello Daryle.<br>
><br>
> How is this proposal going? Did you get any feedback?<br>
<br>
</span>It hasn't been presented to the committee, but EWG is interested=
:<br>
<a href=3D"http://cplusplus.github.io/EWG/ewg-active.html#108" target=3D"_b=
lank">http://cplusplus.github.io/EWG/ewg-active.html#108</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/77IY0cAlYR8/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/77IY0cAlYR8=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">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>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Daryle Walker<br>Mac, Internet, and Video Game Junkie<br>darylew AT gmail D=
OT com
</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--047d7bb04d529ef5db0503546fd4--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 18 Sep 2014 14:09:13 +0300
Raw View
On 18 September 2014 13:27, Daryle Walker <darylew@gmail.com> wrote:
> Oh, I haven't touched this stuff since the spring. And just checked my
> e-mail now. Does anyone see any problems with the proposal?
>
> I don't know if Gabriel Dos Reis has tried to contact me.
You could contact him. :) I can certainly introduce you if you want.
--
---
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/.
.