Topic: Allow specialization of std::optional for
Author: David Stone <deusexsophismata@gmail.com>
Date: Tue, 1 Oct 2013 20:47:02 -0700 (PDT)
Raw View
------=_Part_4850_23728334.1380685622756
Content-Type: text/plain; charset=ISO-8859-1
By default, std::optional<T> has space overhead of sizeof(bool) compared
with just T. However, there are many types that don't use all of their
storage space. It would be beneficial if it were allowed to specialize
std::optional for user-defined types to take advantage of this fact and not
waste space.
My use case for this is an integer-like class that represents a value
within a range. For instance, you could have an integer that lies somewhere
in the range [0, 10]. Many of my applications are sensitive to even a
single byte of overhead so I would simply be unable to use a
non-specialized std::optional due to the extra bool. I would have to write
a separate class to add this functionality without the overheard, but that
would make the use confusing and easy to get wrong. However, a
specialization for std::optional would be trivial for an integer that has a
range smaller than its underlying type. We could simply store the value 11
in my example. This should provide no space or time overhead over a
non-optional value. It also would not require changing the interface at
all. Other than testing the size of std::optional, there would be no way
for the user to distinguish a specialized vs. non-specialized std::optional.
This is pretty much a direct copy of my question at
http://stackoverflow.com/questions/19081133/specializing-stdoptional#comment28277563_19081133
--
---
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_4850_23728334.1380685622756
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">By default, std::optional<T> has space overhead of s=
izeof(bool) compared with just T. However, there are many types that don't =
use all of their storage space. It would be beneficial if it were allowed t=
o specialize std::optional for user-defined types to take advantage of this=
fact and not waste space.<br><br>My use case for this is an integer-like c=
lass that represents a value within a range. For instance, you could have a=
n integer that lies somewhere in the range [0, 10]. Many of my applications=
are sensitive to even a single byte of overhead so I would simply be unabl=
e to use a non-specialized std::optional due to the extra bool. I would hav=
e to write a separate class to add this functionality without the overheard=
, but that would make the use confusing and easy to get wrong. However, a s=
pecialization for std::optional would be trivial for an integer that has a =
range smaller than its underlying type. We could simply store the value 11 =
in my example. This should provide no space or time overhead over a non-opt=
ional value. It also would not require changing the interface at all. Other=
than testing the size of std::optional, there would be no way for the user=
to distinguish a specialized vs. non-specialized std::optional.<br><br>Thi=
s is pretty much a direct copy of my question at http://stackoverflow.com/q=
uestions/19081133/specializing-stdoptional#comment28277563_19081133<br></di=
v>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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_4850_23728334.1380685622756--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Tue, 1 Oct 2013 21:40:44 -0700
Raw View
--047d7bd756e27cd2d204e7baae6c
Content-Type: text/plain; charset=ISO-8859-1
If that's the case, there's no need to specialize optional; just use your
type directly and provide the optional semantics. Optional is designed to
mimic a pointer's interface without requiring dynamic memory allocation for
the most part.
If you have some kind of null value, it will be far clearer to client code
to just use that value than to specialize optional.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Tue, Oct 1, 2013 at 8:47 PM, David Stone <deusexsophismata@gmail.com>wrote:
> By default, std::optional<T> has space overhead of sizeof(bool) compared
> with just T. However, there are many types that don't use all of their
> storage space. It would be beneficial if it were allowed to specialize
> std::optional for user-defined types to take advantage of this fact and not
> waste space.
>
> My use case for this is an integer-like class that represents a value
> within a range. For instance, you could have an integer that lies somewhere
> in the range [0, 10]. Many of my applications are sensitive to even a
> single byte of overhead so I would simply be unable to use a
> non-specialized std::optional due to the extra bool. I would have to write
> a separate class to add this functionality without the overheard, but that
> would make the use confusing and easy to get wrong. However, a
> specialization for std::optional would be trivial for an integer that has a
> range smaller than its underlying type. We could simply store the value 11
> in my example. This should provide no space or time overhead over a
> non-optional value. It also would not require changing the interface at
> all. Other than testing the size of std::optional, there would be no way
> for the user to distinguish a specialized vs. non-specialized std::optional.
>
> This is pretty much a direct copy of my question at
> http://stackoverflow.com/questions/19081133/specializing-stdoptional#comment28277563_19081133
>
> --
>
> ---
> 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/.
--047d7bd756e27cd2d204e7baae6c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>If that's the case, there's no need to specia=
lize optional; just use your type directly and provide the optional semanti=
cs. Optional is designed to mimic a pointer's interface without requiri=
ng dynamic memory allocation for the most part.</div>
<div>=A0</div><div>If you have some kind of null value, it will be far clea=
rer to client code to just use that value than to specialize optional.</div=
></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><=
div>
Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" ta=
rget=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"htt=
p://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://sta=
ckoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Oct 1, 2013 at 8:47 PM, David St=
one <span dir=3D"ltr"><<a href=3D"mailto:deusexsophismata@gmail.com" tar=
get=3D"_blank">deusexsophismata@gmail.com</a>></span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<div dir=3D"ltr">By default, std::optional<T> has space overhead of s=
izeof(bool) compared with just T. However, there are many types that don=
9;t use all of their storage space. It would be beneficial if it were allow=
ed to specialize std::optional for user-defined types to take advantage of =
this fact and not waste space.<br>
<br>My use case for this is an integer-like class that represents a value w=
ithin a range. For instance, you could have an integer that lies somewhere =
in the range [0, 10]. Many of my applications are sensitive to even a singl=
e byte of overhead so I would simply be unable to use a non-specialized std=
::optional due to the extra bool. I would have to write a separate class to=
add this functionality without the overheard, but that would make the use =
confusing and easy to get wrong. However, a specialization for std::optiona=
l would be trivial for an integer that has a range smaller than its underly=
ing type. We could simply store the value 11 in my example. This should pro=
vide no space or time overhead over a non-optional value. It also would not=
require changing the interface at all. Other than testing the size of std:=
:optional, there would be no way for the user to distinguish a specialized =
vs. non-specialized std::optional.<br>
<br>This is pretty much a direct copy of my question at <a href=3D"http://s=
tackoverflow.com/questions/19081133/specializing-stdoptional#comment2827756=
3_19081133" target=3D"_blank">http://stackoverflow.com/questions/19081133/s=
pecializing-stdoptional#comment28277563_19081133</a><span class=3D"HOEnZb">=
<font color=3D"#888888"><br>
</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=A0<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%2Bunsubscribe@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>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bd756e27cd2d204e7baae6c--
.
Author: MJanes <max.jns@gmail.com>
Date: Wed, 2 Oct 2013 00:12:21 -0700 (PDT)
Raw View
------=_Part_3217_18594.1380697942318
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Il giorno mercoled=EC 2 ottobre 2013 06:40:44 UTC+2, Billy O'Neal ha scritt=
o:
> If you have some kind of null value, it will be far clearer to client cod=
e=20
> to just use that value than to specialize optional.
>
maybe, the OP made a bad example ( I agree that if a return type has a=20
null-value one should use that instead so avoiding the confusion of=20
discerning between an "empty" optional and an optional "null" ), but if=20
the type to be "optionalized" has invariants guaranteeing that you can=20
never get its "null binary value", then the proposed optimization seems=20
reasonable to me ...
as a user, I find optional ( boost::optional, more specififcally ) very=20
useful, especially for self-documenting code ...=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_3217_18594.1380697942318
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno mercoled=EC 2 ottobre 2013 06:40:44 UTC+2, Billy=
O'Neal ha scritto:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div>If you have some kind of null value, it will be far clearer =
to client code to just use that value than to specialize optional.</div></d=
iv></blockquote><div><br>maybe, the OP made a bad example ( I agree that if=
a return type has a null-value one should use that instead so avoiding the=
confusion of discerning between an "empty" optional and an optional "null"=
), but if the type to be "optionalized" has invariants guaranteeing =
that you can never get its "null binary value", then the proposed optimizat=
ion seems reasonable to me ...<br>as a user, I find optional ( boost::optio=
nal, more specififcally ) very useful, especially for self-documenting code=
... <br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3217_18594.1380697942318--
.
Author: Jean-Marc Bourguet <jm@bourguet.org>
Date: Wed, 02 Oct 2013 09:30:53 +0200
Raw View
On Wed, 2 Oct 2013 00:12:21 -0700 (PDT), MJanes <max.jns@gmail.com>
wrote:
> Il giorno mercoled=EC 2 ottobre 2013 06:40:44 UTC+2, Billy O'Neal ha
> scritto:
>=20
> If you have some kind of null value, it will be far clearer to client
> code to just use that value than to specialize optional.
>=20
> maybe, the OP made a bad example ( I agree that if a return type has
> a null-value one should use that instead so avoiding the confusion of
> discerning between an "empty" optional and an optional "null" ), but
> if the type to be "optionalized" has invariants guaranteeing that you
> can never get its "null binary value", then the proposed optimization
> seems reasonable to me ...
> as a user, I find optional ( boost::optional, more specififcally )
> very useful, especially for self-documenting code ...=20
The request seems allowed by clause 17.6.4.2.1/1 of C++11.
A program may add a template specialization for any standard
library template to namespace std only if the declaration depends
on a user-defined type and the specialization meets the standard
library requirements for the original template and is not
explicitly prohibited.
Has it been removed?
Yours,
--=20
Jean-Marc
--=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/.
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Wed, 2 Oct 2013 00:43:14 -0700 (PDT)
Raw View
------=_Part_3133_18348673.1380699794969
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu =B6roda, 2 pa=BCdziernika 2013 05:47:02 UTC+2 u=BFytkownik David Sto=
ne=20
napisa=B3:
>
> By default, std::optional<T> has space overhead of sizeof(bool) compared=
=20
> with just T. However, there are many types that don't use all of their=20
> storage space. It would be beneficial if it were allowed to specialize=20
> std::optional for user-defined types to take advantage of this fact and n=
ot=20
> waste space.
>
> My use case for this is an integer-like class that represents a value=20
> within a range. For instance, you could have an integer that lies somewhe=
re=20
> in the range [0, 10]. Many of my applications are sensitive to even a=20
> single byte of overhead so I would simply be unable to use a=20
> non-specialized std::optional due to the extra bool. I would have to writ=
e=20
> a separate class to add this functionality without the overheard, but tha=
t=20
> would make the use confusing and easy to get wrong. However, a=20
> specialization for std::optional would be trivial for an integer that has=
a=20
> range smaller than its underlying type. We could simply store the value 1=
1=20
> in my example. This should provide no space or time overhead over a=20
> non-optional value. It also would not require changing the interface at=
=20
> all. Other than testing the size of std::optional, there would be no way=
=20
> for the user to distinguish a specialized vs. non-specialized std::option=
al.
>
Perhaps what you need is not to specialize template std::optional, but=20
another standardized "optional_trait" where you would only specify how you=
=20
want to store the "engaged/disengaged" flag. std::optional would use that=
=20
trait, but would generate the interface for you. this would save you the=20
trouble of writing all the member functions of optional.=20
Regards,
&rzej
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_3133_18348673.1380699794969
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>W dniu =B6roda, 2 pa=BCdziernika 2013 05:47:02 UTC+2 u=
=BFytkownik David Stone napisa=B3:<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">By default, std::optional<T> has space overhea=
d of sizeof(bool) compared with just T. However, there are many types that =
don't use all of their storage space. It would be beneficial if it were all=
owed to specialize std::optional for user-defined types to take advantage o=
f this fact and not waste space.<br><br>My use case for this is an integer-=
like class that represents a value within a range. For instance, you could =
have an integer that lies somewhere in the range [0, 10]. Many of my applic=
ations are sensitive to even a single byte of overhead so I would simply be=
unable to use a non-specialized std::optional due to the extra bool. I wou=
ld have to write a separate class to add this functionality without the ove=
rheard, but that would make the use confusing and easy to get wrong. Howeve=
r, a specialization for std::optional would be trivial for an integer that =
has a range smaller than its underlying type. We could simply store the val=
ue 11 in my example. This should provide no space or time overhead over a n=
on-optional value. It also would not require changing the interface at all.=
Other than testing the size of std::optional, there would be no way for th=
e user to distinguish a specialized vs. non-specialized std::optional.<br><=
/div></blockquote><div><br>Perhaps what you need is not to specialize templ=
ate std::optional, but another standardized "optional_trait" where you woul=
d only specify how you want to store the "engaged/disengaged" flag. std::op=
tional would use that trait, but would generate the interface for you. this=
would save you the trouble of writing all the member functions of optional=
.. <br><br>Regards,<br>&rzej<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3133_18348673.1380699794969--
.
Author: Christopher Jefferson <chris@bubblescope.net>
Date: Wed, 2 Oct 2013 09:08:24 +0100
Raw View
On 2 October 2013 04:47, David Stone <deusexsophismata@gmail.com> wrote:
> By default, std::optional<T> has space overhead of sizeof(bool) compared
> with just T. However, there are many types that don't use all of their
> storage space. It would be beneficial if it were allowed to specialize
> std::optional for user-defined types to take advantage of this fact and not
> waste space.
>
> My use case for this is an integer-like class that represents a value within
> a range. For instance, you could have an integer that lies somewhere in the
> range [0, 10]. Many of my applications are sensitive to even a single byte
> of overhead so I would simply be unable to use a non-specialized
> std::optional due to the extra bool. I would have to write a separate class
> to add this functionality without the overheard, but that would make the use
> confusing and easy to get wrong. However, a specialization for std::optional
> would be trivial for an integer that has a range smaller than its underlying
> type. We could simply store the value 11 in my example. This should provide
> no space or time overhead over a non-optional value. It also would not
> require changing the interface at all. Other than testing the size of
> std::optional, there would be no way for the user to distinguish a
> specialized vs. non-specialized std::optional.
Just to point out, a similar optimisation is available (in my
experience) for most non-trivial types. For example on any modern unix
you have never going to end up with a pointer pointing to (void*)1, so
any class which contains a pointer can use the memory location of that
pointer = (void*)1 to denote that the optional is disengaged.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Wed, 02 Oct 2013 11:26:56 +0200
Raw View
On 10/02/2013 05:47 AM, David Stone wrote:
> but that would make the use confusing and easy to get wrong. However, a
> specialization for std::optional would be trivial for an integer that
> has a range smaller than its underlying type. We could simply store the
> value 11 in my example. This should provide no space or time overhead
There were some discussion about this in the thread "std::degenerate<>
class template"
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/vBtZKyj-dtg
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Stone <deusexsophismata@gmail.com>
Date: Wed, 2 Oct 2013 06:38:47 -0700 (PDT)
Raw View
------=_Part_149_14584882.1380721127257
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, October 1, 2013 10:40:44 PM UTC-6, Billy O'Neal wrote:
>
> If that's the case, there's no need to specialize optional; just use your
> type directly and provide the optional semantics. Optional is designed to
> mimic a pointer's interface without requiring dynamic memory allocation for
> the most part.
>
> If you have some kind of null value, it will be far clearer to client code
> to just use that value than to specialize optional.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
If I did this, the user would always have to check my class for whether it
is currently engaged. How I am thinking about it, the only way to set this
value would be through the std::optional interface. This would mean that
the users of my class that don't use std::optional wouldn't know that such
an optimization exists for std::optional, and the users of my class through
std::optional would just benefit from reduced size without the interface
otherwise changing at all.
However, as Jean-Marc Bourguet says, 17.6.4.2.1/1 seems to already allow
this, so it looks like this is unnecessary.
Andrzej, I agree that it would be a bit more convenient for me to have some
sort of optional_trait, but it is absolutely not necessary.
--
---
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_149_14584882.1380721127257
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 1, 2013 10:40:44 PM UTC-6, Billy O'Nea=
l 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"><div>=
If
that's the case, there's no need to specialize optional; just use your=20
type directly and provide the optional semantics. Optional is designed=20
to mimic a pointer's interface without requiring dynamic memory=20
allocation for the most part.</div>
<div> </div><div>If you have some kind of null value, it will be far c=
learer to client code to just use that value than to specialize optional.</=
div></div><div><br clear=3D"all"><div><div dir=3D"ltr"><div>
Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" target=
=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http://=
stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stackov=
erflow.com/<wbr>users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br></div></blockquote><div><br>If I did this, the user would always=20
have to check my class for whether it is currently engaged. How I am=20
thinking about it, the only way to set this value would be through th=
e=20
std::optional interface. This would mean that the users of my class that
don't use std::optional wouldn't know that such an optimization exists=20
for std::optional, and the users of my class through std::optional would
just benefit from reduced size without the interface otherwise changing
at all.<br><br><br>However, as Jean-Marc Bourguet says, 17.6.4.2.1/1 seems=
to already allow this, so it looks like this is unnecessary.<br><br>Andrze=
j, I agree that it would be a bit more convenient for me to have some sort =
of optional_trait, but it is absolutely not necessary.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_149_14584882.1380721127257--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 2 Oct 2013 09:17:05 -0500
Raw View
--001a11c2c8eab7bf1904e7c2bbbb
Content-Type: text/plain; charset=ISO-8859-1
On 1 October 2013 23:40, Billy O'Neal <billy.oneal@gmail.com> wrote:
> If that's the case, there's no need to specialize optional; just use your
> type directly and provide the optional semantics.
+1.
--
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/.
--001a11c2c8eab7bf1904e7c2bbbb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 1 October 2013 23:40, Billy O'Neal <span dir=3D"ltr"><<a href=3D"=
mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">If that's the case, there's no need =
to specialize optional; just use your type directly and provide the optiona=
l semantics.</blockquote>
</div><br>+1.</div><div class=3D"gmail_extra">-- <br>=A0Nevin ":-)&quo=
t; Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"=
_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2c8eab7bf1904e7c2bbbb--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 02 Oct 2013 09:04:55 -0700
Raw View
On quarta-feira, 2 de outubro de 2013 09:08:24, Christopher Jefferson wrote:
> Just to point out, a similar optimisation is available (in my
> experience) for most non-trivial types. For example on any modern unix
> you have never going to end up with a pointer pointing to (void*)1, so
> any class which contains a pointer can use the memory location of that
> pointer = (void*)1 to denote that the optional is disengaged.
And any polymorphic class has at least one pointer, the pointer to the vtable.
The only problem is that it's inaccessible without completely unspecified
pointer aerobics. But since std::optional comes with the compiler, the
compiler team could properly make use of the member.
Of course, that assumes that the user is using the engaged member in the
specified fashion, not just as storage for something else.
--
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
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 2 Oct 2013 11:47:12 -0700
Raw View
--20cf300e529dbc4b8f04e7c681bd
Content-Type: text/plain; charset=ISO-8859-1
Perhaps, but you also could cause the user to have to check two things.
Consider something like:
optional<MyNullableType> x;
if (x) {
// Well, MyNullableType is nullable too, so I have to check it:
if (*x) {
// Stuff
}
}
I suspect this would cause confusion.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Wed, Oct 2, 2013 at 6:38 AM, David Stone <deusexsophismata@gmail.com>wrote:
> On Tuesday, October 1, 2013 10:40:44 PM UTC-6, Billy O'Neal wrote:
>
>> If that's the case, there's no need to specialize optional; just use your
>> type directly and provide the optional semantics. Optional is designed to
>> mimic a pointer's interface without requiring dynamic memory allocation for
>> the most part.
>>
>> If you have some kind of null value, it will be far clearer to client
>> code to just use that value than to specialize optional.
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/**users/82320/billy-oneal<http://stackoverflow.com/users/82320/billy-oneal>
>> Malware Response Instructor - BleepingComputer.com
>>
>>
> If I did this, the user would always have to check my class for whether it
> is currently engaged. How I am thinking about it, the only way to set this
> value would be through the std::optional interface. This would mean that
> the users of my class that don't use std::optional wouldn't know that such
> an optimization exists for std::optional, and the users of my class through
> std::optional would just benefit from reduced size without the interface
> otherwise changing at all.
>
>
> However, as Jean-Marc Bourguet says, 17.6.4.2.1/1 seems to already allow
> this, so it looks like this is unnecessary.
>
> Andrzej, I agree that it would be a bit more convenient for me to have
> some sort of optional_trait, but it is absolutely not necessary.
>
> --
>
> ---
> 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/.
--20cf300e529dbc4b8f04e7c681bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Perhaps, but you also could cause the user to have to=
check two things. Consider something like:</div><div>=A0</div><div>optiona=
l<MyNullableType> x;</div><div>=A0</div><div>if (x) {</div><div>=A0=
=A0=A0 // Well, MyNullableType is nullable too, so I have to check it:</div=
>
<div>=A0=A0=A0 if (*x) {</div><div>=A0=A0=A0=A0=A0=A0=A0 // Stuff</div><div=
>=A0=A0=A0 }</div><div>}</div><div>=A0</div><div>I suspect this would cause=
confusion.</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><d=
iv dir=3D"ltr"><div>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/=
users/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/8=
2320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Oct 2, 2013 at 6:38 AM, David St=
one <span dir=3D"ltr"><<a href=3D"mailto:deusexsophismata@gmail.com" tar=
get=3D"_blank">deusexsophismata@gmail.com</a>></span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On Tuesday, October 1, 2013 10:40:44 PM =
UTC-6, Billy O'Neal wrote:</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div class=3D"im"><div>If
that's the case, there's no need to specialize optional; just use =
your=20
type directly and provide the optional semantics. Optional is designed=20
to mimic a pointer's interface without requiring dynamic memory=20
allocation for the most part.</div>
<div>=A0</div></div><div class=3D"im"><div>If you have some kind of null va=
lue, it will be far clearer to client code to just use that value than to s=
pecialize optional.</div></div></div><div><br clear=3D"all"><div class=3D"i=
m">
<div><div dir=3D"ltr"><div>
Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" ta=
rget=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"htt=
p://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://sta=
ckoverflow.com/<u></u>users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br></div></div></blockquote><div><br>If I did this, the user would always=
=20
have to check my class for whether it is currently engaged. How I am=20
thinking about it,=A0 the only way to set this value would be through the=
=20
std::optional interface. This would mean that the users of my class that
don't use std::optional wouldn't know that such an optimization ex=
ists=20
for std::optional, and the users of my class through std::optional would
just benefit from reduced size without the interface otherwise changing
at all.<br><br><br>However, as Jean-Marc Bourguet says, 17.6.4.2.1/1 seems=
to already allow this, so it looks like this is unnecessary.<br><br>Andrze=
j, I agree that it would be a bit more convenient for me to have some sort =
of optional_trait, but it is absolutely not necessary.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<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%2Bunsubscribe@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>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf300e529dbc4b8f04e7c681bd--
.
Author: David Stone <deusexsophismata@gmail.com>
Date: Wed, 2 Oct 2013 16:50:53 -0700 (PDT)
Raw View
------=_Part_5740_12160247.1380757853278
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, October 2, 2013 12:47:12 PM UTC-6, Billy O'Neal wrote:
>
> Perhaps, but you also could cause the user to have to check two things.
> Consider something like:
>
> optional<MyNullableType> x;
>
> if (x) {
> // Well, MyNullableType is nullable too, so I have to check it:
> if (*x) {
> // Stuff
> }
> }
>
> I suspect this would cause confusion.
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
I feel like maybe we are misunderstanding each other then. My argument is
that my type is not nullable. The user never has to check if the value
exists when they use it because it does not have a null state. However,
when used with optional, it could secretly take advantage of the
representation of the object in a way that no other class is allowed to do.
Perhaps code would explain this better than word, so here is a rough
outline of what I am talking about:
class non_zero_integer {
public:
constexpr non_zero_integer(int value):
x(value) {
if (x == 0) {
throw std::runtime_error("Cannot be zero");
}
}
// arithmetic operator overloads
private:
friend class optional<non_zero_integer>;
constexpr non_zero_integer() noexcept:
x(0) {
}
int x;
};
template<>
class optional<non_zero_integer> {
public:
// Default constructs into the disengaged state
constexpr optional() = default;
constexpr non_zero_integer & value() const {
return (value != 0) ? value : throw
std::bad_optional_access("Attempted to access uninitialized optional");
}
// Other stuff
private:
non_zero_integer value;
};
Note how the user of either class is completely unaware of this
optimization unless they specifically check the size of
optional<non_zero_integer>.
--
---
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_5740_12160247.1380757853278
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 2, 2013 12:47:12 PM UTC-6, Billy O'N=
eal 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"><di=
v>Perhaps, but you also could cause the user to have to check two things. C=
onsider something like:</div><div> </div><div>optional<MyNullableTy=
pe> x;</div><div> </div><div>if (x) {</div><div> =
// Well, MyNullableType is nullable too, so I have to check it:</div>
<div> if (*x) {</div><div> &=
nbsp; // Stuff</div><div> }</div><div>}</div><div>&=
nbsp;</div><div>I suspect this would cause confusion.</div></div><div><br c=
lear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/=
users/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/<wbr>us=
ers/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br></div></blockquote><div><br><br>I feel like maybe we are misunderstandi=
ng each other then. My argument is that my type is not nullable. The user n=
ever has to check if the value exists when they use it because it does not =
have a null state. However, when used with optional, it could secretl=
y take advantage of the representation of the object in a way that no other=
class is allowed to do. Perhaps code would explain this better than word, =
so here is a rough outline of what I am talking about:<br><br>class non_zer=
o_integer {<br>public:<br> constexpr non_zero_integer(int=
value):<br> x(value) {<br>  =
; if (x =3D=3D 0) {<br> &n=
bsp; throw std::runtime_error("Cannot be zero");<b=
r> }<br> }<br> =
// arithmetic operator overloads<br>private:<br> &n=
bsp; friend class optional<non_zero_integer>;<br> c=
onstexpr non_zero_integer() noexcept:<br> &nb=
sp; x(0) {<br> }<br> int x;<br>};<br><b=
r>template<><br>class optional<non_zero_integer> {<br>public:<b=
r> // Default constructs into the disengaged state<br>&nb=
sp; constexpr optional() =3D default;<br> con=
stexpr non_zero_integer & value() const {<br> &=
nbsp; return (value !=3D 0) ? value : throw std::bad_optional_access(=
"Attempted to access uninitialized optional");<br> }<br>&=
nbsp; // Other stuff<br>private:<br> non_zero=
_integer value;<br>};<br><br><br><br>Note how the user of either class is c=
ompletely unaware of this optimization unless they specifically check the s=
ize of optional<non_zero_integer>.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5740_12160247.1380757853278--
.
Author: Maurice Bos <m-ou.se@m-ou.se>
Date: Thu, 3 Oct 2013 11:07:34 +0200
Raw View
--e89a8f3bae5d6c853d04e7d285b0
Content-Type: text/plain; charset=ISO-8859-1
Another good example might be a variant type (boost::variant, maybe
std::variant in the future). A variant<string, float> always contains
either a string or a float. Apart from some union{string;float;}-like
member, the variant has an integer as member to keep track of whether the
variant contains a string or a float. An optional<variant<string, float>>
might use some friendship between optionals and variants to 'secretly' let
the variant handle the 'optionallity', which could simply use a third value
in its integer member to represent an empty null state. That way, the
optional would't have to hold more information than just the variant, but
optional<> and variant<> would still behave as expected. (variant<> is
never empty, optional<> adds this 'empty' state)
2013/10/3 David Stone <deusexsophismata@gmail.com>
> On Wednesday, October 2, 2013 12:47:12 PM UTC-6, Billy O'Neal wrote:
>>
>> Perhaps, but you also could cause the user to have to check two things.
>> Consider something like:
>>
>> optional<MyNullableType> x;
>>
>> if (x) {
>> // Well, MyNullableType is nullable too, so I have to check it:
>> if (*x) {
>> // Stuff
>> }
>> }
>>
>> I suspect this would cause confusion.
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/**users/82320/billy-oneal<http://stackoverflow.com/users/82320/billy-oneal>
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>
> I feel like maybe we are misunderstanding each other then. My argument is
> that my type is not nullable. The user never has to check if the value
> exists when they use it because it does not have a null state. However,
> when used with optional, it could secretly take advantage of the
> representation of the object in a way that no other class is allowed to do.
> Perhaps code would explain this better than word, so here is a rough
> outline of what I am talking about:
>
> class non_zero_integer {
> public:
> constexpr non_zero_integer(int value):
> x(value) {
> if (x == 0) {
> throw std::runtime_error("Cannot be zero");
> }
> }
> // arithmetic operator overloads
> private:
> friend class optional<non_zero_integer>;
> constexpr non_zero_integer() noexcept:
> x(0) {
> }
> int x;
> };
>
> template<>
> class optional<non_zero_integer> {
> public:
> // Default constructs into the disengaged state
> constexpr optional() = default;
> constexpr non_zero_integer & value() const {
> return (value != 0) ? value : throw
> std::bad_optional_access("Attempted to access uninitialized optional");
> }
> // Other stuff
> private:
> non_zero_integer value;
> };
>
>
>
> Note how the user of either class is completely unaware of this
> optimization unless they specifically check the size of
> optional<non_zero_integer>.
>
> --
>
> ---
> 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/.
--e89a8f3bae5d6c853d04e7d285b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Another good example might be a variant type (boost::varia=
nt, maybe std::variant in the future). A variant<string, float> alway=
s contains either a string or a float. Apart from some union{string;float;}=
-like member, the variant has an integer as member to keep track of whether=
the variant contains a string or a float. An optional<variant<string=
, float>> might use some friendship between optionals and variants to=
'secretly' let the variant handle the 'optionallity', whic=
h could simply use a third value in its integer member to represent an empt=
y null state. That way, the optional would't have to hold more informat=
ion than just the variant, but optional<> and variant<> would s=
till behave as expected. (variant<> is never empty, optional<> =
adds this 'empty' state)<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/10=
/3 David Stone <span dir=3D"ltr"><<a href=3D"mailto:deusexsophismata@gma=
il.com" target=3D"_blank">deusexsophismata@gmail.com</a>></span><br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On Wednesday, October 2, 2013 12:47:12 P=
M UTC-6, Billy O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">
<div>Perhaps, but you also could cause the user to have to check two things=
.. Consider something like:</div><div>=A0</div><div>optional<MyNullableTy=
pe> x;</div><div>=A0</div><div>if (x) {</div><div>=A0=A0=A0 // Well, MyN=
ullableType is nullable too, so I have to check it:</div>
<div>=A0=A0=A0 if (*x) {</div><div>=A0=A0=A0=A0=A0=A0=A0 // Stuff</div><div=
>=A0=A0=A0 }</div><div>}</div><div>=A0</div><div>I suspect this would cause=
confusion.</div></div><div><br clear=3D"all"><div><div dir=3D"ltr"><div>Bi=
lly O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/=
users/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/<u></u>=
users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br></div></blockquote></div><div><br><br>I feel like maybe we are misunder=
standing each other then. My argument is that my type is not nullable. The =
user never has to check if the value exists when they use it because it doe=
s not have a null state. However, when used with optional,=A0 it could secr=
etly take advantage of the representation of the object in a way that no ot=
her class is allowed to do. Perhaps code would explain this better than wor=
d, so here is a rough outline of what I am talking about:<br>
<br>class non_zero_integer {<br>public:<br>=A0=A0=A0 constexpr non_zero_int=
eger(int value):<br>=A0=A0=A0 =A0=A0=A0 x(value) {<br>=A0=A0=A0 =A0=A0=A0 i=
f (x =3D=3D 0) {<br>=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 throw std::runtime_error(=
"Cannot be zero");<br>=A0=A0=A0 =A0=A0=A0 }<br>=A0=A0=A0 }<br>
=A0=A0=A0 // arithmetic operator overloads<br>private:<br>=A0=A0=A0 friend =
class optional<non_zero_integer>;<br>=A0=A0=A0 constexpr non_zero_int=
eger() noexcept:<br>=A0=A0=A0 =A0=A0=A0 x(0) {<br>=A0=A0=A0 }<br>=A0=A0=A0 =
int x;<br>};<br><br>template<><br>
class optional<non_zero_integer> {<br>public:<br>=A0=A0=A0 // Default=
constructs into the disengaged state<br>=A0=A0=A0 constexpr optional() =3D=
default;<br>=A0=A0=A0 constexpr non_zero_integer & value() const {<br>=
=A0=A0=A0 =A0=A0=A0 return (value !=3D 0) ? value : throw std::bad_optional=
_access("Attempted to access uninitialized optional");<br>
=A0=A0=A0 }<br>=A0=A0=A0 // Other stuff<br>private:<br>=A0=A0=A0 non_zero_i=
nteger value;<br>};<br><br><br><br>Note how the user of either class is com=
pletely unaware of this optimization unless they specifically check the siz=
e of optional<non_zero_integer>.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<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%2Bunsubscribe@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>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--e89a8f3bae5d6c853d04e7d285b0--
.