Topic: Internal swap-ing mechanism, All types swap-able
Author: Christ-Jan Wijtmans <cj.wijtmans@gmail.com>
Date: Sun, 16 Mar 2014 03:55:44 -0700 (PDT)
Raw View
------=_Part_4576_14767694.1394967345000
Content-Type: text/plain; charset=UTF-8
Hmm i posted the wrong output of the first test code.
But i believe this makes C++ more RAII friendly compared to the current
situation.
--
---
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_4576_14767694.1394967345000
Content-Type: text/html; charset=UTF-8
<div dir="ltr"><div>Hmm i posted the wrong output of the first test code. <br>But i believe this makes C++ more RAII friendly compared to the current situation.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<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 />
------=_Part_4576_14767694.1394967345000--
.
Author: Christ-Jan Wijtmans <cj.wijtmans@gmail.com>
Date: Sun, 16 Mar 2014 04:09:31 -0700 (PDT)
Raw View
------=_Part_4435_11680712.1394968171470
Content-Type: text/plain; charset=UTF-8
I would like to note that the current behavior could stay for structs so
that they stay compatible with C.
Also it would keep structs useful for PODs. I would go even so far as to
disallow constructors, destructors, virtuals or class members being in
structs so that they are guaranteed to be PODs and compatible with C.
Making them differentiated from classes with default copy and move behavior
that respect RAII.
--
---
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_4435_11680712.1394968171470
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I would like to note that the current behavior could stay =
for structs so that they stay compatible with C.<br>Also it would keep stru=
cts useful for PODs. I would go even so far as to disallow constructors, de=
structors, virtuals or class members being in structs so that they are guar=
anteed to be PODs and compatible with C.<br>Making them differentiated from=
classes with default copy and move behavior that respect RAII.</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_4435_11680712.1394968171470--
.
Author: Philipp Maximilian Stephani <p.stephani2@gmail.com>
Date: Sun, 16 Mar 2014 15:21:35 +0000
Raw View
--20cf307f3256ccfd9204f4badb8c
Content-Type: text/plain; charset=UTF-8
Such a change (forcing all structs to be POD) would break billions of lines
of working code and will therefore not happen.
On Sun Mar 16 2014 at 12:09:32, Christ-Jan Wijtmans <cj.wijtmans@gmail.com>
wrote:
> I would like to note that the current behavior could stay for structs so
> that they stay compatible with C.
> Also it would keep structs useful for PODs. I would go even so far as to
> disallow constructors, destructors, virtuals or class members being in
> structs so that they are guaranteed to be PODs and compatible with C.
> Making them differentiated from classes with default copy and move
> behavior that respect RAII.
>
> --
>
> ---
> 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/.
--20cf307f3256ccfd9204f4badb8c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Such a change (forcing all structs to be POD) would break billions of lines=
of working code and will therefore not happen.<br><br><div>On Sun Mar 16 2=
014 at 12:09:32, Christ-Jan Wijtmans <<a href=3D"mailto:cj.wijtmans@gmai=
l.com">cj.wijtmans@gmail.com</a>> wrote:</div>
<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">I would like to note that t=
he current behavior could stay for structs so that they stay compatible wit=
h C.<br>
Also it would keep structs useful for PODs. I would go even so far as to di=
sallow constructors, destructors, virtuals or class members being in struct=
s so that they are guaranteed to be PODs and compatible with C.<br>Making t=
hem differentiated from classes with default copy and move behavior that re=
spect RAII.</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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote>
<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 />
--20cf307f3256ccfd9204f4badb8c--
.
Author: admin@hexadigm.com
Date: Sun, 6 Apr 2014 05:30:21 -0700 (PDT)
Raw View
------=_Part_1110_17064437.1396787421727
Content-Type: text/plain; charset=UTF-8
The fact that an official proposal for this has already been submitted is
welcome news. I've also thought about this idea as I'm sure many others
have. "std::swap()" should probably be deprecated and replaced with a
(non-throwing) "swap()" operator of some type, even if it means just adding
a built-in "swap()" function that could be invoked on all fundamental types
(though some may cringe at this syntax). For classes, the "swap()" operator
(or function call) could then be available as a new special function,
similar to the other special (class) functions, so it would be implicitly
generated as required. The implicit version would simply call the "swap()"
operator (or function) on all its data members (WYSIWYG). While there will
no doubt have to be a careful examination of all this, to ensure no
(subtle/breaking) problems exist, on the surface it seems this would go a
long way to solve a lot of existing confusion surrounding the use use of
the existing "std::swap()" (which is unnatural and potentially error-prone
compared to the above system). For "operator=(Whatever whatever)", maybe we
can all finally see the day where the standard (usual) pattern is to pass
"whatever" by value as seen (creating a "unifying" assignment operator as
it's so often called), and to simply invoke the new (non-throwing) "swap()"
operator on that object, including on all base classes. Details TBD of
course (but the basic pattern is simple and already widely known).
--
---
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_1110_17064437.1396787421727
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The fact that an official proposal for this has already be=
en submitted is welcome news. I've also thought about this idea as I'm sure=
many others have. "std::swap()" should probably be deprecated and replaced=
with a (non-throwing) "swap()" operator of some type, even if it means jus=
t adding a built-in "swap()" function that could be invoked on all fundamen=
tal types (though some may cringe at this syntax). For classes, the "swap()=
" operator (or function call) could then be available as a new special func=
tion, similar to the other special (class) functions, so it would be implic=
itly generated as required. The implicit version would simply call the "swa=
p()" operator (or function) on all its data members (WYSIWYG). While there =
will no doubt have to be a careful examination of all this, to ensure no (s=
ubtle/breaking) problems exist, on the surface it seems this would go a lon=
g way to solve a lot of existing confusion surrounding the use use of the e=
xisting "std::swap()" (which is unnatural and potentially error-prone compa=
red to the above system). For "operator=3D(Whatever whatever)", maybe we ca=
n all finally see the day where the standard (usual) pattern is to pass "wh=
atever" by value as seen (creating a "unifying" assignment operator as it's=
so often called), and to simply invoke the new (non-throwing) "swap()" ope=
rator on that object, including on all base classes. Details TBD of course =
(but the basic pattern is simple and already widely known).</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_1110_17064437.1396787421727--
.