------=_Part_541_17260804.1393456382711
Content-Type: text/plain; charset=UTF-8

It's common to derive from a class and only add things like convenience
constructors. That means the memory footprint (and object size) of the base
class and the derived class is exactly the same and there's no risk of
dangerous slicing. However, in case the base class lacks a virtual
destructor, it's a bit scary that there's nothing that will prevent
accidental deletion through a pointer-to-base, which causes undefined
behaviour.

I'm playing with the thought: would it be possible to define the behaviour
of a delete operation via pointer-to-base in this particular case, in a
future version of the standard?

As far as I can see, there are two real dangers when deleting via
pointer-to-base in general when there's no virtual destructor. The first
one lies in invoking delete with the wrong object size (derived class
members are not properly destroyed). That will always cause undefined
behaviour, but in the case described above when the size is the same (and
there are no derived class members to destroy) it should be safe.

The other one is that the destructor of the derived class doesn't get
called, but only the base class destructor. This is of course very bad, but
in theory (or at least in my mind) calling the "wrong" destructor has the
potential of not causing undefined behaviour. Let's just pretend that the
behaviour is defined such that the base non-virtual destructor is called
and any destructors of derived objects are not. When there are no derived
members to destroy, this may "only" lead to unexpected results (resources
not being released, or whatever the omitted destructor was supposed to do
unless it's empty) in case of accidential deletion through a
pointer-to-base. But at least the behaviour would be defined and
reproducable with different compilers! I think that is a slightly better
(less evil) alternative to undefined behaviour, if there's any chance of
possible standardization.

Of course, this still does not mean that anyone should intentionally write
code that deletes via base-to-pointer!

Please share your reactions, or tell me if I'm wrong somewhere. Maybe there
are other negative effects in "compiler magic" that I'm not aware of?

Best wishes

Johan

--

---
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_541_17260804.1393456382711
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><font face=3D"arial,sans-serif" size=3D"2">It's commo=
n to derive from a class and only add things like convenience constructors.=
 That means the memory footprint (and object size) of the base class and th=
e derived class is exactly the same and there's no risk of dangerous slicin=
g. However, in case the base class lacks a virtual destructor, it's a bit s=
cary that there's nothing that will prevent accidental deletion through a p=
ointer-to-base, which causes undefined behaviour.</font></div><div><font fa=
ce=3D"arial,sans-serif" size=3D"2"><br></font></div><div><font face=3D"aria=
l,sans-serif" size=3D"2">I'm playing with the thought: would it be possible=
 to define the behaviour of a delete operation via pointer-to-base in this =
particular case, in a future version of the standard?</font></div><div><fon=
t size=3D"2"><br></font></div><div><font face=3D"arial,sans-serif" size=3D"=
2">As far as I can see, there are two real dangers when deleting via pointe=
r-to-base in general when there's no virtual destructor. The first one lies=
 in invoking delete with the wrong object size (derived class members are n=
ot properly destroyed). That will always cause undefined behaviour, but in =
the case described above when the size is the same (and there are no derive=
d class members to destroy) it should be safe.</font></div><div><font size=
=3D"2"><br></font></div><div><font face=3D"arial,sans-serif" size=3D"2">The=
 other one is that the destructor of the derived class doesn't get called, =
but only the base class destructor. This is of course very bad, but in theo=
ry (or at least in my mind) calling the "wrong" destructor has the potentia=
l of not causing undefined behaviour. Let's just pretend that the behaviour=
 is defined such that the base non-virtual destructor is called and any des=
tructors of derived objects are not. When there are no derived members to d=
estroy, this may "only" lead to unexpected results (resources not being rel=
eased, or whatever the omitted destructor was supposed to do unless it's em=
pty) in case of accidential deletion through a pointer-to-base. But at leas=
t the behaviour would be defined and reproducable with different compilers!=
 I think that is a slightly better (less evil) alternative to undefined beh=
aviour, if there's any chance of possible standardization.</font></div><div=
><font size=3D"2"><br></font></div><div><font face=3D"arial,sans-serif" siz=
e=3D"2">Of course, this still does not mean that anyone should intentionall=
y write code that deletes via base-to-pointer!</font></div><div><font size=
=3D"2"><br></font></div><div><font face=3D"arial,sans-serif" size=3D"2">Ple=
ase share your reactions, or tell me if I'm wrong somewhere. Maybe there ar=
e other negative effects in "compiler magic" that I'm not aware of?</font><=
/div><div><font size=3D"2"><br></font></div><div><font face=3D"arial,sans-s=
erif" size=3D"2">Best wishes</font></div><div><font size=3D"2"><br></font><=
/div><p><font face=3D"arial,sans-serif" size=3D"2">Johan</font></p></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_541_17260804.1393456382711--

.

On 27 February 2014 01:13,  <williamsson@gmail.com> wrote:
> It's common to derive from a class and only add things like convenience
> constructors. That means the memory footprint (and object size) of the base
> class and the derived class is exactly the same and there's no risk of
> dangerous slicing. However, in case the base class lacks a virtual
> destructor, it's a bit scary that there's nothing that will prevent
> accidental deletion through a pointer-to-base, which causes undefined
> behaviour.
>
> I'm playing with the thought: would it be possible to define the behaviour
> of a delete operation via pointer-to-base in this particular case, in a
> future version of the standard?
>
> As far as I can see, there are two real dangers when deleting via
> pointer-to-base in general when there's no virtual destructor. The first one
> lies in invoking delete with the wrong object size (derived class members
> are not properly destroyed). That will always cause undefined behaviour, but
> in the case described above when the size is the same (and there are no
> derived class members to destroy) it should be safe.
>
> The other one is that the destructor of the derived class doesn't get
> called, but only the base class destructor. This is of course very bad, but
> in theory (or at least in my mind) calling the "wrong" destructor has the
> potential of not causing undefined behaviour. Let's just pretend that the
> behaviour is defined such that the base non-virtual destructor is called and
> any destructors of derived objects are not. When there are no derived
> members to destroy, this may "only" lead to unexpected results (resources
> not being released, or whatever the omitted destructor was supposed to do
> unless it's empty) in case of accidential deletion through a
> pointer-to-base. But at least the behaviour would be defined and
> reproducable with different compilers! I think that is a slightly better
> (less evil) alternative to undefined behaviour, if there's any chance of
> possible standardization.
>
> Of course, this still does not mean that anyone should intentionally write
> code that deletes via base-to-pointer!
>
> Please share your reactions, or tell me if I'm wrong somewhere. Maybe there
> are other negative effects in "compiler magic" that I'm not aware of?

It seems that this idea was floated on
http://www.open-std.org/pipermail/ub/2013-December/000382.html
and the replies to it.

--

---
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/.

.

On 27 February 2014 01:13,  <williamsson@gmail.com> wrote:
>
> The other one is that the destructor of the derived class doesn't get
> called, but only the base class destructor. This is of course very bad, but
> in theory (or at least in my mind) calling the "wrong" destructor has the
> potential of not causing undefined behaviour. Let's just pretend that the
> behaviour is defined such that the base non-virtual destructor is called and
> any destructors of derived objects are not. When there are no derived
> members to destroy, this may "only" lead to unexpected results (resources
> not being released, or whatever the omitted destructor was supposed to do
> unless it's empty) in case of accidential deletion through a
> pointer-to-base. But at least the behaviour would be defined and
> reproducable with different compilers! I think that is a slightly better
> (less evil) alternative to undefined behaviour, if there's any chance of
> possible standardization.


Another point; having such mistakes be defined behavior is not necessarily
"less evil". Undefined behavior doesn't mean "WILL launch missiles", it
also means that an implementation is allowed to do _useful_ things under
the auspices of undefined behavior, like launch a debugger and tell you
where you made a mistake!

Given that, and the email thread on the UB mailing list (and especially
the first response to the initial question), I think you need a
stronger argument
for making the case you depict defined. It seems to me that it should remain
undefined, because _that_ is the "less evil" alternative.

--

---
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_355_31740382.1393491709483
Content-Type: text/plain; charset=UTF-8



Ville, I see your point, but so far I still think defined behaviour would
be preferred.

The only case when you will have a bug and defined behaviour at the same
time, is when the desctructor is non-empty. Of course, this kind of bugs
are hard to track down. But if the destructor is supposed to do some work,
and for the reason of delete via pointer-to-base is not executed, the
program will not run as you expected it to. There can still be symptoms.
Most importantly, the program remains in a valid state. Your system tests
will still work in production.

The undefined behaviour on the other hand is unpredictable, so anything can
happen. A program that can't be trusted may be useless or dangerous at
worst. If you're lucky, that missile you mention will visibly go off in
debug mode before you go into production. Let's pray the missile dives into
the ocean. If you're not lucky, some seemingly random minor change will
happen that keeps your program running without any diagnostics being
reported, and you will never know why your program state changed.
You've got to ask yourself one question: "Do I feel lucky?" :-) Seriously
though, I will try to come up with some more arguments.

Kind regards,

Johan



--

---
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_355_31740382.1393491709483
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p><font size=3D"2">Ville,&nbsp;I see your point, but so f=
ar I still think defined behaviour would be preferred.</font></p><p><font s=
ize=3D"2">The only case when you will have a bug and defined behaviour at t=
he same time, is when the desctructor is non-empty. Of course, this kind of=
 bugs are hard to track down. But if the destructor is supposed to do some =
work, and for the reason of delete via pointer-to-base is not executed, the=
 program will not run as you expected it to. There can still be symptoms. M=
ost importantly, the program remains in a valid state. Your system tests wi=
ll still work in production.</font></p><p><font size=3D"2">The undefined be=
haviour on the other hand is unpredictable, so anything can happen. A progr=
am that can't be trusted may be useless or dangerous at worst. If you're lu=
cky, that missile you mention will visibly go off in debug mode before you =
go into production. Let's pray the missile dives into the ocean. If you're =
not lucky, some seemingly random minor change will happen that keeps your p=
rogram running without any diagnostics being reported, and you will never k=
now why your program state changed.</font></p><div><font size=3D"2">You've =
got to ask yourself one question: "Do I feel lucky?" :-) Seriously though, =
I will try to come up with some more arguments.</font></div><div><font size=
=3D"2"></font>&nbsp;</div><div><font size=3D"2">Kind regards,</font></div><=
div><font size=3D"2"></font>&nbsp;</div><div><font size=3D"2">Johan</font><=
/div><div><font size=3D"2"></font>&nbsp;</div><div><font size=3D"2"></font>=
&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_355_31740382.1393491709483--

.

On 27 February 2014 11:01,  <williamsson@gmail.com> wrote:
> Ville, I see your point, but so far I still think defined behaviour would be
> preferred.
>
> The only case when you will have a bug and defined behaviour at the same
> time, is when the desctructor is non-empty. Of course, this kind of bugs are
> hard to track down. But if the destructor is supposed to do some work, and
> for the reason of delete via pointer-to-base is not executed, the program
> will not run as you expected it to. There can still be symptoms. Most
> importantly, the program remains in a valid state. Your system tests will
> still work in production.

Well, as far as I can see, the program is most certainly not in a
valid state, nor will
system tests work in production. I have no way of assuming that not invoking
the correct destructor results in a valid state, so I'll assume quite
the opposite.
And the tests I tend to write will show whether the right destructor was invoked
or not.


> The undefined behaviour on the other hand is unpredictable, so anything can
> happen. A program that can't be trusted may be useless or dangerous at
> worst. If you're lucky, that missile you mention will visibly go off in
> debug mode before you go into production. Let's pray the missile dives into
> the ocean. If you're not lucky, some seemingly random minor change will
> happen that keeps your program running without any diagnostics being
> reported, and you will never know why your program state changed.

The same applies equally to a program that didn't invoke a destructor
it was meant to.

I can probably catch such UB with ub-sanitizer. If the behavior becomes defined,
I don't know how any diagnostic tool will know whether I did or did not mean
to not invoke a destructor.

I remain strongly convinced that the current semantics are right.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_91_1741471.1393492941414
Content-Type: text/plain; charset=UTF-8

>Well, as far as I can see, the program is most certainly not in a valid
state, nor will
>system tests work in production. I have no way of assuming that not
invoking
>the correct destructor results in a valid state, so I'll assume quite
>the opposite.

That's the main point. I'm asking if it would be possible to define the
behaviour so that the outcome is predictable and reproducable. That's what
I meant with valid state.

Best wishes

Johan

--

---
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_91_1741471.1393492941414
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><font face=3D"arial,sans-serif" size=3D"2=
">&gt;Well, as far as I can see, the program is most certainly not in a val=
id state, nor will <br>&gt;system tests work in production. I have no way o=
f assuming that not invoking <br>&gt;the correct destructor results in a va=
lid state, so I'll assume quite <br>&gt;the opposite.</font></div><div dir=
=3D"ltr"><font size=3D"2"></font>&nbsp;</div><div dir=3D"ltr"><font face=3D=
"arial,sans-serif" size=3D"2">That's the main point. I'm asking if it would=
 be possible to define the behaviour so that the outcome is predictable and=
 reproducable. That's what I meant with valid state.<br><br>Best wishes<br>=
<br>Johan</font></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_91_1741471.1393492941414--

.

--Apple-Mail=_B6D4AC2F-3329-44A2-A914-BF08E7E6B1E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On Feb 27, 2014, at 5:22 PM, williamsson@gmail.com wrote:

> >Well, as far as I can see, the program is most certainly not in a valid =
state, nor will=20
> >system tests work in production. I have no way of assuming that not invo=
king=20
> >the correct destructor results in a valid state, so I'll assume quite=20
> >the opposite.
> =20
> That's the main point. I'm asking if it would be possible to define the b=
ehaviour so that the outcome is predictable and reproducable. That's what I=
 meant with valid state.

I think the answer is that the ideas expressed by the C++ type system don't=
 permit that possibility. Two objects constructed with different types have=
 different type throughout their lifetime, and each must be destroyed by th=
e appropriate destructor. The type system isn't as easy to hack as you're a=
ssuming.

See the discussion at the ub list. The problem solved by pseudo-subtyping t=
ouches on extension methods and factory functions. Improving those areas of=
 the language (and they need improvement) should eliminate the desire to at=
tempt to emulate a base class up to destructor compatibility.

--=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/.

--Apple-Mail=_B6D4AC2F-3329-44A2-A914-BF08E7E6B1E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 2=
7, 2014, at 5:22 PM, <a href=3D"mailto:williamsson@gmail.com">williamsson@g=
mail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blockquot=
e type=3D"cite"><div dir=3D"ltr"><div dir=3D"ltr"><font face=3D"arial,sans-=
serif" size=3D"2">&gt;Well, as far as I can see, the program is most certai=
nly not in a valid state, nor will <br>&gt;system tests work in production.=
 I have no way of assuming that not invoking <br>&gt;the correct destructor=
 results in a valid state, so I'll assume quite <br>&gt;the opposite.</font=
></div><div dir=3D"ltr"><font size=3D"2"></font>&nbsp;</div><div dir=3D"ltr=
"><font face=3D"arial,sans-serif" size=3D"2">That's the main point. I'm ask=
ing if it would be possible to define the behaviour so that the outcome is =
predictable and reproducable. That's what I meant with valid state.<br></fo=
nt></div></div></blockquote><div><br></div></div>I think the answer is that=
 the ideas expressed by the C++ type system don&rsquo;t permit that possibi=
lity. Two objects constructed with different types have different type thro=
ughout their lifetime, and each must be destroyed by the appropriate destru=
ctor. The type system isn&rsquo;t as easy to hack as you&rsquo;re assuming.=
<div><br></div><div>See the discussion at the ub list. The problem solved b=
y pseudo-subtyping touches on extension methods and factory functions. Impr=
oving those areas of the language (and they need improvement) should elimin=
ate the desire to attempt to emulate a base class up to destructor compatib=
ility.</div><div><br></div></body></html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--Apple-Mail=_B6D4AC2F-3329-44A2-A914-BF08E7E6B1E3--

.

On 27 February 2014 11:22,  <williamsson@gmail.com> wrote:
>>Well, as far as I can see, the program is most certainly not in a valid
>> state, nor will
>>system tests work in production. I have no way of assuming that not
>> invoking
>>the correct destructor results in a valid state, so I'll assume quite
>>the opposite.
>
> That's the main point. I'm asking if it would be possible to define the
> behaviour so that the outcome is predictable and reproducable. That's what I
> meant with valid state.


Well, I guess it's certainly possible, for cases where the derived
class destructor
is trivial. That would still be validating a mostly-invalid design in
language rules, and I
can't imagine a practical reason to do so. Having it be UB allows
implementations
to detect the situation (at run-time, if need be) and inform users,
without forcing every
implementation to do so (thus avoiding potential run-time costs that
don't need to
be paid unless so desired). This also nicely allows implementations to have the
detection mechanism in place in debug mode, and to remove such mechanisms
in release mode.

--

---
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_6734_4994575.1393503603685
Content-Type: text/plain; charset=UTF-8

Ville, are you referring to Clang's UB sanitizer? Is this situation really
so easily detectable and this tool can tell where you made the mistake?
That is not my personal experience from the tools I'm using, but I guess I
should test with some other tools as well.

However, it's my understanding that undefined behaviour does not
necessarily manifest itself in any measurable way. Or it may show up the
first time your run the program on a different operating system version,
hardware or some other circumstances. Or after several weeks of running the
software continously. It doesn't sound very easy to detect in a debug
session.

Best wishes

Johan

--

---
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_6734_4994575.1393503603685
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Ville, are you referring to Clang's UB sanitizer? Is =
this situation really so easily detectable and this tool can tell where you=
 made&nbsp;the mistake? That is not my personal experience from the tools I=
'm using, but I guess I should test with some other tools as well.</div><di=
v>&nbsp;</div><div>However, it's my understanding that undefined behaviour =
does not necessarily manifest itself in any measurable way. Or it may show =
up the first time your run the program on a different operating system vers=
ion, hardware or some other circumstances. Or after several weeks of runnin=
g the software continously. It doesn't sound&nbsp;very easy to detect in a =
debug session.</div><div>&nbsp;</div><div>Best wishes</div><div>&nbsp;</div=
><div>Johan</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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_6734_4994575.1393503603685--

.

On Feb 27, 2014, at 7:19 PM, Ville Voutilainen <ville.voutilainen@gmail.com=
> wrote:

> Well, I guess it's certainly possible, for cases where the derived
> class destructor
> is trivial.

The lifetime of trivially-destructible types ends arbitrarily; it doesn't m=
atter whether the destructor runs or not. I don't think the current languag=
e specifies UB if you happen to arbitrarily call the trivial destructor of =
a base subobject before neglecting to call the trivial destructor of the de=
rived class.

Perhaps you're even allowed to call the same trivial destructor twice. I do=
n't see why not; they don't do anything at all. (ATM I had a couple drinks =
and it's bedtime though.)

--=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/.

.

On 27 February 2014 15:25, David Krauss <potswa@gmail.com> wrote:
>
> On Feb 27, 2014, at 7:19 PM, Ville Voutilainen <ville.voutilainen@gmail.c=
om> wrote:
>
>> Well, I guess it's certainly possible, for cases where the derived
>> class destructor
>> is trivial.
>
> The lifetime of trivially-destructible types ends arbitrarily; it doesn't=
 matter whether the destructor runs or not. I don't think the current langu=
age specifies UB if you happen to arbitrarily call the trivial destructor o=
f a base subobject before neglecting to call the trivial destructor of the =
derived class.
>
> Perhaps you're even allowed to call the same trivial destructor twice. I =
don't see why not; they don't do anything at all. (ATM I had a couple drink=
s and it's bedtime though.)

The current wording doesn't care whether the destructors are trivial.
The case we hit
is  [expr.delete]/3, which says
"if the static type of the object to be deleted is different from its
dynamic type, the static type shall be a base class of the dynamic
type of the object to be deleted and the
static type shall have a virtual destructor or the behavior is undefined. "

An alternative case is [expr.delete]/5, which says "If the object
being deleted has incomplete
class type at the point of deletion and the complete class has a
non-trivial destructor or a deallocation function, the behavior is undefine=
d."

That doesn't supersede paragraph 3, as far as I can see. So, as long
as the static and
dynamic type differ, deleting is undefined behavior if the destructor
is not virtual. Therefore,
it doesn't help that either the base or derived destructor is trivial.
That's what this thread
is originally proposing to change.

--=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/.

.

On 27 February 2014 14:20,  <williamsson@gmail.com> wrote:
> Ville, are you referring to Clang's UB sanitizer? Is this situation really
> so easily detectable and this tool can tell where you made the mistake? That
> is not my personal experience from the tools I'm using, but I guess I should
> test with some other tools as well.

I do not know whether that particular sanitizer (which is not
clang-specific, I might
add) supports this particular case. But I do not expect adding such
support to be
too difficult.

>
> However, it's my understanding that undefined behaviour does not necessarily
> manifest itself in any measurable way. Or it may show up the first time your
> run the program on a different operating system version, hardware or some
> other circumstances. Or after several weeks of running the software
> continously. It doesn't sound very easy to detect in a debug session.

All of these problems apply equally well to the cases where you don't invoke
a destructor you intended to invoke. Whether an implementation gives you
sane results for such UB cases is up to the implementation. Whether making
the case this thread is about ends up having sane results is up to the user
code. I prefer giving an implementation a chance to mark all of these cases
invalid, rather than relying on the users to instrument what they need
and figure
out which valid cases are actually valid and which ones are actually invalid.

Just in case it's not clear, based on what I have written on this
subject, you can
expect national body opposition to this proposal.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e013cba9657de7204f3654deb
Content-Type: text/plain; charset=ISO-8859-1

I believe that the original question is not addressed only to types with
trivial destructors as defined in the standard, but rather to types for
which the dynamic type's destructor does not do anything other than calling
the static type's destructor. Something like:

struct base {
   std::string s;
};
struct derived : base {
};
delete static_cast<base*>(new derived);

The destructor is not trivial, as the base's destructor is not trivial, but
Johan believes that since '~derived' does not do anything other than
calling '~base' and that one will be called in that 'delete' expression.

Other than that, I am not sure I buy into that use case. If the type does
not have a virtual destructor, it was most probably not designed to be a
base of anything else, and in that case you might be abusing inheritance.
If you only want convenience constructors (as you mentioned), you can
always do that externally by creating functions that will create the object
and set it to the correct state. The design looks suspicious...


On Thu, Feb 27, 2014 at 8:25 AM, David Krauss <potswa@gmail.com> wrote:

>
> On Feb 27, 2014, at 7:19 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
> > Well, I guess it's certainly possible, for cases where the derived
> > class destructor
> > is trivial.
>
> The lifetime of trivially-destructible types ends arbitrarily; it doesn't
> matter whether the destructor runs or not. I don't think the current
> language specifies UB if you happen to arbitrarily call the trivial
> destructor of a base subobject before neglecting to call the trivial
> destructor of the derived class.
>
> Perhaps you're even allowed to call the same trivial destructor twice. I
> don't see why not; they don't do anything at all. (ATM I had a couple
> drinks and it's bedtime though.)
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e013cba9657de7204f3654deb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I believe that the original question is not addressed only=
 to types with trivial destructors as defined in the standard, but rather t=
o types for which the dynamic type&#39;s destructor does not do anything ot=
her than calling the static type&#39;s destructor. Something like:<br>
<br>struct base {<br>=A0 =A0std::string s;<br>};<br>struct derived : base {=
<br>};<br>delete static_cast&lt;base*&gt;(new derived);<br><br>The destruct=
or is not trivial, as the base&#39;s destructor is not trivial, but Johan b=
elieves that since &#39;~derived&#39; does not do anything other than calli=
ng &#39;~base&#39; and that one will be called in that &#39;delete&#39; exp=
ression. <br>
<br>Other than that, I am not sure I buy into that use case. If the type do=
es not have a virtual destructor, it was most probably not designed to be a=
 base of anything else, and in that case you might be abusing inheritance. =
If you only want convenience constructors (as you mentioned), you can alway=
s do that externally by creating functions that will create the object and =
set it to the correct state. The design looks suspicious...</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Feb 2=
7, 2014 at 8:25 AM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:po=
tswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div class=3D""><br>
On Feb 27, 2014, at 7:19 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.=
voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Well, I guess it&#39;s certainly possible, for cases where the derived=
<br>
&gt; class destructor<br>
&gt; is trivial.<br>
<br>
</div>The lifetime of trivially-destructible types ends arbitrarily; it doe=
sn&#39;t matter whether the destructor runs or not. I don&#39;t think the c=
urrent language specifies UB if you happen to arbitrarily call the trivial =
destructor of a base subobject before neglecting to call the trivial destru=
ctor of the derived class.<br>

<br>
Perhaps you&#39;re even allowed to call the same trivial destructor twice. =
I don&#39;t see why not; they don&#39;t do anything at all. (ATM I had a co=
uple drinks and it&#39;s bedtime though.)<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--089e013cba9657de7204f3654deb--

.

--001a1134d69c65e81004f36590cd
Content-Type: text/plain; charset=ISO-8859-1

On 26 February 2014 17:13, <williamsson@gmail.com> wrote:

> It's common to derive from a class and only add things like convenience
> constructors. That means the memory footprint (and object size) of the base
> class and the derived class is exactly the same and there's no risk of
> dangerous slicing.
>

Memory footprint: yes.  Behavior: no.

When there are no derived members to destroy, this may "only" lead to
> unexpected results (resources not being released, or whatever the omitted
> destructor was supposed to do unless it's empty) in case of accidential
> deletion through a pointer-to-base.
>

A derived destructor may modify global/static/thread local state or base
class state.

About the only possible rule you could use safely is if you have a derived
class that doesn't add any non-trivially destructible non-static member
variables nor a non-defaulted user declared destructor.

That sounds like a very complicated rule leading to very brittle code.

But at least the behaviour would be defined and reproducable with different
> compilers! I think that is a slightly better (less evil) alternative to
> undefined behaviour, if there's any chance of possible standardization.
>
> Of course, this still does not mean that anyone should intentionally write
> code that deletes via base-to-pointer!
>

The only way the standard can say "don't do that" is by making it undefined
behavior.  If the code is legal, users are allowed to rely on that behavior.

I would be strongly against this, were it to be a proposal.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1134d69c65e81004f36590cd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 26 February 2014 17:13,  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:williamsson@gmail.com" target=3D"_blank">williamsson@gmail.com</=
a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><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><font face=3D"arial,sans-serif">It&#39;s common to de=
rive from a class and only add things like convenience constructors. That m=
eans the memory footprint (and object size) of the base class and the deriv=
ed class is exactly the same and there&#39;s no risk of dangerous slicing. =
</font></div>

</div></blockquote><div><br></div><div>Memory footprint: yes.=A0 Behavior: =
no.<br> <br></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><fon=
t face=3D"arial,sans-serif">When there are no derived members to destroy, t=
his may &quot;only&quot; lead to unexpected results (resources not being re=
leased, or whatever the omitted destructor was supposed to do unless it&#39=
;s empty) in case of accidential deletion through a pointer-to-base.</font>=
</div>

</div></blockquote><div><br></div><div>A derived destructor may modify glob=
al/static/thread local state or base class state.<br><br></div><div>About t=
he only possible rule you could use safely is if you have a derived class t=
hat doesn&#39;t add any non-trivially destructible non-static member variab=
les nor a non-defaulted user declared destructor.<br>

<br>That sounds like a very complicated rule leading to very brittle code.<=
br> <br></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><font fa=
ce=3D"arial,sans-serif"> But at least the behaviour would be defined and re=
producable with different compilers! I think that is a slightly better (les=
s evil) alternative to undefined behaviour, if there&#39;s any chance of po=
ssible standardization.</font></div>

<div><font><br></font></div><div><font face=3D"arial,sans-serif">Of course,=
 this still does not mean that anyone should intentionally write code that =
deletes via base-to-pointer!</font></div></div></blockquote><div><br></div>

<div>The only way the standard can say &quot;don&#39;t do that&quot; is by =
making it undefined behavior.=A0 If the code is legal, users are allowed to=
 rely on that behavior.<br><br></div><div>I would be strongly against this,=
 were it to be a proposal.<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--001a1134d69c65e81004f36590cd--

.

Em qui 27 fev 2014, =E0s 01:01:49, williamsson@gmail.com escreveu:
> The only case when you will have a bug and defined behaviour at the same=
=20
> time, is when the desctructor is non-empty. Of course, this kind of bugs=
=20
> are hard to track down. But if the destructor is supposed to do some work=
,=20
> and for the reason of delete via pointer-to-base is not executed, the=20
> program will not run as you expected it to. There can still be symptoms.=
=20
> Most importantly, the program remains in a valid state. Your system tests=
=20
> will still work in production.

Says who? You just said that some code that was supposed to be run didn't g=
et=20
run. I call that "invalid state".

Example to prove: the derived class's destructor removes the this pointer f=
rom=20
a global list of tracked objects, which was previously added by the=20
constructor. This now means the global list contains a dangling pointer.

It sounds like you want "it's defined behaviour if the derived class(es)=20
destructor(s) are trivial, if you don't count the call to the base class=20
destructor"
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=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/.

.

--Apple-Mail=_0564E55C-7C6D-454C-81C8-5D34EF6F8A09
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On Feb 27, 2014, at 9:31 PM, Ville Voutilainen <ville.voutilainen@gmail.com=
> wrote:

> On 27 February 2014 15:25, David Krauss <potswa@gmail.com> wrote:
>>=20
>> On Feb 27, 2014, at 7:19 PM, Ville Voutilainen <ville.voutilainen@gmail.=
com> wrote:
>>=20
>>> Well, I guess it's certainly possible, for cases where the derived
>>> class destructor
>>> is trivial.
>>=20
>> The lifetime of trivially-destructible types ends arbitrarily; it doesn'=
t matter whether the destructor runs or not. I don't think the current lang=
uage specifies UB if you happen to arbitrarily call the trivial destructor =
of a base subobject before neglecting to call the trivial destructor of the=
 derived class.
>>=20
>> Perhaps you're even allowed to call the same trivial destructor twice. I=
 don't see why not; they don't do anything at all. (ATM I had a couple drin=
ks and it's bedtime though.)
>=20
> The current wording doesn't care whether the destructors are trivial.
> The case we hit
> is  [expr.delete]/3, which says
> "if the static type of the object to be deleted is different from its
> dynamic type, the static type shall be a base class of the dynamic
> type of the object to be deleted and the
> static type shall have a virtual destructor or the behavior is undefined.=
 "

Ah, didn't realize that dynamic type applies to non-polymorphic classes.

There's a slight ambiguity in that paragraph, though. If you consider subob=
jects to be "created by new" along with the complete object, then pointers =
to member subobjects (which are most-derived objects) are valid arguments t=
o delete. References to most-derived object in [expr.delete]/2 should be re=
placed with complete object.

> That doesn't supersede paragraph 3, as far as I can see. So, as long
> as the static and
> dynamic type differ, deleting is undefined behavior if the destructor
> is not virtual. Therefore,
> it doesn't help that either the base or derived destructor is trivial.
> That's what this thread
> is originally proposing to change.

I get the impression he wants to work with real destructors.

Trivial destructors might not be interchangeable with delete, but free stil=
l remains a viable solution as long as the base class overloads operator ne=
w to call malloc. (Or otherwise ensure that malloc is called.)

--=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/.

--Apple-Mail=_0564E55C-7C6D-454C-81C8-5D34EF6F8A09
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 2=
7, 2014, at 9:31 PM, Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilai=
nen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><br class=3D=
"Apple-interchange-newline"><blockquote type=3D"cite">On 27 February 2014 1=
5:25, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gmail.com=
</a>&gt; wrote:<br><blockquote type=3D"cite"><br>On Feb 27, 2014, at 7:19 P=
M, Ville Voutilainen &lt;<a href=3D"mailto:ville.voutilainen@gmail.com">vil=
le.voutilainen@gmail.com</a>&gt; wrote:<br><br><blockquote type=3D"cite">We=
ll, I guess it's certainly possible, for cases where the derived<br>class d=
estructor<br>is trivial.<br></blockquote><br>The lifetime of trivially-dest=
ructible types ends arbitrarily; it doesn't matter whether the destructor r=
uns or not. I don't think the current language specifies UB if you happen t=
o arbitrarily call the trivial destructor of a base subobject before neglec=
ting to call the trivial destructor of the derived class.<br><br>Perhaps yo=
u're even allowed to call the same trivial destructor twice. I don't see wh=
y not; they don't do anything at all. (ATM I had a couple drinks and it's b=
edtime though.)<br></blockquote><br>The current wording doesn't care whethe=
r the destructors are trivial.<br>The case we hit<br>is &nbsp;[expr.delete]=
/3, which says<br>"if the static type of the object to be deleted is differ=
ent from its<br>dynamic type, the static type shall be a base class of the =
dynamic<br>type of the object to be deleted and the<br>static type shall ha=
ve a virtual destructor or the behavior is undefined. &ldquo;</blockquote><=
div><br></div><div>Ah, didn&rsquo;t realize that dynamic type applies to no=
n-polymorphic classes.</div><div><br></div><div>There&rsquo;s a slight ambi=
guity in that paragraph, though. If you consider subobjects to be &ldquo;cr=
eated by new&rdquo; along with the complete object, then pointers to member=
 subobjects (which are most-derived objects) are valid arguments to <font f=
ace=3D"Courier">delete</font>. References to <i>most-derived object</i>&nbs=
p;in [expr.delete]/2 should be replaced with <i>complete object</i>.</div><=
div><br></div><blockquote type=3D"cite">That doesn't supersede paragraph 3,=
 as far as I can see. So, as long<br>as the static and<br>dynamic type diff=
er, deleting is undefined behavior if the destructor<br>is not virtual. The=
refore,<br>it doesn't help that either the base or derived destructor is tr=
ivial.<br>That's what this thread<br>is originally proposing to change.<br>=
</blockquote><div><br></div><div>I get the impression he wants to work with=
 real destructors.</div><div><br></div><div>Trivial destructors might not b=
e interchangeable with <font face=3D"Courier">delete</font>, but&nbsp;<font=
 face=3D"Courier">free</font>&nbsp;still remains a viable solution as long =
as the base class overloads&nbsp;<font face=3D"Courier">operator new</font>=
 to call <font face=3D"Courier">malloc</font>. (Or otherwise ensure that <f=
ont face=3D"Courier">malloc</font> is called.)</div></div><br></body></html=
>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />

--Apple-Mail=_0564E55C-7C6D-454C-81C8-5D34EF6F8A09--

.