Topic: [std-proposals] Re: Proposal: Class static proper
Author: Igor Baidiuk <target.san@gmail.com>
Date: Tue, 5 May 2015 09:37:02 -0700 (PDT)
Raw View
------=_Part_442_284785086.1430843822245
Content-Type: multipart/alternative;
boundary="----=_Part_443_662716414.1430843822245"
------=_Part_443_662716414.1430843822245
Content-Type: text/plain; charset=UTF-8
Frankly speaking, I don't see what should it solve.
If you know type statically, then you use template programming, static
constexpr members.
If you don't know type statically, then you'll need to go through vtable
anyway to know exact type.
If this is a shortcut for 'virtual getSomeConstant', then please note that
constant should be allocated somewhere in vtable and be perfectly
constexpr. Not very flexible.
And BTW vtable structure is implementation-defined.
On Tuesday, May 5, 2015 at 7:21:24 PM UTC+3, John Yates wrote:
>
> I have been writing embedded systems in C++ for nearly 20 years.
> Repeatedly I have encountered a desire to access class properties more
> cheaply that via a call to a virtual method. This seems (at least to me) a
> very natural extension of C++ storage specifiers and the semantics of
> virtual name lookup. I have finally gotten around to writing a brief
> proposal
> <https://docs.google.com/document/d/1Y0_MG7MgoUDHGQGh4IZcAWRRO9I4Xy-WjwgQe19iT1g/edit?usp=sharing>.
> Very curious what other may think.
>
--
---
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_443_662716414.1430843822245
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Frankly speaking, I don't see what should it solve.<br>If =
you know type statically, then you use template programming, static constex=
pr members.<br>If you don't know type statically, then you'll need to go th=
rough vtable anyway to know exact type.<br>If this is a shortcut for 'virtu=
al getSomeConstant', then please note that constant should be allocated som=
ewhere in vtable and be perfectly constexpr. Not very flexible.<br>And BTW =
vtable structure is implementation-defined.<br><br>On Tuesday, May 5, 2015 =
at 7:21:24 PM UTC+3, John Yates wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-s=
ize:small">I have been writing embedded systems in C++ for nearly 20 years.=
Repeatedly I have encountered a desire to access class properties mo=
re cheaply that via a call to a virtual method. This seems (at least =
to me) a very natural extension of C++ storage specifiers and the semantics=
of virtual name lookup. I have finally gotten around to writin=
g a <a href=3D"https://docs.google.com/document/d/1Y0_MG7MgoUDHGQGh4IZcAWRR=
O9I4Xy-WjwgQe19iT1g/edit?usp=3Dsharing" target=3D"_blank" rel=3D"nofollow" =
onmousedown=3D"this.href=3D'https://docs.google.com/document/d/1Y0_MG7MgoUD=
HGQGh4IZcAWRRO9I4Xy-WjwgQe19iT1g/edit?usp\75sharing';return true;" onclick=
=3D"this.href=3D'https://docs.google.com/document/d/1Y0_MG7MgoUDHGQGh4IZcAW=
RRO9I4Xy-WjwgQe19iT1g/edit?usp\75sharing';return true;">brief proposal</a>.=
Very curious what other may think.</span><br></div></blockquote></di=
v>
<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_443_662716414.1430843822245--
------=_Part_442_284785086.1430843822245--
.
Author: John Yates <john.yates.sheets@gmail.com>
Date: Tue, 5 May 2015 12:15:08 -0700 (PDT)
Raw View
------=_Part_5275_1046166535.1430853308825
Content-Type: multipart/alternative;
boundary="----=_Part_5276_1472335756.1430853308825"
------=_Part_5276_1472335756.1430853308825
Content-Type: text/plain; charset=UTF-8
On Tuesday, May 5, 2015 at 12:37:02 PM UTC-4, Igor Baidiuk wrote:
>
> Frankly speaking, I don't see what should it solve.
>
Did you read the linked to proposal?
> If you know type statically, then you use template programming, static
> constexpr members.
> If you don't know type statically, then you'll need to go through vtable
> anyway to know exact type.
>
Correct, the type is _not_ statically known. The first example in my
document tries to be an illustrative example. If you find it inadequate
perhaps you could help me improve it.
> If this is a shortcut for 'virtual getSomeConstant', then please note that
> constant should be allocated somewhere in vtable and be perfectly
> constexpr. Not very flexible.
>
That is exactly the use case. It is a way of accessing efficiently class
"properties".
> And BTW vtable structure is implementation-defined.
>
Yes, I am well aware of that point. Once I have paid the price in an
object to have a vtable pointer, retrieving a constant at a fixed offset is
all I seek. I am not trying to control layout of the vtable, only
attempting to piggyback on the the fact that my object contains a pointer
to a class-specific piece of initialized readonly storageand perhaps
suggesting how much storage is necessary to store my constant.
--
---
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_5276_1472335756.1430853308825
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, May 5, 2015 at 12:37:02 PM UTC-4, Igor Baidiuk=
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">Frankl=
y speaking, I don't see what should it solve.<br></div></blockquote><div><b=
r></div><div><span style=3D"font-family: arial, sans-serif; font-size: smal=
l;">Did you read the linked to proposal?</span></div><div> </div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">If you know type s=
tatically, then you use template programming, static constexpr members.<br>=
If you don't know type statically, then you'll need to go through vtable an=
yway to know exact type.<br></div></blockquote><div><br></div><div style=3D=
"font-family: arial, sans-serif; font-size: small;">Correct, the type is _n=
ot_ statically known. The first example in my document tries to be an=
illustrative example. If you find it inadequate perhaps you could he=
lp me improve it.</div><div> </div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">If this is a shortcut for 'virtual getSomeConsta=
nt', then please note that constant should be allocated somewhere in vtable=
and be perfectly constexpr. Not very flexible.<br></div></blockquote><div>=
<br></div><div>That is exactly the use case. It is a way of accessing=
efficiently class "properties". </div><div> </div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">And BTW vtable structure is=
implementation-defined.<br></div></blockquote><div><br></div><div>Yes, I a=
m well aware of that point. Once I have paid the price in an object t=
o have a vtable pointer, retrieving a constant at a fixed offset is all I s=
eek. I am not trying to control layout of the vtable, only attempting=
to piggyback on the the fact that my object contains a pointer to a class-=
specific piece of initialized readonly storageand perhaps suggesting =
how much storage is necessary to store my constant.</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_5276_1472335756.1430853308825--
------=_Part_5275_1046166535.1430853308825--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 5 May 2015 13:57:32 -0700 (PDT)
Raw View
------=_Part_1032_2023941338.1430859452314
Content-Type: multipart/alternative;
boundary="----=_Part_1033_241099286.1430859452314"
------=_Part_1033_241099286.1430859452314
Content-Type: text/plain; charset=UTF-8
On Tuesday, May 5, 2015 at 12:21:24 PM UTC-4, John Yates wrote:
>
> I have been writing embedded systems in C++ for nearly 20 years.
> Repeatedly I have encountered a desire to access class properties more
> cheaply that via a call to a virtual method. This seems (at least to me) a
> very natural extension of C++ storage specifiers and the semantics of
> virtual name lookup. I have finally gotten around to writing a brief
> proposal
> <https://docs.google.com/document/d/1Y0_MG7MgoUDHGQGh4IZcAWRRO9I4Xy-WjwgQe19iT1g/edit?usp=sharing>.
> Very curious what other may think.
>
My concern with this proposal is that it formalizes and promotes the use of
ad-hoc methods of OOP. While it is true that many people want to use such
methods, to standardize it would suggest that it's a good thing. Which by
inference implies that there's something wrong with virtual dispatch.
Also, I'd say that derived class versions of these static members *must*
use the `override` keyword, to make it clear that they're overriding a
previously defined virtual, rather than creating a regular new static
member.
Lastly, don't call them "properties". It gives the wrong impression; people
might start thinking of C# properties.
--
---
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_1033_241099286.1430859452314
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, May 5, 2015 at 12:21:24 PM UTC-4, John Yates w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><span st=
yle=3D"font-family:arial,sans-serif;font-size:small">I have been writing em=
bedded systems in C++ for nearly 20 years. Repeatedly I have encounte=
red a desire to access class properties more cheaply that via a call to a v=
irtual method. This seems (at least to me) a very natural extension o=
f C++ storage specifiers and the semantics of virtual name lookup. I =
have finally gotten around to writing a <a href=3D"https://docs.googl=
e.com/document/d/1Y0_MG7MgoUDHGQGh4IZcAWRRO9I4Xy-WjwgQe19iT1g/edit?usp=3Dsh=
aring" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https=
://docs.google.com/document/d/1Y0_MG7MgoUDHGQGh4IZcAWRRO9I4Xy-WjwgQe19iT1g/=
edit?usp\75sharing';return true;" onclick=3D"this.href=3D'https://docs.goog=
le.com/document/d/1Y0_MG7MgoUDHGQGh4IZcAWRRO9I4Xy-WjwgQe19iT1g/edit?usp\75s=
haring';return true;">brief proposal</a>. Very curious what other may=
think.</span><br></div></blockquote><div><br>My concern with this proposal=
is that it formalizes and promotes the use of ad-hoc methods of OOP. While=
it is true that many people want to use such methods, to standardize it wo=
uld suggest that it's a good thing. Which by inference implies that there's=
something wrong with virtual dispatch.<br><br>Also, I'd say that derived c=
lass versions of these static members <i>must</i> use the `override` keywor=
d, to make it clear that they're overriding a previously defined virtual, r=
ather than creating a regular new static member.<br><br>Lastly, don't call =
them "properties". It gives the wrong impression; people might start thinki=
ng of C# properties.<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_1033_241099286.1430859452314--
------=_Part_1032_2023941338.1430859452314--
.
Author: John Yates <john.yates.sheets@gmail.com>
Date: Tue, 5 May 2015 15:21:38 -0700 (PDT)
Raw View
------=_Part_3390_64170154.1430864499031
Content-Type: multipart/alternative;
boundary="----=_Part_3391_470987484.1430864499032"
------=_Part_3391_470987484.1430864499032
Content-Type: text/plain; charset=UTF-8
On Tuesday, May 5, 2015 at 4:57:32 PM UTC-4, Nicol Bolas wrote:
>
> My concern with this proposal is that it formalizes and promotes the use
> of ad-hoc methods of OOP. While it is true that many people want to use
> such methods, to standardize it would suggest that it's a good thing. Which
> by inference implies that there's something wrong with virtual dispatch.
>
There is nothing fundamentally wrong with virtual dispatch. The proposal
early on admits that virtual dispatch can provide equivalent functionality.
The issue is entirely one of efficiency, an eternal C++ objective. In the
embedded systems I write more times than I care to count I have foregone
use of virtual methods in favor of my own *ad hoc* lookup simply because I
could not afford the cost of virtual dispatch.
> Also, I'd say that derived class versions of these static members *must*
> use the `override` keyword, to make it clear that they're overriding a
> previously defined virtual, rather than creating a regular new static
> member.
>
Point well taken. I have updated the proposal.
> Lastly, don't call them "properties". It gives the wrong impression;
> people might start thinking of C# properties.
>
Do you think that "class attribute" is a better, less misleading phrase?
(I have tentatively updated the proposal replacing property with
attribute.)
--
---
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_3391_470987484.1430864499032
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, May 5, 2015 at 4:57:32 PM UTC-4, Nicol Bolas w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>My =
concern with this proposal is that it formalizes and promotes the use of ad=
-hoc methods of OOP. While it is true that many people want to use such met=
hods, to standardize it would suggest that it's a good thing. Which by infe=
rence implies that there's something wrong with virtual dispatch.<br></div>=
</div></blockquote><div><br></div><div>There is nothing fundamentally wrong=
with virtual dispatch. The proposal early on admits that virtual dis=
patch can provide equivalent functionality. The issue is entirely one=
of efficiency, an eternal C++ objective. In the embedded systems I w=
rite more times than I care to count I have foregone use of virtual methods=
in favor of my own <i>ad hoc</i> lookup simply because I could not afford =
the cost of virtual dispatch.</div><div> </div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div>Also, I'd say that derived clas=
s versions of these static members <i>must</i> use the `override` keyword, =
to make it clear that they're overriding a previously defined virtual, rath=
er than creating a regular new static member.<br></div></div></blockquote><=
div><br></div><div>Point well taken. I have updated the proposal.</di=
v><div> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div>Lastly, don't call them "properties". It gives the wrong impress=
ion; people might start thinking of C# properties.<br></div></div></blockqu=
ote><div><br></div><div>Do you think that "class attribute" is a better, le=
ss misleading phrase? (I have tentatively updated the proposal replac=
ing property with attribute.) </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_3391_470987484.1430864499032--
------=_Part_3390_64170154.1430864499031--
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Tue, 5 May 2015 23:49:07 -0700 (PDT)
Raw View
------=_Part_5604_154822941.1430894947748
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The term "attribute" is [[already_taken]]. Call these what they are: virtua=
l static data members.=20
I would also suggest collecting some performance measurements to back up yo=
ur argument (eg with a hand-rolled vtable implementation). You should also =
make it clear that you understand that the C++ standard does not mandate vt=
ables as an implementation technique although of course in practice every i=
mplementation uses them.=20
Would this mean that pointers to data members can now involve a vtable look=
up? Could that break ABI?=20
I note you haven't provided definitions for the members as would usually be=
required for static data members. Is that an omission or intentional?=20
Is it really necessary that virtual static data members be const? Non-const=
virtual static data members would have to be allocated outside the vtable =
itself, but access to them would still be considerably cheaper than a nulla=
ry virtual method call. Note that also objects with run time initialization=
would need to be allocated outside the vtable, even if they were const the=
reafter.=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_5604_154822941.1430894947748--
.
Author: Morwenn <morwenn29@gmail.com>
Date: Wed, 6 May 2015 02:41:39 -0700 (PDT)
Raw View
------=_Part_181_1167576531.1430905299966
Content-Type: multipart/alternative;
boundary="----=_Part_182_1900673878.1430905299966"
------=_Part_182_1900673878.1430905299966
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I am not here to contribute to the debate but only to dhow support: it's a=
=20
feature that I have desired from time to time and the way you describe it=
=20
makes it trivial to understand and use. I like the use of override. Oh=20
yeah, by the way, is it possible to implement such a proposal while keeping=
=20
override a contextual keyword or does it have to become a full-fledge=20
keyword?
Le mardi 5 mai 2015 18:21:24 UTC+2, John Yates a =C3=A9crit :
>
> I have been writing embedded systems in C++ for nearly 20 years. =20
> Repeatedly I have encountered a desire to access class properties more=20
> cheaply that via a call to a virtual method. This seems (at least to me)=
a=20
> very natural extension of C++ storage specifiers and the semantics of=20
> virtual name lookup. I have finally gotten around to writing a brief=20
> proposal=20
> <https://docs.google.com/document/d/1Y0_MG7MgoUDHGQGh4IZcAWRRO9I4Xy-WjwgQ=
e19iT1g/edit?usp=3Dsharing>.=20
> Very curious what other may think.
>
--=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_182_1900673878.1430905299966
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I am not here to contribute to the debate but only to dhow=
support: it's a feature that I have desired from time to time and the way =
you describe it makes it trivial to understand and use. I like the use of <=
span style=3D"font-family: courier new,monospace;">override</span>. Oh yeah=
, by the way, is it possible to implement such a proposal while keeping <sp=
an style=3D"font-family: courier new,monospace;">override</span> a contextu=
al keyword or does it have to become a full-fledge keyword?<br><br>Le mardi=
5 mai 2015 18:21:24 UTC+2, John Yates a =C3=A9crit :<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><span style=3D"font-family:ari=
al,sans-serif;font-size:small">I have been writing embedded systems in C++ =
for nearly 20 years. Repeatedly I have encountered a desire to access=
class properties more cheaply that via a call to a virtual method. T=
his seems (at least to me) a very natural extension of C++ storage specifie=
rs and the semantics of virtual name lookup. I have finally got=
ten around to writing a <a href=3D"https://docs.google.com/document/d/1Y0_M=
G7MgoUDHGQGh4IZcAWRRO9I4Xy-WjwgQe19iT1g/edit?usp=3Dsharing" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://docs.google.com/doc=
ument/d/1Y0_MG7MgoUDHGQGh4IZcAWRRO9I4Xy-WjwgQe19iT1g/edit?usp\75sharing';re=
turn true;" onclick=3D"this.href=3D'https://docs.google.com/document/d/1Y0_=
MG7MgoUDHGQGh4IZcAWRRO9I4Xy-WjwgQe19iT1g/edit?usp\75sharing';return true;">=
brief proposal</a>. Very curious what other may think.</span><br></di=
v></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 <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_182_1900673878.1430905299966--
------=_Part_181_1167576531.1430905299966--
.