Topic: C++ Inherited Operator Overloading
Author: Jake F <slimercraft3@gmail.com>
Date: Wed, 20 Dec 2017 07:25:27 -0800 (PST)
Raw View
------=_Part_2828_232724837.1513783527361
Content-Type: multipart/alternative;
boundary="----=_Part_2829_871677473.1513783527362"
------=_Part_2829_871677473.1513783527362
Content-Type: text/plain; charset="UTF-8"
To Fellow Members of the community to make C++ better,
As I am sure you are all aware that in C++ you can overload many operators.
Part of this becomes it is annoying to overload the +=, -=, *=, <=, etc,
operators when you already overloaded the +, -, *, < and == operators. My
proposal for C++20 is that there is a class as part of a header already in
C++ which, when you extend it, it allows you to just overload the +, and it
will overload +=. Please comment with suggestions on how to improve this
post.
Attached is some code I made illustrating this proposal and is not complete.
I hope you will consider my proposal,
Jake
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ac2a6df9-35b5-4862-8f5e-d51a7e316eb7%40isocpp.org.
------=_Part_2829_871677473.1513783527362
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To Fellow Members of the community to make C++ better,<div=
><br></div><div>As I am sure you are all aware that in C++ you can overload=
many operators. Part of this becomes it is annoying to overload the +=3D, =
-=3D, *=3D, <=3D, etc, operators when you already overloaded the +, -, *=
, < and =3D=3D operators. My proposal for C++20 is that there is a class=
as part of a header already in C++ which, when you extend it, it allows yo=
u to just overload the +, and it will overload +=3D. Please comment with su=
ggestions on how to improve this post.</div><div><br></div><div>Attached is=
some code I made illustrating this proposal and is not complete.</div><div=
><br></div><div>I hope you will consider my proposal,</div><div><br></div><=
div>Jake</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ac2a6df9-35b5-4862-8f5e-d51a7e316eb7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ac2a6df9-35b5-4862-8f5e-d51a7e316eb7=
%40isocpp.org</a>.<br />
------=_Part_2829_871677473.1513783527362--
------=_Part_2828_232724837.1513783527361
Content-Type: text/x-c++src; charset=US-ASCII; name=proposal.cpp
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=proposal.cpp
X-Attachment-Id: 43eb4c1e-5dd8-46af-bd30-d847ac455e52
Content-ID: <43eb4c1e-5dd8-46af-bd30-d847ac455e52>
#include <iostream>
#include <string>
#include <vector>
#include <bitset>
#include <sstream>
#include <math.h>
#include <fstream>
#include <time.h>
#include <algorithm>
#include <future>
#include <utility>
#include <functional>
using namespace std;
//#include "iostream"
//#include "string"
//#include "sstream"
class QuickOperators
{
public:
template<typename T>
bool operator <=(T obj)
{
return *this < obj && *this == obj;
}
template<typename T>
bool operator >=(T obj)
{
return *this > obj && *this == obj;
}
template<typename T>
bool operator != (T obj)
{
return !(*this == obj);
}
template<typename T>
auto& operator += (T obj)
{
return obj + *this;
}
template<typename T>
auto& operator -= (T obj)
{
return obj - *this;
}
template<typename T>
auto& operator *= (T obj)
{
return obj * *this;
}
template<typename T>
auto& operator /= (T obj)
{
return obj / *this;
}
};
template<typename T, typename A>
void readvalues(const string& line, vector<T>& values) {
istringstream stream(line);
T value;
while (stream >> value) {
values.push_back(value);
}
}
int main()
{
vector<string> d;
readvalues<4>("33333", d);
}
------=_Part_2828_232724837.1513783527361--
.
Author: Bob Fang <dorafmon@gmail.com>
Date: Wed, 20 Dec 2017 07:32:11 -0800 (PST)
Raw View
------=_Part_2818_1710558553.1513783931795
Content-Type: multipart/alternative;
boundary="----=_Part_2819_506592710.1513783931795"
------=_Part_2819_506592710.1513783931795
Content-Type: text/plain; charset="UTF-8"
Have you
used http://www.boost.org/doc/libs/1_55_0/libs/utility/operators.htm?
On Wednesday, 20 December 2017 15:25:27 UTC, Jake F wrote:
>
> To Fellow Members of the community to make C++ better,
>
> As I am sure you are all aware that in C++ you can overload many
> operators. Part of this becomes it is annoying to overload the +=, -=, *=,
> <=, etc, operators when you already overloaded the +, -, *, < and ==
> operators. My proposal for C++20 is that there is a class as part of a
> header already in C++ which, when you extend it, it allows you to just
> overload the +, and it will overload +=. Please comment with suggestions on
> how to improve this post.
>
> Attached is some code I made illustrating this proposal and is not
> complete.
>
> I hope you will consider my proposal,
>
> Jake
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/72bea8a8-f23c-4077-bad8-188f869dcf95%40isocpp.org.
------=_Part_2819_506592710.1513783931795
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Have you used=C2=A0http://www.boost.org/doc/libs/1_55=
_0/libs/utility/operators.htm?</div><div><br></div><div><br>On Wednesday, 2=
0 December 2017 15:25:27 UTC, Jake F wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">To Fellow Members of the community to make C=
++ better,<div><br></div><div>As I am sure you are all aware that in C++ yo=
u can overload many operators. Part of this becomes it is annoying to overl=
oad the +=3D, -=3D, *=3D, <=3D, etc, operators when you already overload=
ed the +, -, *, < and =3D=3D operators. My proposal for C++20 is that th=
ere is a class as part of a header already in C++ which, when you extend it=
, it allows you to just overload the +, and it will overload +=3D. Please c=
omment with suggestions on how to improve this post.</div><div><br></div><d=
iv>Attached is some code I made illustrating this proposal and is not compl=
ete.</div><div><br></div><div>I hope you will consider my proposal,</div><d=
iv><br></div><div>Jake</div></div></blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/72bea8a8-f23c-4077-bad8-188f869dcf95%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/72bea8a8-f23c-4077-bad8-188f869dcf95=
%40isocpp.org</a>.<br />
------=_Part_2819_506592710.1513783931795--
------=_Part_2818_1710558553.1513783931795--
.
Author: Jake F <slimercraft3@gmail.com>
Date: Wed, 20 Dec 2017 07:34:10 -0800 (PST)
Raw View
------=_Part_2780_2061355302.1513784050702
Content-Type: multipart/alternative;
boundary="----=_Part_2781_187703842.1513784050702"
------=_Part_2781_187703842.1513784050702
Content-Type: text/plain; charset="UTF-8"
Please ignore the parts of original not part of the QuickOperators class. I
do not know how to remove the bottom portion.
On Wednesday, December 20, 2017 at 10:25:27 AM UTC-5, Jake F wrote:
>
> To Fellow Members of the community to make C++ better,
>
> As I am sure you are all aware that in C++ you can overload many
> operators. Part of this becomes it is annoying to overload the +=, -=, *=,
> <=, etc, operators when you already overloaded the +, -, *, < and ==
> operators. My proposal for C++20 is that there is a class as part of a
> header already in C++ which, when you extend it, it allows you to just
> overload the +, and it will overload +=. Please comment with suggestions on
> how to improve this post.
>
> Attached is some code I made illustrating this proposal and is not
> complete.
>
> I hope you will consider my proposal,
>
> Jake
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3a901434-e3fc-4db2-8cb7-ca1c37d75a82%40isocpp.org.
------=_Part_2781_187703842.1513784050702
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Please ignore the parts of original not part of the=C2=A0<=
span style=3D"color: rgb(0, 0, 0); white-space: pre-wrap;">QuickOperators c=
lass. I do not know how to remove the bottom portion.</span><br><br>On Wedn=
esday, December 20, 2017 at 10:25:27 AM UTC-5, Jake F 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">To Fellow Members of the com=
munity to make C++ better,<div><br></div><div>As I am sure you are all awar=
e that in C++ you can overload many operators. Part of this becomes it is a=
nnoying to overload the +=3D, -=3D, *=3D, <=3D, etc, operators when you =
already overloaded the +, -, *, < and =3D=3D operators. My proposal for =
C++20 is that there is a class as part of a header already in C++ which, wh=
en you extend it, it allows you to just overload the +, and it will overloa=
d +=3D. Please comment with suggestions on how to improve this post.</div><=
div><br></div><div>Attached is some code I made illustrating this proposal =
and is not complete.</div><div><br></div><div>I hope you will consider my p=
roposal,</div><div><br></div><div>Jake</div></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3a901434-e3fc-4db2-8cb7-ca1c37d75a82%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3a901434-e3fc-4db2-8cb7-ca1c37d75a82=
%40isocpp.org</a>.<br />
------=_Part_2781_187703842.1513784050702--
------=_Part_2780_2061355302.1513784050702--
.
Author: Jake F <slimercraft3@gmail.com>
Date: Wed, 20 Dec 2017 07:39:13 -0800 (PST)
Raw View
------=_Part_2898_263992540.1513784353412
Content-Type: multipart/alternative;
boundary="----=_Part_2899_1161122818.1513784353413"
------=_Part_2899_1161122818.1513784353413
Content-Type: text/plain; charset="UTF-8"
This is a proposal to include a function similar to that in STL however the
key difference is that this is templated so you can have many different
types and not just ones extending the class.
On Wednesday, December 20, 2017 at 10:32:11 AM UTC-5, Bob Fang wrote:
>
> Have you used
> http://www.boost.org/doc/libs/1_55_0/libs/utility/operators.htm?
>
>
> On Wednesday, 20 December 2017 15:25:27 UTC, Jake F wrote:
>>
>> To Fellow Members of the community to make C++ better,
>>
>> As I am sure you are all aware that in C++ you can overload many
>> operators. Part of this becomes it is annoying to overload the +=, -=, *=,
>> <=, etc, operators when you already overloaded the +, -, *, < and ==
>> operators. My proposal for C++20 is that there is a class as part of a
>> header already in C++ which, when you extend it, it allows you to just
>> overload the +, and it will overload +=. Please comment with suggestions on
>> how to improve this post.
>>
>> Attached is some code I made illustrating this proposal and is not
>> complete.
>>
>> I hope you will consider my proposal,
>>
>> Jake
>>
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f9c3188c-5730-41bf-a880-cc59ac115951%40isocpp.org.
------=_Part_2899_1161122818.1513784353413
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This is a proposal to include a function similar to that i=
n STL however the key difference is that this is templated so you can have =
many different types and not just ones extending the class.<br><br>On Wedne=
sday, December 20, 2017 at 10:32:11 AM UTC-5, Bob Fang wrote:<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"><div>Have you used=C2=A0<a =
href=3D"http://www.boost.org/doc/libs/1_55_0/libs/utility/operators.htm" ta=
rget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_0%2Flib=
s%2Futility%2Foperators.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHd1kEag=
H-HiswX8CfvszlyDR8z8Q';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_55_0%2=
Flibs%2Futility%2Foperators.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHd1=
kEagH-HiswX8CfvszlyDR8z8Q';return true;">http://www.boost.org/doc/<wbr>=
libs/1_55_0/libs/utility/<wbr>operators.htm</a>?</div><div><br></div><div><=
br>On Wednesday, 20 December 2017 15:25:27 UTC, Jake F wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">To Fellow Members of the commun=
ity to make C++ better,<div><br></div><div>As I am sure you are all aware t=
hat in C++ you can overload many operators. Part of this becomes it is anno=
ying to overload the +=3D, -=3D, *=3D, <=3D, etc, operators when you alr=
eady overloaded the +, -, *, < and =3D=3D operators. My proposal for C++=
20 is that there is a class as part of a header already in C++ which, when =
you extend it, it allows you to just overload the +, and it will overload +=
=3D. Please comment with suggestions on how to improve this post.</div><div=
><br></div><div>Attached is some code I made illustrating this proposal and=
is not complete.</div><div><br></div><div>I hope you will consider my prop=
osal,</div><div><br></div><div>Jake</div></div></blockquote></div></div></b=
lockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f9c3188c-5730-41bf-a880-cc59ac115951%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f9c3188c-5730-41bf-a880-cc59ac115951=
%40isocpp.org</a>.<br />
------=_Part_2899_1161122818.1513784353413--
------=_Part_2898_263992540.1513784353412--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 07:45:17 -0800 (PST)
Raw View
------=_Part_2859_520199674.1513784717743
Content-Type: multipart/alternative;
boundary="----=_Part_2860_1020549804.1513784717743"
------=_Part_2860_1020549804.1513784717743
Content-Type: text/plain; charset="UTF-8"
Regardless of the quality of the proposal, you should remove the `<=` and
`=>` from the proposal. With the advent of the spaceship operator,* nobody*
is going to be overloading them directly anymore. Not unless they're doing
some DSEL-style work, in which case they'll *want* to overload them
manually.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5ee4e50f-fd74-451f-b1b6-37ab47a22288%40isocpp.org.
------=_Part_2860_1020549804.1513784717743
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Regardless of the quality of the proposal, you should remo=
ve the `<=3D` and `=3D>` from the proposal. With the advent of the sp=
aceship operator,<i> nobody</i> is going to be overloading them directly an=
ymore. Not unless they're doing some DSEL-style work, in which case the=
y'll <i>want</i> to overload them manually.<br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5ee4e50f-fd74-451f-b1b6-37ab47a22288%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5ee4e50f-fd74-451f-b1b6-37ab47a22288=
%40isocpp.org</a>.<br />
------=_Part_2860_1020549804.1513784717743--
------=_Part_2859_520199674.1513784717743--
.
Author: slimercraft3@gmail.com
Date: Wed, 20 Dec 2017 07:47:18 -0800 (PST)
Raw View
------=_Part_3043_1911255129.1513784838621
Content-Type: multipart/alternative;
boundary="----=_Part_3044_2141087745.1513784838622"
------=_Part_3044_2141087745.1513784838622
Content-Type: text/plain; charset="UTF-8"
Ok Nicol Bolas I will remove them from my proposal here is an updated copy.
On Wednesday, December 20, 2017 at 10:45:17 AM UTC-5, Nicol Bolas wrote:
>
> Regardless of the quality of the proposal, you should remove the `<=` and
> `=>` from the proposal. With the advent of the spaceship operator,*
> nobody* is going to be overloading them directly anymore. Not unless
> they're doing some DSEL-style work, in which case they'll *want* to
> overload them manually.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d788149e-b39a-4bb8-8c25-65fd9a04738f%40isocpp.org.
------=_Part_3044_2141087745.1513784838622
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ok Nicol Bolas I will remove them from my proposal here is=
an updated copy.<div><br></div><div><br><br>On Wednesday, December 20, 201=
7 at 10:45:17 AM UTC-5, Nicol Bolas 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">Regardless of the quality of the proposal, you=
should remove the `<=3D` and `=3D>` from the proposal. With the adve=
nt of the spaceship operator,<i> nobody</i> is going to be overloading them=
directly anymore. Not unless they're doing some DSEL-style work, in wh=
ich case they'll <i>want</i> to overload them manually.<br></div></bloc=
kquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d788149e-b39a-4bb8-8c25-65fd9a04738f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d788149e-b39a-4bb8-8c25-65fd9a04738f=
%40isocpp.org</a>.<br />
------=_Part_3044_2141087745.1513784838622--
------=_Part_3043_1911255129.1513784838621
Content-Type: text/x-c++src; charset=US-ASCII; name="proposal (1).cpp"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="proposal (1).cpp"
X-Attachment-Id: 3fec83bc-53da-456c-9c59-51e1c3554c10
Content-ID: <3fec83bc-53da-456c-9c59-51e1c3554c10>
#include <iostream>
#include <string>
#include <vector>
#include <bitset>
#include <sstream>
#include <math.h>
#include <fstream>
#include <time.h>
#include <algorithm>
#include <future>
#include <utility>
#include <functional>
using namespace std;
//#include "iostream"
//#include "string"
//#include "sstream"
class QuickOperators
{
public:
template<typename T>
bool operator != (T obj)
{
return !(*this == obj);
}
template<typename T>
auto& operator += (T obj)
{
return obj + *this;
}
template<typename T>
auto& operator -= (T obj)
{
return obj - *this;
}
template<typename T>
auto& operator *= (T obj)
{
return obj * *this;
}
template<typename T>
auto& operator /= (T obj)
{
return obj / *this;
}
};
------=_Part_3043_1911255129.1513784838621--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Wed, 20 Dec 2017 15:47:55 +0000
Raw View
--001a1137b910c91fab0560c781e6
Content-Type: text/plain; charset="UTF-8"
I encounter this quite often, and I see a more flexible approach - an
automatic +() given an +=() and a copy constructor, OR an automatic +=
given a +() and a move assignment operator. I do not believe the solution
is inheritance, though - that's not a particularly common C++ approach for
adding functionality in this way.
It makes more sense to me to just have the standard instruct that these
methods are generated automatically if they are absent and their
requirements are satisfied. This kind of method creation is already done in
C++ in different situations. Obviously the generated operators may not be
optimal, but the developer has every opportunity to write them out manually
later on. It is non-breaking.
On 20 Dec 2017 15:25, "Jake F" <slimercraft3@gmail.com> wrote:
To Fellow Members of the community to make C++ better,
As I am sure you are all aware that in C++ you can overload many operators.
Part of this becomes it is annoying to overload the +=, -=, *=, <=, etc,
operators when you already overloaded the +, -, *, < and == operators. My
proposal for C++20 is that there is a class as part of a header already in
C++ which, when you extend it, it allows you to just overload the +, and it
will overload +=. Please comment with suggestions on how to improve this
post.
Attached is some code I made illustrating this proposal and is not complete.
I hope you will consider my proposal,
Jake
--
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.
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/ac2a6df9-35b5-4862-
8f5e-d51a7e316eb7%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ac2a6df9-35b5-4862-8f5e-d51a7e316eb7%40isocpp.org?utm_medium=email&utm_source=footer>
..
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOvxYSRY3W8RKg-q9wQ8H%2Bu_y%2BbJPfkNDkXqn5TuSWJxA%40mail.gmail.com.
--001a1137b910c91fab0560c781e6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>I encounter this quite often, and I see a more flexi=
ble approach - an automatic +() given an +=3D() and a copy constructor, OR =
an automatic +=3D given a +() and a move assignment operator. I do not beli=
eve the solution is inheritance, though - that's not a particularly com=
mon C++ approach for adding functionality in this way.</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">It makes more sense to me to just have the s=
tandard instruct that these methods are generated automatically if they are=
absent and their requirements are satisfied. This kind of method creation =
is already done in C++ in different situations. Obviously the generated ope=
rators may not be optimal, but the developer has every opportunity to write=
them out manually later on. It is non-breaking.<br><div class=3D"gmail_ext=
ra" dir=3D"auto"><br><div class=3D"gmail_quote">On 20 Dec 2017 15:25, "=
;Jake F" <<a href=3D"mailto:slimercraft3@gmail.com">slimercraft3@gm=
ail.com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">To Fellow Members of the community to make C++ better,<div><b=
r></div><div>As I am sure you are all aware that in C++ you can overload ma=
ny operators. Part of this becomes it is annoying to overload the +=3D, -=
=3D, *=3D, <=3D, etc, operators when you already overloaded the +, -, *,=
< and =3D=3D operators. My proposal for C++20 is that there is a class =
as part of a header already in C++ which, when you extend it, it allows you=
to just overload the +, and it will overload +=3D. Please comment with sug=
gestions on how to improve this post.</div><div><br></div><div>Attached is =
some code I made illustrating this proposal and is not complete.</div><div>=
<br></div><div>I hope you will consider my proposal,</div><div><br></div><d=
iv>Jake</div></div><font color=3D"#888888">
<p></p>
-- <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@<wbr>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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ac2a6df9-35b5-4862-8f5e-d51a7e316eb7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/ac2a=
6df9-35b5-4862-<wbr>8f5e-d51a7e316eb7%40isocpp.org</a><wbr>.<br>
</font></blockquote></div><br></div></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOvxYSRY3W8RKg-q9wQ8H%2Bu_y%2=
BbJPfkNDkXqn5TuSWJxA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOv=
xYSRY3W8RKg-q9wQ8H%2Bu_y%2BbJPfkNDkXqn5TuSWJxA%40mail.gmail.com</a>.<br />
--001a1137b910c91fab0560c781e6--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 07:55:25 -0800 (PST)
Raw View
------=_Part_3029_251601135.1513785325550
Content-Type: multipart/alternative;
boundary="----=_Part_3030_702382531.1513785325550"
------=_Part_3030_702382531.1513785325550
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 10:47:57 AM UTC-5, Jake Arkinstall wrote:
>
> I encounter this quite often, and I see a more flexible approach - an
> automatic +() given an +=() and a copy constructor, OR an automatic +=
> given a +() and a move assignment operator. I do not believe the solution
> is inheritance, though - that's not a particularly common C++ approach for
> adding functionality in this way.
>
I disagree with this. We should not assume that a type for which `+` is
valid is also a type for which `+=` would be valid even if it is copyable.
It might be OK for a user to request generation of such functions
explicitly, but it should not be something the standard imposes on types.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9d752e6c-b0d5-4412-8174-61019822b4a9%40isocpp.org.
------=_Part_3030_702382531.1513785325550
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, December 20, 2017 at 10:47:57 AM UTC-5, Jake=
Arkinstall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
auto"><div>I encounter this quite often, and I see a more flexible approach=
- an automatic +() given an +=3D() and a copy constructor, OR an automatic=
+=3D given a +() and a move assignment operator. I do not believe the solu=
tion is inheritance, though - that's not a particularly common C++ appr=
oach for adding functionality in this way.</div></div></blockquote><div><br=
></div><div>I disagree with this. We should not assume that a type for whic=
h `+` is valid is also a type for which `+=3D` would be valid even if it is=
copyable. It might be OK for a user to request generation of such function=
s explicitly, but it should not be something the standard imposes on types.=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9d752e6c-b0d5-4412-8174-61019822b4a9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9d752e6c-b0d5-4412-8174-61019822b4a9=
%40isocpp.org</a>.<br />
------=_Part_3030_702382531.1513785325550--
------=_Part_3029_251601135.1513785325550--
.
Author: Jake Arkinstall <jake.arkinstall@gmail.com>
Date: Wed, 20 Dec 2017 16:09:18 +0000
Raw View
--001a113db576443aa70560c7cee1
Content-Type: text/plain; charset="UTF-8"
On 20 Dec 2017 15:55, "Nicol Bolas" <jmckesson@gmail.com> wrote:
I disagree with this. We should not assume that a type for which `+` is
valid is also a type for which `+=` would be valid even if it is copyable.
Is that not the essential definition of += in the first place? Bear in mind
I am talking about:
T& operator+(const T&) const;
T& operator+(const S&) const;
Not an operator that returns a different type. If you can add something to
an object and return an object of the same type, and you can assign that
object of the same type to the original object, as you describe, then the
+= should do the same thing (albeit potentially more efficient). Perhaps
you can provide an example of where this would produce an unexpected
problem, but as far as I can see it makes absolute sense for peculiar
behaviour of + and = to be assumed to carry through to +=.
It might be OK for a user to request generation of such functions
explicitly, but it should not be something the standard imposes on types.
If it is not valid, we do exactly what we always do when we don't want a
compiler to generate extra methods. Delete them. But as current code
without this change is only modified in the absense of these methods, and
thus these methods are not used in working code, nothing is broken by
neglecting to delete these methods.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOKw1t04ozpYq0erbsV_N3B5Rm-87kRRYg0efkfniDB%2BA%40mail.gmail.com.
--001a113db576443aa70560c7cee1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><div class=3D"gmail_extra"><div class=3D"gmail_quote=
">On 20 Dec 2017 15:55, "Nicol Bolas" <<a href=3D"mailto:jmcke=
sson@gmail.com">jmckesson@gmail.com</a>> wrote:<br type=3D"attribution">=
<blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"quoted-text"><div>I=
disagree with this. We should not assume that a type for which `+` is vali=
d is also a type for which `+=3D` would be valid even if it is copyable.</d=
iv></div></div></blockquote></div></div></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Is that not the essential definition of +=3D in the first =
place? Bear in mind I am talking about:</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">T& operator+(const T&) const;</div><div dir=3D"auto=
">T& operator+(const S&) const;</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Not an operator that returns a different type. If you can a=
dd something to an object and return an object of the same type, and you ca=
n assign that object of the same type to the original object, as you descri=
be, then the +=3D should do the same thing (albeit potentially more efficie=
nt). Perhaps you can provide an example of where this would produce an unex=
pected problem, but as far as I can see it makes absolute sense for peculia=
r behaviour of + and =3D to be assumed to carry through to +=3D.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D=
"quoted-text"><div>It might be OK for a user to request generation of such =
functions explicitly, but it should not be something the standard imposes o=
n types.<br></div></div></div></blockquote></div></div></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">If it is not valid, we do exactly what we a=
lways do when we don't want a compiler to generate extra methods. Delet=
e them. But as current code without this change is only modified in the abs=
ense of these methods, and thus these methods are not used in working code,=
nothing is broken by neglecting to delete these methods.</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOKw1t04ozpYq0erbsV_N3B5Rm-87=
kRRYg0efkfniDB%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCOKw1=
t04ozpYq0erbsV_N3B5Rm-87kRRYg0efkfniDB%2BA%40mail.gmail.com</a>.<br />
--001a113db576443aa70560c7cee1--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 20 Dec 2017 08:12:21 -0800 (PST)
Raw View
------=_Part_3017_1736377285.1513786341994
Content-Type: multipart/alternative;
boundary="----=_Part_3018_1692955604.1513786341995"
------=_Part_3018_1692955604.1513786341995
Content-Type: text/plain; charset="UTF-8"
On Wednesday, December 20, 2017 at 11:09:20 AM UTC-5, Jake Arkinstall wrote:
>
> On 20 Dec 2017 15:55, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
>
> I disagree with this. We should not assume that a type for which `+` is
> valid is also a type for which `+=` would be valid even if it is copyable.
>
>
> Is that not the essential definition of += in the first place? Bear in
> mind I am talking about:
>
> T& operator+(const T&) const;
> T& operator+(const S&) const;
>
> Not an operator that returns a different type. If you can add something to
> an object and return an object of the same type, and you can assign that
> object of the same type to the original object, as you describe, then the
> += should do the same thing (albeit potentially more efficient). Perhaps
> you can provide an example of where this would produce an unexpected
> problem, but as far as I can see it makes absolute sense for peculiar
> behaviour of + and = to be assumed to carry through to +=.
>
> It might be OK for a user to request generation of such functions
> explicitly, but it should not be something the standard imposes on types.
>
>
> If it is not valid, we do exactly what we always do when we don't want a
> compiler to generate extra methods. Delete them.
>
But we're talking about methods that were not generated before. The usual
way to allow a type to have `+` but not `+=` was to not declare a `+=` at
all. You're now changing the meaning of their code.
That's bad.
But as current code without this change is only modified in the absense of
> these methods, and thus these methods are not used in working code, nothing
> is broken by neglecting to delete these methods.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/96733364-a01d-47ef-a6d5-ac871badce1f%40isocpp.org.
------=_Part_3018_1692955604.1513786341995
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, December 20, 2017 at 11:09:20 AM UTC=
-5, Jake Arkinstall 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"auto"><div><div><div class=3D"gmail_quote">On 20 Dec 2017 15:55, &q=
uot;Nicol Bolas" <<a onmousedown=3D"this.href=3D'javascript:=
9;;return true;" onclick=3D"this.href=3D'javascript:';return true;"=
href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mai=
lto=3D"lcVi72HjBQAJ">jmck...@gmail.com</a>> wrote:<br type=3D"attributio=
n"><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div><div>I disagree with this. We should not =
assume that a type for which `+` is valid is also a type for which `+=3D` w=
ould be valid even if it is copyable.</div></div></div></blockquote></div><=
/div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Is that not the es=
sential definition of +=3D in the first place? Bear in mind I am talking ab=
out:</div><div dir=3D"auto"><br></div><div dir=3D"auto">T& operator+(co=
nst T&) const;</div><div dir=3D"auto">T& operator+(const S&) co=
nst;</div><div dir=3D"auto"><br></div><div dir=3D"auto">Not an operator tha=
t returns a different type. If you can add something to an object and retur=
n an object of the same type, and you can assign that object of the same ty=
pe to the original object, as you describe, then the +=3D should do the sam=
e thing (albeit potentially more efficient). Perhaps you can provide an exa=
mple of where this would produce an unexpected problem, but as far as I can=
see it makes absolute sense for peculiar behaviour of + and =3D to be assu=
med to carry through to +=3D.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto"><div><div class=3D"gmail_quote"><blockquote style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>I=
t might be OK for a user to request generation of such functions explicitly=
, but it should not be something the standard imposes on types.<br></div></=
div></div></blockquote></div></div></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">If it is not valid, we do exactly what we always do when we don=
't want a compiler to generate extra methods. Delete them.</div></div><=
/blockquote><div><br></div><div>But we're talking about methods that we=
re not generated before. The usual way to allow a type to have `+` but not =
`+=3D` was to not declare a `+=3D` at all. You're now changing the mean=
ing of their code.</div><div><br></div><div>That's bad.</div><div><br><=
/div><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"auto"><div di=
r=3D"auto">But as current code without this change is only modified in the =
absense of these methods, and thus these methods are not used in working co=
de, nothing is broken by neglecting to delete these methods.</div></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/96733364-a01d-47ef-a6d5-ac871badce1f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/96733364-a01d-47ef-a6d5-ac871badce1f=
%40isocpp.org</a>.<br />
------=_Part_3018_1692955604.1513786341995--
------=_Part_3017_1736377285.1513786341994--
.
Author: slimercraft3@gmail.com
Date: Wed, 20 Dec 2017 08:23:16 -0800 (PST)
Raw View
------=_Part_2975_966240425.1513786997060
Content-Type: multipart/alternative;
boundary="----=_Part_2976_1484902990.1513786997060"
------=_Part_2976_1484902990.1513786997060
Content-Type: text/plain; charset="UTF-8"
If it is done with inheritance then the user can determine if the
functionality provided is needed. Also it could be they just overload it
with an error to prevent it.
On Wednesday, December 20, 2017 at 11:12:22 AM UTC-5, Nicol Bolas wrote:
>
>
>
> On Wednesday, December 20, 2017 at 11:09:20 AM UTC-5, Jake Arkinstall
> wrote:
>>
>> On 20 Dec 2017 15:55, "Nicol Bolas" <jmck...@gmail.com> wrote:
>>
>> I disagree with this. We should not assume that a type for which `+` is
>> valid is also a type for which `+=` would be valid even if it is copyable.
>>
>>
>> Is that not the essential definition of += in the first place? Bear in
>> mind I am talking about:
>>
>> T& operator+(const T&) const;
>> T& operator+(const S&) const;
>>
>> Not an operator that returns a different type. If you can add something
>> to an object and return an object of the same type, and you can assign that
>> object of the same type to the original object, as you describe, then the
>> += should do the same thing (albeit potentially more efficient). Perhaps
>> you can provide an example of where this would produce an unexpected
>> problem, but as far as I can see it makes absolute sense for peculiar
>> behaviour of + and = to be assumed to carry through to +=.
>>
>> It might be OK for a user to request generation of such functions
>> explicitly, but it should not be something the standard imposes on types.
>>
>>
>> If it is not valid, we do exactly what we always do when we don't want a
>> compiler to generate extra methods. Delete them.
>>
>
> But we're talking about methods that were not generated before. The usual
> way to allow a type to have `+` but not `+=` was to not declare a `+=` at
> all. You're now changing the meaning of their code.
>
> That's bad.
>
> But as current code without this change is only modified in the absense of
>> these methods, and thus these methods are not used in working code, nothing
>> is broken by neglecting to delete these methods.
>>
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ae0ff397-3d89-417d-82d3-ec56c818e1d3%40isocpp.org.
------=_Part_2976_1484902990.1513786997060
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If it is done with inheritance then the user can determine=
if the functionality provided is needed. Also it could be they just overlo=
ad it with an error to prevent it.<br><br>On Wednesday, December 20, 2017 a=
t 11:12:22 AM UTC-5, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><br><br>On Wednesday, December 20, 2017 at 11:09:=
20 AM UTC-5, Jake Arkinstall 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"auto"><div><div><div class=3D"gmail_quote">On 20 Dec 2017 15:5=
5, "Nicol Bolas" <<a rel=3D"nofollow">jmck...@gmail.com</a>>=
; wrote:<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>I disa=
gree with this. We should not assume that a type for which `+` is valid is =
also a type for which `+=3D` would be valid even if it is copyable.</div></=
div></div></blockquote></div></div></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">Is that not the essential definition of +=3D in the first place=
? Bear in mind I am talking about:</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">T& operator+(const T&) const;</div><div dir=3D"auto">T&a=
mp; operator+(const S&) const;</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Not an operator that returns a different type. If you can add so=
mething to an object and return an object of the same type, and you can ass=
ign that object of the same type to the original object, as you describe, t=
hen the +=3D should do the same thing (albeit potentially more efficient). =
Perhaps you can provide an example of where this would produce an unexpecte=
d problem, but as far as I can see it makes absolute sense for peculiar beh=
aviour of + and =3D to be assumed to carry through to +=3D.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div><div class=3D"gmail_quote"><bloc=
kquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div><div>It might be OK for a user to request generat=
ion of such functions explicitly, but it should not be something the standa=
rd imposes on types.<br></div></div></div></blockquote></div></div></div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">If it is not valid, we do exact=
ly what we always do when we don't want a compiler to generate extra me=
thods. Delete them.</div></div></blockquote><div><br></div><div>But we'=
re talking about methods that were not generated before. The usual way to a=
llow a type to have `+` but not `+=3D` was to not declare a `+=3D` at all. =
You're now changing the meaning of their code.</div><div><br></div><div=
>That's bad.</div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"auto"><div dir=3D"auto">But as current code without this chan=
ge is only modified in the absense of these methods, and thus these methods=
are not used in working code, nothing is broken by neglecting to delete th=
ese methods.</div></div>
</blockquote></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ae0ff397-3d89-417d-82d3-ec56c818e1d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ae0ff397-3d89-417d-82d3-ec56c818e1d3=
%40isocpp.org</a>.<br />
------=_Part_2976_1484902990.1513786997060--
------=_Part_2975_966240425.1513786997060--
.
Author: slimercraft3@gmail.com
Date: Wed, 20 Dec 2017 08:24:09 -0800 (PST)
Raw View
------=_Part_2954_1278346517.1513787049527
Content-Type: multipart/alternative;
boundary="----=_Part_2955_1148823042.1513787049527"
------=_Part_2955_1148823042.1513787049527
Content-Type: text/plain; charset="UTF-8"
That is why it returns auto so what ever type is return from the + is
carried forward to the return of +=.
On Wednesday, December 20, 2017 at 11:09:20 AM UTC-5, Jake Arkinstall wrote:
>
> On 20 Dec 2017 15:55, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
>
> I disagree with this. We should not assume that a type for which `+` is
> valid is also a type for which `+=` would be valid even if it is copyable.
>
>
> Is that not the essential definition of += in the first place? Bear in
> mind I am talking about:
>
> T& operator+(const T&) const;
> T& operator+(const S&) const;
>
> Not an operator that returns a different type. If you can add something to
> an object and return an object of the same type, and you can assign that
> object of the same type to the original object, as you describe, then the
> += should do the same thing (albeit potentially more efficient). Perhaps
> you can provide an example of where this would produce an unexpected
> problem, but as far as I can see it makes absolute sense for peculiar
> behaviour of + and = to be assumed to carry through to +=.
>
> It might be OK for a user to request generation of such functions
> explicitly, but it should not be something the standard imposes on types.
>
>
> If it is not valid, we do exactly what we always do when we don't want a
> compiler to generate extra methods. Delete them. But as current code
> without this change is only modified in the absense of these methods, and
> thus these methods are not used in working code, nothing is broken by
> neglecting to delete these methods.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/135bdc43-220c-4e3e-bf85-cd7ac456969f%40isocpp.org.
------=_Part_2955_1148823042.1513787049527
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">That is why it returns auto so what ever type is return fr=
om the + is carried forward to the return of +=3D.<br><br>On Wednesday, Dec=
ember 20, 2017 at 11:09:20 AM UTC-5, Jake Arkinstall wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"auto"><div><div><div class=3D"gmai=
l_quote">On 20 Dec 2017 15:55, "Nicol Bolas" <<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"lcVi72HjBQAJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;">jmck...@gmail.com</a>=
> wrote:<br type=3D"attribution"><blockquote style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>I d=
isagree with this. We should not assume that a type for which `+` is valid =
is also a type for which `+=3D` would be valid even if it is copyable.</div=
></div></div></blockquote></div></div></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Is that not the essential definition of +=3D in the first pl=
ace? Bear in mind I am talking about:</div><div dir=3D"auto"><br></div><div=
dir=3D"auto">T& operator+(const T&) const;</div><div dir=3D"auto">=
T& operator+(const S&) const;</div><div dir=3D"auto"><br></div><div=
dir=3D"auto">Not an operator that returns a different type. If you can add=
something to an object and return an object of the same type, and you can =
assign that object of the same type to the original object, as you describe=
, then the +=3D should do the same thing (albeit potentially more efficient=
). Perhaps you can provide an example of where this would produce an unexpe=
cted problem, but as far as I can see it makes absolute sense for peculiar =
behaviour of + and =3D to be assumed to carry through to +=3D.</div><div di=
r=3D"auto"><br></div><div dir=3D"auto"><div><div class=3D"gmail_quote"><blo=
ckquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div><div>It might be OK for a user to request genera=
tion of such functions explicitly, but it should not be something the stand=
ard imposes on types.<br></div></div></div></blockquote></div></div></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">If it is not valid, we do exac=
tly what we always do when we don't want a compiler to generate extra m=
ethods. Delete them. But as current code without this change is only modifi=
ed in the absense of these methods, and thus these methods are not used in =
working code, nothing is broken by neglecting to delete these methods.</div=
></div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/135bdc43-220c-4e3e-bf85-cd7ac456969f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/135bdc43-220c-4e3e-bf85-cd7ac456969f=
%40isocpp.org</a>.<br />
------=_Part_2955_1148823042.1513787049527--
------=_Part_2954_1278346517.1513787049527--
.