Topic: std::degenerate<> class template :
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Tue, 03 Sep 2013 14:51:30 +0200
Raw View
On 09/03/2013 02:18 PM, the.ultimate.koala@gmail.com wrote:
> that it should be a "drop-in replacement" for it. degenerate<T,v>
> actually implements an equivalent of std::optional<T - {v}>, in the case
> of when you're not using all the values of a type.
Have you consider an extension where there are several "none" values?
For instance, you may have a simple lexer/tokenizer that returns the
next token from the input. Let us say it recognizes integer,
floating-point numbers, and string. In addition to this, the tokenizer
may return special tokens to indicate errors or end-of-file.
enum class Token { ERROR, EOF, INTEGER, FLOAT, STRING };
So here we have two values that are set apart from the encodable set.
--
---
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: the.ultimate.koala@gmail.com
Date: Tue, 3 Sep 2013 07:28:01 -0700 (PDT)
Raw View
------=_Part_2623_17569552.1378218481207
Content-Type: text/plain; charset=ISO-8859-1
Bjorn,
> Have you consider an extension where there are several "none" values?
>
>
Yes. There are several problems. Let's call V the set of values of a type T
:
Choose a value v1 within V as the "none" value. The type degenerate<T, v1>would be usable as a replacement for a hypothetical optional<T
- {v1}>. Now choose a value v2 within V :
- if it's the same as v1, then degenerate<degenerate<T, v1>, v2> would
degrade to degenerate<T, v1>.
- if it's different of v1, then degenerate<degenerate<T, v1>, v2> would
be usable as a replacement for a hypothetical optional<optional<T -
{v1,v2}>>.
You can see that the count set of values is decrementing at every step.
When you reach the empty set, what should happen? We could leave this to
the programmer.
To answer more precisely, it would suffice to accomodate class type with
value semantics as type T. I think this can be done with functors.
For instance, you may have a simple lexer/tokenizer that returns the
> next token from the input. Let us say it recognizes integer,
> floating-point numbers, and string. In addition to this, the tokenizer
> may return special tokens to indicate errors or end-of-file.
>
> enum class Token { ERROR, EOF, INTEGER, FLOAT, STRING };
>
> So here we have two values that are set apart from the encodable set.
>
>
In what order ? The most logical to me would be :
enum class Token { ERROR, EOF, INTEGER, FLOAT, STRING };
using possibly_erroneous_result_t = degenerate<Token, Token::ERROR>;
using result_t = degenerate<possibly_erroneous_result_t, constexpr []() ->possibly_erroneous_result_t
{ return possibly_erroneous_result_t{ Token::EOF }; }>;
I did not yet try to write the variant accomodating classes with functors.
--
---
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_2623_17569552.1378218481207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Bjorn,<br><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hav=
e you consider an extension where there are several "none" values?
<br>
<br></blockquote><div><br>Yes. There are several problems. Let's call V the=
set of values of a type T :<br><br>Choose a value v1 within V as the "none=
" value. The type <span style=3D"font-family: courier new,monospace;">degen=
erate<T, v1></span> would be usable as a replacement for a hypothetic=
al <span style=3D"font-family: courier new,monospace;">optional<T - {v1}=
></span>. Now choose a value v2 within V :<br><ul><li>if it's the same a=
s v1, then <span style=3D"font-family: courier new,monospace;">degenerate&l=
t;degenerate<T, v1>, v2></span> would degrade to <span style=3D"fo=
nt-family: courier new,monospace;">degenerate<T, v1><span style=3D"fo=
nt-family: arial,sans-serif;">.</span></span></li><li><span style=3D"font-f=
amily: courier new,monospace;"><span style=3D"font-family: arial,sans-serif=
;">if it's different of v1, then </span></span><span style=3D"font-family: =
courier new,monospace;">degenerate<degenerate<T, v1>, v2><font =
face=3D"arial,sans-serif"> would be usable as a replacement for a hypotheti=
cal </font></span><span style=3D"font-family: courier new,monospace;">optio=
nal<optional<T - {v1,v2}>><span style=3D"font-family: arial,san=
s-serif;">.</span></span></li></ul><p>You can see that the count set of val=
ues is decrementing at every step. When you reach the empty set, what shoul=
d happen? We could leave this to the programmer.<br></p> To answer mor=
e precisely, it would suffice to accomodate class type with value semantics=
as type T. I think this can be done with functors.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;">For instance, you may have =
a simple lexer/tokenizer that returns the
<br>next token from the input. Let us say it recognizes integer,
<br>floating-point numbers, and string. In addition to this, the tokenizer
<br>may return special tokens to indicate errors or end-of-file.
<br>
<br> enum class Token { ERROR, EOF, INTEGER, FLOAT, STRING };
<br>
<br>So here we have two values that are set apart from the encodable set.
<br>
<br></blockquote><div><br>In what order ? The most logical to me would be :=
<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">enum=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Token</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> ERROR</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> EOF</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> INTEGER<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> FLOAT</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> STRING </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">using</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> possibly_erroneous_result_t </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> degenerate</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify"><</span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Token</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">Token</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ERROR</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">>;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> result_t </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> degenerate</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">possibly_erroneous_result_t</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[]()</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">-></span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> possibly_erroneous_result_t </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> possibly_erroneous_result_t</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">Token</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">EOF </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}>;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><b=
r>I did not yet try to write the variant accomodating classes with functors=
..<br><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_2623_17569552.1378218481207--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 04 Sep 2013 08:43:48 +0200
Raw View
This is a multi-part message in MIME format.
--------------030009010302080107040501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 04/09/13 06:48, the.ultimate.koala@gmail.com a =E9crit :
> Nicol Bolas,
>
> Thank you for your latest response, your opinion a lot clearer now.
>
> If I may reword your comments into short constructive suggestions,=20
> that would mean :
>
> * That the class is a worthwhile attempt at building something
> standardizable, not a hack altogether.
>
> Just look at `optional`. All of that.
>
> * That I should more closely keep the "optional" interface.
>
>
> ... yes. That's the point of the space optimized optional type.
> It's exactly like `optional<T>`, only certain values are
> considered "not a real value".
>
>
> I see no reason to give it a special name just because of that
> /minor/ difference between them.
>
> * That the difference in behaviour is acceptable, and should be
> proposed as another base template of optional<> instead of another
> getting another name altogether.
>
>
> Sure you can. It's quite simple:
>
> template<typename T, typename NullValueProvider>
> class optional
> {
> public:
> constexpr optional() : t(NullValueProvider::getNullValue()) {}
> constexpr optional(const T &_t) : t(_t) {}
> constexpr optional(const nullopt_T &) :
> t(NullValueProvider::getNullValue()) {}
>
> explicit operator bool() {return NullValueProvider::isNullValue(t);=
}
>
> constexpr T const* operator->() const
> {
> return &t; //As with the regular optional version, the return
> value is undefined if not engaged.
> }
>
> constexpr const T &value() const
> {
> if(*this) return t;
> throw bad_optional_access; //Throws when not engaged.
> }
>
> private:
> T t;
> };
>
> <snip/>
>
> * That I should implement another base template using functors, to
> accomodate values that are not allowed as non-type tempate arguments.
>
>
What do you think about defining the degenerate class empty
template <typename T, typename DegenerateValue>
struct degenerate
{
typedef T value_type;
typedef DegenerateValue degenerate_value_type;
};
and use it to make specialization of optional
template <typename T, typename DegenerateValue>
struct optional <degenerate<T,DegenerateValue>>
{
// include here the degenerated specialization
}
In this way optional doesn't changes its interface (preserv only one=20
template parameter), and we are able to have
optional<T>
and
optional<degenerate<Player, integral_constant<Player, Player(-1)>>
Best,
Vicente
--=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/.
--------------030009010302080107040501
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 04/09/13 06:48,
<a class="moz-txt-link-abbreviated" href="mailto:the.ultimate.koala@gmail.com">the.ultimate.koala@gmail.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:6da8e8d3-7c26-4841-bc3f-40dd0715e92b@isocpp.org"
type="cite">
<div dir="ltr">Nicol Bolas,<br>
<br>
Thank you for your latest response, your opinion a lot clearer
now.<br>
<br>
If I may reword your comments into short constructive
suggestions, that would mean :<br>
<ul>
<li>That the class is a worthwhile attempt at building
something standardizable, not a hack altogether.<br>
</li>
</ul>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir="ltr">
<div>Just look at `optional`. All of that.<br>
</div>
</div>
</blockquote>
<div>
<ul>
<li>That I should more closely keep the "optional"
interface.<br>
</li>
</ul>
</div>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir="ltr">
<div><br>
... yes. That's the point of the space optimized optional
type. It's exactly like `optional<T>`, only certain
values are considered "not a real value". <br>
</div>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir="ltr">
<div><br>
I see no reason to give it a special name just because of
that <i>minor</i> difference between them.<br>
</div>
</div>
</blockquote>
<div>
<ul>
<li>That the difference in behaviour is acceptable, and
should be proposed as another base template of
optional<> instead of another getting another name
altogether.</li>
</ul>
</div>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir="ltr">
<div><br>
Sure you can. It's quite simple:<br>
<br>
template<typename T, typename NullValueProvider><br>
class optional<br>
{<br>
public:<br>
constexpr optional() : t(NullValueProvider::<wbr>getNullValue())
{}<br>
constexpr optional(const T &_t) : t(_t) {}<br>
constexpr optional(const nullopt_T &) :
t(NullValueProvider::<wbr>getNullValue()) {}<br>
<br>
explicit operator bool() {return NullValueProvider::<wbr>isNullValue(t);}<br>
<br>
constexpr T const* operator->() const<br>
{<br>
return &t; //As with the regular optional version,
the return value is undefined if not engaged.<br>
}<br>
<br>
constexpr const T &value() const<br>
{<br>
if(*this) return t;<br>
throw bad_optional_access; //Throws when not engaged.<br>
}<br>
<br>
private:<br>
T t;<br>
};</div>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div dir="ltr">
<div><snip/><br>
</div>
</div>
</blockquote>
<div>
<ul>
<li>That I should implement another base template using
functors, to accomodate values that are not allowed as
non-type tempate arguments.<br>
</li>
</ul>
</div>
<br>
</div>
</blockquote>
<br>
What do you think about defining the degenerate class empty<br>
<br>
template <typename T, typename DegenerateValue><br>
struct degenerate<br>
{<br>
typedef T value_type;<br>
typedef DegenerateValue degenerate_value_type;<br>
};<br>
<br>
and use it to make specialization of optional<br>
<br>
template <typename T, typename DegenerateValue><br>
struct optional <degenerate<T,DegenerateValue>><br>
{<br>
// include here the degenerated specialization<br>
}<br>
<br>
In this way optional doesn't changes its interface (preserv only one
template parameter), and we are able to have <br>
<br>
optional<T><br>
<br>
and<br>
<br>
optional<degenerate<Player, integral_constant<Player,
Player(-1)>><br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to 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="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------030009010302080107040501--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 4 Sep 2013 02:11:03 -0700 (PDT)
Raw View
------=_Part_12_8486434.1378285863351
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, September 4, 2013 2:43:48 PM UTC+8, Vicente J. Botet Escriba
wrote:
>
> What do you think about defining the degenerate class empty
>
> and use it to make specialization of optional
>
> optional<degenerate<Player, integral_constant<Player, Player(-1)>>
>
Same as my suggestion above :v)
Except that if the order of parameters is reversed, then the type (e.g.
Player) may be retrieved from integral_constant.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_12_8486434.1378285863351
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, September 4, 2013 2:43:48 PM UTC+8, =
Vicente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>
=20
=20
=20
<div>What do you think about defining the degenerate class empty<br>
<br>
and use it to make specialization of optional<br>
<br>
optional<degenerate<Player, integral_constant<Player,
Player(-1)>><br></div></blockquote><div><br>Same as my suggestion=
above :v)<br><br>Except that if the order of parameters is reversed, then =
the type (e.g. <span style=3D"font-family: courier new,monospace;">Player</=
span>) may be retrieved from <span style=3D"font-family: courier new,monosp=
ace;">integral_constant</span>.<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_12_8486434.1378285863351--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 02:35:13 -0700 (PDT)
Raw View
------=_Part_3005_13267621.1378287313681
Content-Type: text/plain; charset=ISO-8859-1
Vicente,
What do you think about defining the degenerate class empty
>
> template <typename T, typename DegenerateValue>
> struct degenerate
> {
> typedef T value_type;
> typedef DegenerateValue degenerate_value_type;
> };
>
>
You're asking me what I think, so let me first sum up how I perceive the
problem now, considering the feedback I got up to now :
- The class template that I first called degenerate<> is indeed targeted
to be a more space-efficient optional<>, and should be a specialisation
thereof.
- Can the compiler (or can the template writer make the compiler)
automatically determine a sensible value that would not conflict with any
other value of the type?
Which would limit to two implementation types for optional<>. The first one
for "dense" types, i.e. whose set of values have the same cardinality as
the set of storable values of their storage, and as such, you need to
extend the storage capacity to accomodate the additional "undefined" value.
This is the current implementation of optional<>. Something like:
struct optional_storage {
bool is_defined;
union value {
dummy_t dummy;
unsigned char[] correctly_aligned_correctly_sized_storage;
}
}
And another one for "sparse" types, i.e. whose set of values has
cardinality strictly less than the cardinality of the set of storable
values of their storage. Example of such types defined in the standard, are
bool and nullptr_t. (having respectively 2 and 1 value, but much wider
storage capacity) Details aside, the storage could be defined as :
union optional_storage {
underlying_type storage;
type value;
}
Definedness would amount to testing the "storage" against the undefined
"value".
Determining denseness or sparseness could be done by
traits/concepts/whatever TMP supports, this is still an open question in my
mind.
That said:
>
> template <typename T, typename DegenerateValue>
> struct optional <degenerate<T,DegenerateValue>>
> {
> // include here the degenerated specialization
> }
>
> In this way optional doesn't changes its interface (preserv only one
> template parameter), and we are able to have
>
> optional<T>
>
> and
>
> optional<degenerate<Player, integral_constant<Player, Player(-1)>>
>
>
I'd say yes, this is a fair idea. You take the word "degenerate" and make
it an adjective to the type Player, with a value representing
disengagedness. This would be the result of a refactoring the templates, I
think.
I think that your degenerate<Player, integral_constant<Player, Player(-1)>(using your definition of
degenerate) would benefit of being a full-fledged type representing Player
- Player(-1) and actually used in the signature of optional<> members.
This object would then build the "sparse" type Player - Player(-1) from the
"dense" type Player. The same space-efficient optimization of optional<>could be used for bool
and all other "sparse" types all the same.
This makes me think that Core C++ would benefit having a way of defining
truly "sparse" enums.
--
---
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_3005_13267621.1378287313681
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Vicente,<br><br><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
What do you think about defining the degenerate class empty<br>
<br>
template <typename T, typename DegenerateValue><br>
struct degenerate<br>
{<br>
typedef T value_type;<br>
typedef DegenerateValue degenerate_value_type;<br>
};<br>
<br></div></blockquote><div><br>You're asking me what I think, so let m=
e first sum up how I perceive the problem now, considering the feedback I g=
ot up to now :<br><ul><li>The class template that I first called degenerate=
<> is indeed targeted to be a more space-efficient optional<>, =
and should be a specialisation thereof.<br></li><li>Can the compiler (or ca=
n the template writer make the compiler) automatically determine a sensible=
value that would not conflict with any other value of the type?<br></li></=
ul>Which would limit to two implementation types for optional<>. The =
first one for "dense" types, i.e. whose set of values have the same cardina=
lity as the set of storable values of their storage, and as such, you need =
to extend the storage capacity to accomodate the additional "undefined" val=
ue. This is the current implementation of optional<>. Something like:=
<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">stru=
ct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> optiona=
l_storage </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">b=
ool</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> is_def=
ined</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">union</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> value </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br> =
dummy_t dummy</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">unsigned</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">char</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">[]</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> correctly_aligned_correctly_sized_storage</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div></code></div><br>And another one for "sparse" typ=
es, i.e. whose set of values has cardinality strictly less than the cardina=
lity of the set of storable values of their storage. Example of such types =
defined in the standard, are bool and nullptr_t. (having respectively 2 and=
1 value, but much wider storage capacity) Details aside, the storage could=
be defined as :<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">union</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> optional_storage </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br> underlying_type storage</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br> type value</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>Definedness would=
amount to testing the "storage" against the undefined "value".<br><br>Dete=
rmining denseness or sparseness could be done by traits/concepts/whatever T=
MP supports, this is still an open question in my mind.<br><br>That said:<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt =
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div =
bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<br>
template <typename T, typename DegenerateValue><br>
struct optional <degenerate<T,DegenerateValue><wbr>><br>
{<br>
// include here the degenerated specialization<br>
}<br>
<br>
In this way optional doesn't changes its interface (preserv only one
template parameter), and we are able to have <br>
<br>
optional<T><br>
<br>
and<br>
<br>
optional<degenerate<Player, integral_constant<Player,
Player(-1)>><br>
<br></div></blockquote><div><br>I'd say yes, this is a fair idea. You t=
ake the word "degenerate" and make it an adjective to the type Player, with=
a value representing disengagedness. This would be the result of a refacto=
ring the templates, I think.<br><br>I think that your <span style=3D"font-f=
amily: courier new,monospace;">degenerate<Player, integral_constant<P=
layer, Player(-1)></span> (using your definition of <span style=3D"font-=
family: courier new,monospace;">degenerate</span>) would benefit of being a=
full-fledged type representing <span style=3D"font-family: courier new,mon=
ospace;">Player - Player(-1)</span> and actually used in the signature of <=
span style=3D"font-family: courier new,monospace;">optional<></span> =
members.<br><br>This object would then build the "sparse" type <span style=
=3D"font-family: courier new,monospace;">Player - Player(-1)<font face=3D"a=
rial,sans-serif"> from the "dense" type <span style=3D"font-family: courier=
new,monospace;">Player</span>.</font> <font face=3D"arial,sans-serif">The =
same space-efficient optimization of <span style=3D"font-family: courier ne=
w,monospace;">optional<></span> could be used for <span style=3D"font=
-family: courier new,monospace;">bool </span>and all other "sparse" types a=
ll the same.<br><br>This makes me think that Core C++ would benefit having =
a way of defining truly "sparse" enums.<br></font></span></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_3005_13267621.1378287313681--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 02:39:17 -0700 (PDT)
Raw View
------=_Part_201_18744082.1378287557110
Content-Type: text/plain; charset=ISO-8859-1
David,
> Same as my suggestion above :v)
>
> Except that if the order of parameters is reversed, then the type (e.g.
> Player) may be retrieved from integral_constant.
>
Indeed. I was intended to give you credit for this is my response to
Vicente, but in the flow of more technical writing, I forgot. Please don't
think that I'm ignoring you :)
Laurent
--
---
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_201_18744082.1378287557110
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div>David,<br> <br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"><div>Same as my suggest=
ion above :v)<br><br>Except that if the order of parameters is reversed, th=
en the type (e.g. <span style=3D"font-family:courier new,monospace">Player<=
/span>) may be retrieved from <span style=3D"font-family:courier new,monosp=
ace">integral_constant</span>.<br></div></div></blockquote><div><br>Indeed.=
I was intended to give you credit for this is my response to Vicente, but =
in the flow of more technical writing, I forgot. Please don't think that I'=
m ignoring you :) <br><br>Laurent<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_201_18744082.1378287557110--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 4 Sep 2013 05:37:32 -0700 (PDT)
Raw View
------=_Part_4043_18955837.1378298252963
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, September 3, 2013 11:43:48 PM UTC-7, Vicente J. Botet Escriba=
=20
wrote:
>
> Le 04/09/13 06:48, the.ultim...@gmail.com <javascript:> a =E9crit :
> =20
> What do you think about defining the degenerate class empty
>
> template <typename T, typename DegenerateValue>
> struct degenerate
> {
> typedef T value_type;
> typedef DegenerateValue degenerate_value_type;
> };
>
> and use it to make specialization of optional
>
> template <typename T, typename DegenerateValue>
> struct optional <degenerate<T,DegenerateValue>>
> {
> // include here the degenerated specialization
> }
>
> In this way optional doesn't changes its interface (preserv only one=20
> template parameter), and we are able to have=20
>
> optional<T>
>
> and
>
> optional<degenerate<Player, integral_constant<Player, Player(-1)>>
>
That seems way too much like a kludge. Sure, you can `template using=3D` yo=
ur=20
way around it, but we shouldn't *have* to do things like that just to make=
=20
something useable. What is so wrong with just making `optional<T, Tester>`=
=20
as a variation? We do something similar for `unique_ptr`.
I can't imagine how difficult it would be to implement that, with all those=
=20
`std::enable_if`s and everything. That's a huge burden compared to simply=
=20
having another template overload.
--=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_4043_18955837.1378298252963
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, September 3, 2013 11:43:48 PM UTC-7, V=
icente J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 04/09/13 06:48,
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Bx=
WDbIdhIawJ">the.ultim...@gmail.com</a> a =E9crit :<br>
</div>
<br>
What do you think about defining the degenerate class empty<br>
<br>
template <typename T, typename DegenerateValue><br>
struct degenerate<br>
{<br>
typedef T value_type;<br>
typedef DegenerateValue degenerate_value_type;<br>
};<br>
<br>
and use it to make specialization of optional<br>
<br>
template <typename T, typename DegenerateValue><br>
struct optional <degenerate<T,DegenerateValue><wbr>><br>
{<br>
// include here the degenerated specialization<br>
}<br>
<br>
In this way optional doesn't changes its interface (preserv only one
template parameter), and we are able to have <br>
<br>
optional<T><br>
<br>
and<br>
<br>
optional<degenerate<Player, integral_constant<Player,
Player(-1)>><br></div></blockquote><div><br>That seems way too mu=
ch like a kludge. Sure, you can `template using=3D` your way around it, but=
we shouldn't <i>have</i> to do things like that just to make something use=
able. What is so wrong with just making `optional<T, Tester>` as a va=
riation? We do something similar for `unique_ptr`.<br><br>I can't imagine h=
ow difficult it would be to implement that, with all those `std::enable_if`=
s and everything. That's a huge burden compared to simply having another te=
mplate overload.<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_4043_18955837.1378298252963--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 4 Sep 2013 06:35:17 -0700 (PDT)
Raw View
------=_Part_4501_32504497.1378301717206
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Wednesday, September 4, 2013 8:37:32 PM UTC+8, Nicol Bolas wrote:
>
> That seems way too much like a kludge. Sure, you can `template using=3D`=
=20
> your way around it, but we shouldn't *have* to do things like that just=
=20
> to make something useable. What is so wrong with just making `optional<T,=
=20
> Tester>` as a variation? We do something similar for `unique_ptr`.
>
unique_ptr uses a deleter, which is part of the smart pointer framework. (
shared_ptr also has them, albeit not as a template argument.) And they are=
=20
analogous to container allocators. Actually we would be better off if=20
unique_ptr had used an Allocator argument; it could be used by make_uniquee=
ven if=20
unique_ptr itself only needs the destructor/deallocator capability.
It's good to avoid adding new *kinds* of template arguments for unique=20
situations. My above suggestion is to name it excluded_value<=85>, and reus=
e=20
the same concept for compile-time numeric ranges and such. So this use-case=
=20
would be naturally forming an optional over a type excluding a particular=
=20
value. The Tester concept could be reused for other things. No need to=20
tackle the world all at once, but at least there's a way forward to=20
genericity.
=20
> I can't imagine how difficult it would be to implement that, with all=20
> those `std::enable_if`s and everything. That's a huge burden compared to=
=20
> simply having another template overload.
>
Not sure what you mean. It would be a straightforward partial=20
specialization. Adding a second argument as you propose would also involve=
=20
partial specialization; the primary template we now know as optional would=
=20
become the Tester=3Dvoid specialization. Aside from the role reversal over=
=20
which is primary and which is specialized, the implementations would be=20
exactly the same.
Note that the one-argument style can be already be implemented/prototyped=
=20
as a third-party library.
I think Tester might be a better semantic than DegenerateValue as it allows=
=20
support for NaN, which behaves badly with direct comparison. But whatever=
=20
is used, can probably be specialized on both, since a functor doesn't look=
=20
much like a compile-time constant.
--=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_4501_32504497.1378301717206
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, September 4, 2013 8:37:32 PM UTC+8, =
Nicol Bolas 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"=
ltr">That seems way too much like a kludge. Sure, you can `template using=
=3D` your way around it, but we shouldn't <i>have</i> to do things like tha=
t just to make something useable. What is so wrong with just making `option=
al<T, Tester>` as a variation? We do something similar for `unique_pt=
r`.<br></div></blockquote><div><br><span style=3D"font-family: courier new,=
monospace;">unique_ptr</span> uses a deleter, which is part of the smart po=
inter framework. (<span style=3D"font-family: courier new,monospace;">share=
d_ptr</span> also has them, albeit not as a template argument.) And they ar=
e analogous to container allocators. Actually we would be better off if <sp=
an style=3D"font-family: courier new,monospace;">unique_ptr</span> had used=
an Allocator argument; it could be used by <span style=3D"font-family: cou=
rier new,monospace;">make_unique</span> even if <span style=3D"font-family:=
courier new,monospace;">unique_ptr</span> itself only needs the destructor=
/deallocator capability.<br><br>It's good to avoid adding new *kinds* of te=
mplate arguments for unique situations. My above suggestion is to name it <=
span style=3D"font-family: courier new,monospace;">excluded_value<=85>=
;</span>, and reuse the same concept for compile-time numeric ranges and su=
ch. So this use-case would be naturally forming an <span style=3D"font-fami=
ly: courier new,monospace;">optional</span> over a type excluding a particu=
lar value. The <span style=3D"font-family: courier new,monospace;">Tester</=
span> concept could be reused for other things. No need to tackle the world=
all at once, but at least there's a way forward to genericity.<br> </=
div><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>I ca=
n't imagine how difficult it would be to implement that, with all those `st=
d::enable_if`s and everything. That's a huge burden compared to simply havi=
ng another template overload.<br></div></div></blockquote><div><br>Not sure=
what you mean. It would be a straightforward partial specialization. Addin=
g a second argument as you propose would also involve partial specializatio=
n; the primary template we now know as <span style=3D"font-family: courier =
new,monospace;">optional</span> would become the <span style=3D"font-family=
: courier new,monospace;">Tester=3Dvoid</span><font face=3D"arial,sans-seri=
f"> specialization.</font> Aside from the role reversal over which is prima=
ry and which is specialized, the implementations would be exactly the same.=
<br><br>Note that the one-argument style can be already be implemented/prot=
otyped as a third-party library.<br><br>I think <span style=3D"font-family:=
courier new,monospace;">Tester</span> might be a better semantic than <spa=
n style=3D"font-family: courier new,monospace;">DegenerateValue<font face=
=3D"arial,sans-serif"> as it allows support for NaN, which behaves badly wi=
th direct comparison. But whatever is used, can probably be specialized on =
both, since a functor doesn't look much like a compile-time constant.</font=
></span><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_4501_32504497.1378301717206--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 06:40:37 -0700 (PDT)
Raw View
------=_Part_27_30895072.1378302037445
Content-Type: text/plain; charset=ISO-8859-1
> We do something similar for `unique_ptr`.
>
Where exactly? If you think about the ability of specifying the deleter,
yes, the implementation technique you propose is applied. But no it's not
the same. The deleter will still be called ONLY if p.get() == nullptr. You
don't have the possibility to change the precondition to p.get() ==
0xDEADBEEF. The set of pointers for which the deleter can be called is the
same for both overloads.
I can't imagine how difficult it would be to implement that, with all those
> `std::enable_if`s and everything. That's a huge burden compared to simply
> having another template overload.
>
Indeed. And it would be a shame if standardizing such an overload NOW would
get in the way of an automated way of knowing whether the type you want to
optionalize has a "free slot" or not, that would otherwise be permitted by,
say concepts-lite, or strong typedefs.
--
---
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_27_30895072.1378302037445
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"> <br><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>We do something similar for `unique_ptr`.<b=
r></div></div></blockquote><div><br>Where exactly? If you think about the a=
bility of specifying the deleter, yes, the implementation technique you pro=
pose is applied. But no it's not the same. The deleter will still be called=
ONLY if <span style=3D"font-family: courier new,monospace;">p.get() =3D=3D=
nullptr</span>. You don't have the possibility to change the precondition =
to <span style=3D"font-family: courier new,monospace;">p.get() =3D=3D 0xDEA=
DBEEF</span>. The set of pointers for which the deleter can be called is th=
e same for both overloads.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204=
); padding-left: 1ex;"><div dir=3D"ltr"><div>I can't imagine how difficult =
it would be to implement that, with all those `std::enable_if`s and everyth=
ing. That's a huge burden compared to simply having another template overlo=
ad.<br></div></div></blockquote><div><br>Indeed. And it would be a shame if=
standardizing such an overload NOW would get in the way of an automated wa=
y of knowing whether the type you want to optionalize has a "free slot" or =
not, that would otherwise be permitted by, say concepts-lite, or strong typ=
edefs. <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_27_30895072.1378302037445--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 07:20:29 -0700 (PDT)
Raw View
------=_Part_173_15808551.1378304429759
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
David,
It's good to avoid adding new *kinds* of template arguments for unique=20
> situations. My above suggestion is to name it excluded_value<=85>, and=20
> reuse the same concept for compile-time numeric ranges and such. So this=
=20
> use-case would be naturally forming an optional over a type excluding a=
=20
> particular value.=20
>
Indeed but I would go much further than this. I would say that you can only=
=20
apply this space-saving technique if the type you declare has a "free=20
slot", i.e. the space of allowable values does not take up all the values=
=20
that can be stored by the storage allocated to the object. I came up with=
=20
the words "dense" and "sparse" for qualifying this dichotomy of types. The=
=20
choice of the implementation of "optional" for these types would only need =
:
- The concepts Sparse<T> and Dense<T>,
- The ability to get the underlying_type of a type T, whether Sparse or=
=20
Dense,
- For a type T that is Sparse, the ability to get the first value of the=
=20
underlying type not used by type T,
- Concepts-lite :)
=20
Then, the ability to construct Sparse types, on the top of my head:
- A meta-function remove_value<type T, T v> that would build a type=20
based on T, that behaves like T, except that it cannot take value v. (Th=
e=20
resulting type would be sparse, as there would at least be one free valu=
e)
- Integer values that can limit their values to a sequence of disjoint=
=20
ranges : limited<int, range<int, -3, 10>, range<int, 20, 50>> (Disclaime=
r:=20
syntax subject to change)
- Something like "enum private class" that can create an enumerated=20
type, for which objects of that type can only take the values represente=
d=20
by an enumerator.
- ...
=20
I think Tester might be a better semantic than DegenerateValue as it allows=
=20
> support for NaN, which behaves badly with direct comparison. But whatever=
=20
> is used, can probably be specialized on both, since a functor doesn't loo=
k=20
> much like a compile-time constant.
>
Using the semantics of Sparse<T> and Dense<T> as outlined above, I'd say=20
Dense<double> and Dense<float>, although I don't know if there are any=20
values left free by IEEE754.
--=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_173_15808551.1378304429759
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">David,<br><br><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div>It's good to avoid adding new *kinds* of template ar=
guments for unique situations. My above suggestion is to name it <span styl=
e=3D"font-family:courier new,monospace">excluded_value<=85></span>, a=
nd reuse the same concept for compile-time numeric ranges and such. So this=
use-case would be naturally forming an <span style=3D"font-family:courier =
new,monospace">optional</span> over a type excluding a particular value. </=
div></div></blockquote><div><br>Indeed but I would go much further than thi=
s. I would say that you can only apply this space-saving technique if the t=
ype you declare has a "free slot", i.e. the space of allowable values does =
not take up all the values that can be stored by the storage allocated to t=
he object. I came up with the words "dense" and "sparse" for qualifying thi=
s dichotomy of types. The choice of the implementation of "optional" for th=
ese types would only need :<br><ul><li>The concepts Sparse<T> and Den=
se<T>,</li><li>The ability to get the underlying_type of a type T, wh=
ether Sparse or Dense,<br></li><li>For a type T that is Sparse, the ability=
to get the first value of the underlying type not used by type T,</li><li>=
Concepts-lite :)<br></li></ul>Then, the ability to construct Sparse types, =
on the top of my head:<br><ul><li>A meta-function remove_value<type T, T=
v> that would build a type based on T, that behaves like T, except that=
it cannot take value v. (The resulting type would be sparse, as there woul=
d at least be one free value)<br></li><li>Integer values that can limit the=
ir values to a sequence of disjoint ranges : limited<int, range<int, =
-3, 10>, range<int, 20, 50>> (Disclaimer: syntax subject to cha=
nge)</li><li>Something like "enum private class" that can create an enumera=
ted type, for which objects of that type can only take the values represent=
ed by an enumerator.</li><li>...<br></li></ul></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"><div>I think <span styl=
e=3D"font-family:courier new,monospace">Tester</span> might be a better sem=
antic than <span style=3D"font-family:courier new,monospace">DegenerateValu=
e<font face=3D"arial,sans-serif"> as it allows support for NaN, which behav=
es badly with direct comparison. But whatever is used, can probably be spec=
ialized on both, since a functor doesn't look much like a compile-time cons=
tant.</font></span><br></div></div></blockquote><div><br>Using the semantic=
s of Sparse<T> and Dense<T> as outlined above, I'd say Dense<=
;double> and Dense<float>, although I don't know if there are any =
values left free by IEEE754.<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_173_15808551.1378304429759--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 4 Sep 2013 08:22:59 -0700 (PDT)
Raw View
------=_Part_98_2731905.1378308179724
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Wednesday, September 4, 2013 10:20:29 PM UTC+8, the.ultim...@gmail.com=
=20
wrote:
>
> David,
>
> It's good to avoid adding new *kinds* of template arguments for unique=20
>> situations. My above suggestion is to name it excluded_value<=85>, and=
=20
>> reuse the same concept for compile-time numeric ranges and such. So this=
=20
>> use-case would be naturally forming an optional over a type excluding a=
=20
>> particular value.=20
>>
>
> Indeed but I would go much further than this. I would say that you can=20
> only apply this space-saving technique if the type you declare has a "fre=
e=20
> slot", i.e. the space of allowable values does not take up all the values=
=20
> that can be stored by the storage allocated to the object. I came up with=
=20
> the words "dense" and "sparse" for qualifying this dichotomy of types. Th=
e=20
> choice of the implementation of "optional" for these types would only nee=
d :
>
Please no, dense and sparse have mathematical meanings completely different=
=20
from this. Rational numbers over a bignum type could sort-of be called=20
dense in the mathematical sense.
>
> - The concepts Sparse<T> and Dense<T>,
>
> What's the point of complementary concepts? Define "Dense" as "not=20
Sparse." And Sparse (or ValueConstraint) is just the conceptual interface=
=20
of excluded_value or degenerate or whatever.
Making Dense a specific concept implies that it has specific requirements=
=20
besides being not Sparse, which opens the possibility of a type that=20
satisfies neither. Then what would optional do? Implementation would also=
=20
be complicated, with a need for enable_if as Nicol mentioned.
>
> - The ability to get the underlying_type of a type T, whether Sparse=
=20
> or Dense,
> =20
> Maybe I'm confused. What could the underlying type of a Dense type be,=20
besides itself?
Using the semantics of Sparse<T> and Dense<T> as outlined above, I'd say=20
> Dense<double> and Dense<float>, although I don't know if there are any=20
> values left free by IEEE754.
>
There are as many distinct NaNs as there are numbers between 0.5 and 1, but=
=20
it's a bad idea to try to distinguish them.
--=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_98_2731905.1378308179724
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, September 4, 2013 10:20:29 PM UTC+8,=
the.ultim...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">David,<br><br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>It's good to avoid adding new *kinds* of template argumen=
ts for unique situations. My above suggestion is to name it <span style=3D"=
font-family:courier new,monospace">excluded_value<=85></span>, and re=
use the same concept for compile-time numeric ranges and such. So this use-=
case would be naturally forming an <span style=3D"font-family:courier new,m=
onospace">optional</span> over a type excluding a particular value. </div><=
/div></blockquote><div><br>Indeed but I would go much further than this. I =
would say that you can only apply this space-saving technique if the type y=
ou declare has a "free slot", i.e. the space of allowable values does not t=
ake up all the values that can be stored by the storage allocated to the ob=
ject. I came up with the words "dense" and "sparse" for qualifying this dic=
hotomy of types. The choice of the implementation of "optional" for these t=
ypes would only need :<br></div></div></blockquote><div><br>Please no, dens=
e and sparse have mathematical meanings completely different from this. Rat=
ional numbers over a bignum type could sort-of be called dense in the mathe=
matical sense.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><ul><li>The concepts Sparse<T> and Dense<T>,</l=
i></ul></div></div></blockquote><div>What's the point of complementary conc=
epts? Define "Dense" as "not Sparse." And Sparse (or ValueConstraint) is ju=
st the conceptual interface of <span style=3D"font-family: courier new,mono=
space;">excluded_value</span> or <span style=3D"font-family: courier new,mo=
nospace;">degenerate</span> or whatever.<br><br>Making Dense a specific con=
cept implies that it has specific requirements besides being not Sparse, wh=
ich opens the possibility of a type that satisfies neither. Then what would=
<span style=3D"font-family: courier new,monospace;">optional</span> do? Im=
plementation would also be complicated, with a need for <span style=3D"font=
-family: courier new,monospace;">enable_if</span> as Nicol mentioned.<br></=
div><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><ul>=
<li>The ability to get the underlying_type of a type T, whether Sparse or D=
ense,<br></li></ul></div></div></blockquote><div>Maybe I'm confused. What c=
ould the underlying type of a Dense type be, besides itself?<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Using the sema=
ntics of Sparse<T> and Dense<T> as outlined above, I'd say Dens=
e<double> and Dense<float>, although I don't know if there are =
any values left free by IEEE754.<br></div></blockquote><div><br>There are a=
s many distinct NaNs as there are numbers between 0.5 and 1, but it's a bad=
idea to try to distinguish them.<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_98_2731905.1378308179724--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 09:04:05 -0700 (PDT)
Raw View
------=_Part_466_9070264.1378310645629
Content-Type: text/plain; charset=ISO-8859-1
> Please no, dense and sparse have mathematical meanings completely
> different from this. Rational numbers over a bignum type could sort-of be
> called dense in the mathematical sense.
>
Yes, although I am not a mathematician, I know that mathematics have, to my
dismay, assigned precise meaning to a huge part of the dictionary. I just
found these better than OhNoItsPacked<T> and
YessssssThereIsACornerThereFitItInFitItInQuick<T> :-)
If you agree with the idea, would you mind help me find better names?
>
>> - The concepts Sparse<T> and Dense<T>,
>>
>> What's the point of complementary concepts? Define "Dense" as "not
> Sparse."
>
Of course.
Implementation would also be complicated, with a need for enable_if as
> Nicol mentioned.
>
Or Concepts Lite. (N3701) Sparse<T> and !Sparse<T> should cover a great
deal of value semantics.
I'm getting ahead of myself, I know. I'm imagining what an ideal
implementation of optional<T> would look like.
>
>> - The ability to get the underlying_type of a type T, whether Sparse
>> or Dense,
>>
>> Maybe I'm confused. What could the underlying type of a Dense type be,
> besides itself?
>
>
enums and enum classes are Dense, but their underlying types are different.
Using the semantics of Sparse<T> and Dense<T> as outlined above, I'd say
>> Dense<double> and Dense<float>, although I don't know if there are any
>> values left free by IEEE754.
>>
> There are as many distinct NaNs as there are numbers between 0.5 and 1,
> but it's a bad idea to try to distinguish them.
>
So can we create a C++ type that can store doubles that are non-NaN? What
would be the interface of such a type?
--
---
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_466_9070264.1378310645629
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Please no, dense and sparse have mathematical meanings comple=
tely different from this. Rational numbers over a bignum type could sort-of=
be called dense in the mathematical sense.<br></div></div></blockquote><di=
v><br>Yes, although I am not a mathematician, I know that mathematics have,=
to my dismay, assigned precise meaning to a huge part of the dictionary. I=
just found these better than OhNoItsPacked<T> and YessssssThereIsACo=
rnerThereFitItInFitItInQuick<T> :-)<br><br>If you agree with the idea=
, would you mind help me find better names?<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><ul><li>The concepts Sparse<T> =
and Dense<T>,</li></ul></div></div></blockquote><div>What's the point=
of complementary concepts? Define "Dense" as "not Sparse."</div></div></bl=
ockquote><div><br>Of course.<br><br></div><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> Implementation would also be complicated=
, with a need for <span style=3D"font-family:courier new,monospace">enable_=
if</span> as Nicol mentioned.<br></div></div></blockquote><div><br>Or Conce=
pts Lite. (N3701) Sparse<T> and !Sparse<T> should cover a great=
deal of value semantics.<br><br>I'm getting ahead of myself, I know. I'm i=
magining what an ideal implementation of <span style=3D"font-family: courie=
r new,monospace;">optional<T></span> would look like.<br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><ul><li>The ability t=
o get the underlying_type of a type T, whether Sparse or Dense,<br></li></u=
l></div></div></blockquote><div>Maybe I'm confused. What could the underlyi=
ng type of a Dense type be, besides itself?<br><br></div></div></blockquote=
><div><br><span style=3D"font-family: courier new,monospace;">enum</span>s =
and <span style=3D"font-family: courier new,monospace;">enum class</span>es=
are Dense, but their underlying types are different.<br><br></div><blockqu=
ote 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></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr">Using the semantics of Spars=
e<T> and Dense<T> as outlined above, I'd say Dense<double>=
; and Dense<float>, although I don't know if there are any values lef=
t free by IEEE754.<br></div></blockquote><div></div></div></blockquote><blo=
ckquote 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>There are as=
many distinct NaNs as there are numbers between 0.5 and 1, but it's a bad =
idea to try to distinguish them.<br></div></div></blockquote><div> <br=
>So can we create a C++ type that can store doubles that are non-NaN? What =
would be the interface of such a type?<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_466_9070264.1378310645629--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 04 Sep 2013 18:05:44 +0200
Raw View
This is a multi-part message in MIME format.
--------------070808090102030307020204
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 04/09/13 14:37, Nicol Bolas a =E9crit :
>
>
> On Tuesday, September 3, 2013 11:43:48 PM UTC-7, Vicente J. Botet=20
> Escriba wrote:
>
> Le 04/09/13 06:48, the.ultim...@gmail.com <javascript:> a =E9crit :
>
> What do you think about defining the degenerate class empty
>
> template <typename T, typename DegenerateValue>
> struct degenerate
> {
> typedef T value_type;
> typedef DegenerateValue degenerate_value_type;
> };
>
> and use it to make specialization of optional
>
> template <typename T, typename DegenerateValue>
> struct optional <degenerate<T,DegenerateValue>>
> {
> // include here the degenerated specialization
> }
>
> In this way optional doesn't changes its interface (preserv only
> one template parameter), and we are able to have
>
> optional<T>
>
> and
>
> optional<degenerate<Player, integral_constant<Player, Player(-1)>>
>
>
> That seems way too much like a kludge. Sure, you can `template using=3D`=
=20
> your way around it, but we shouldn't /have/ to do things like that=20
> just to make something useable. What is so wrong with just making=20
> `optional<T, Tester>` as a variation? We do something similar for=20
> `unique_ptr`.
>
There is nothing wrong. Just this must be done quickly as once in C++14=20
it would be not so easy to change the std::optional interface. My=20
suggestion could be adopted just after c++14 is released.
Vicente
--=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/.
--------------070808090102030307020204
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 04/09/13 14:37, Nicol Bolas a
=E9crit=A0:<br>
</div>
<blockquote
cite=3D"mid:90eb2850-ff75-47b6-979d-ac7400146b0b@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Tuesday, September 3, 2013 11:43:48 PM UTC-7, Vicente J.
Botet Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 04/09/13 06:48, <a moz-do-not-send=3D"true"
href=3D"javascript:" target=3D"_blank"
gdf-obfuscated-mailto=3D"BxWDbIdhIawJ">the.ultim...@gmail.c=
om</a>
a =E9crit=A0:<br>
</div>
<br>
What do you think about defining the degenerate class empty<br>
<br>
template <typename T, typename DegenerateValue><br>
struct degenerate<br>
{<br>
=A0 typedef T value_type;<br>
=A0 typedef DegenerateValue degenerate_value_type;<br>
};<br>
<br>
and use it to make=A0 specialization of optional<br>
<br>
template <typename T, typename DegenerateValue><br>
struct optional <degenerate<T,DegenerateValue><wbr>>=
;<br>
{<br>
=A0// include here the degenerated specialization<br>
}<br>
<br>
In this way optional doesn't changes its interface (preserv
only one template parameter), and we are able to have <br>
<br>
optional<T><br>
<br>
and<br>
<br>
optional<degenerate<Player,
integral_constant<Player, Player(-1)>><br>
</div>
</blockquote>
<div><br>
That seems way too much like a kludge. Sure, you can `template
using=3D` your way around it, but we shouldn't <i>have</i> to
do things like that just to make something useable. What is so
wrong with just making `optional<T, Tester>` as a
variation? We do something similar for `unique_ptr`.<br>
<br>
</div>
</div>
</blockquote>
There is nothing wrong. Just this must be done quickly as once in
C++14 it would be not so easy to change the std::optional interface.
My suggestion could be adopted just after c++14 is released.<br>
<br>
Vicente
</body>
</html>
<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 />
--------------070808090102030307020204--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 09:16:40 -0700 (PDT)
Raw View
------=_Part_419_8343460.1378311400707
Content-Type: text/plain; charset=ISO-8859-1
Vicente,
> There is nothing wrong. Just this must be done quickly as once in C++14
> it would be not so easy to change the std::optional interface. My
> suggestion could be adopted just after c++14 is released.
>
> Vicente
>
This must NOT be done quickly, as once in C++14 it would not be so easy to
take out, except by deprecation. If you wish to propose it to the
committee, please write the proposal and go for it. I think it's not ready
at all. (try feeding the template with a reference type, for instance)
--
---
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_419_8343460.1378311400707
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Vicente, <br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><blockquote type=3D"cite"><div di=
r=3D"ltr"><div>
</div>
</div>
</blockquote>
There is nothing wrong. Just this must be done quickly as once in
C++14 it would be not so easy to change the std::optional interface.
My suggestion could be adopted just after c++14 is released.<br>
<br>
Vicente
</div></blockquote><div><br>This must NOT be done quickly, as once in C++=
14 it would not be so easy to take out, except by deprecation. If you wish =
to propose it to the committee, please write the proposal and go for it. I =
think it's not ready at all. (try feeding the template with a reference typ=
e, for instance)<br><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_419_8343460.1378311400707--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 4 Sep 2013 19:20:51 +0300
Raw View
--089e0149ce365d134d04e5913017
Content-Type: text/plain; charset=ISO-8859-1
On 4 September 2013 19:05, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> In this way optional doesn't changes its interface (preserv only one
> template parameter), and we are able to have
>
>
>> optional<T>
>>
>> and
>>
>> optional<degenerate<Player, integral_constant<Player, Player(-1)>>
>>
>
> That seems way too much like a kludge. Sure, you can `template using=`
> your way around it, but we shouldn't *have* to do things like that just
> to make something useable. What is so wrong with just making `optional<T,
> Tester>` as a variation? We do something similar for `unique_ptr`.
>
> There is nothing wrong. Just this must be done quickly as once in C++14
> it would be not so easy to change the std::optional interface. My
> suggestion could be adopted just after c++14 is released.
>
>
>
Perhaps we should leave optional well alone and consider something like
http://rk.hekko.pl/constrained_value/
as a potential solution for cases where you want a type is a constrained
value rather than a nullable
proxy.
--
---
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/.
--089e0149ce365d134d04e5913017
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 September 2013 19:05, Vicente J. Botet Escriba <span dir=3D"lt=
r"><<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicent=
e.botet@wanadoo.fr</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">In this way optional doesn'=
t changes its interface (preserv
only one template parameter), and we are able to have <br><div =
class=3D"im"><blockquote type=3D"cite"><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
optional<T><br>
<br>
and<br>
<br>
optional<degenerate<Player,
integral_constant<Player, Player(-1)>><br>
</div>
</blockquote>
<div><br>
That seems way too much like a kludge. Sure, you can `template
using=3D` your way around it, but we shouldn't <i>have</i> to
do things like that just to make something useable. What is so
wrong with just making `optional<T, Tester>` as a
variation? We do something similar for `unique_ptr`.<br>
<br>
</div>
</div>
</blockquote></div>
There is nothing wrong. Just this must be done quickly as once in
C++14 it would be not so easy to change the std::optional interface.
My suggestion could be adopted just after c++14 is released.<span class=
=3D""><font color=3D"#888888"><br>
<br><br></font></span></div></blockquote><div><br></div><div>Perhaps we=
should leave optional well alone and consider something like <a href=3D"ht=
tp://rk.hekko.pl/constrained_value/">http://rk.hekko.pl/constrained_value/<=
/a><br>
</div><div>as a potential solution for cases where you want a type is a con=
strained value rather than a nullable<br></div><div>proxy. <br></div></div>=
<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 />
--089e0149ce365d134d04e5913017--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 4 Sep 2013 19:24:44 +0300
Raw View
--089e013cbebc4c7c0b04e5913ef9
Content-Type: text/plain; charset=ISO-8859-1
On 4 September 2013 19:16, <the.ultimate.koala@gmail.com> wrote:
> Vicente,
>
>> There is nothing wrong. Just this must be done quickly as once in
>> C++14 it would be not so easy to change the std::optional interface. My
>> suggestion could be adopted just after c++14 is released.
>>
>> Vicente
>>
>
> This must NOT be done quickly, as once in C++14 it would not be so easy to
> take out, except by deprecation. If you wish to propose it to the
> committee, please write the proposal and go for it. I think it's not ready
> at all. (try feeding the template with a reference type, for instance)
>
>
Well, the time for such proposals for c++14 is well past, the NB ballot is
over and the NB comments are in
the pre-Chicago mailing, so whatever you come up with now is going to be
out of scope for c++14 unless
you convince the committee that it's an urgent bug fix, which I doubt will
happen.
--
---
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/.
--089e013cbebc4c7c0b04e5913ef9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 September 2013 19:16, <span dir=3D"ltr"><<a href=3D"mailto=
:the.ultimate.koala@gmail.com" target=3D"_blank">the.ultimate.koala@gmail.c=
om</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Vicente, <br><div class=3D"=
im"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><blockquote type=3D"cite"><div di=
r=3D"ltr"><div>
</div>
</div>
</blockquote>
There is nothing wrong. Just this must be done quickly as once in
C++14 it would be not so easy to change the std::optional interface.
My suggestion could be adopted just after c++14 is released.<br>
<br>
Vicente
</div></blockquote></div><div><br>This must NOT be done quickly, as once =
in C++14 it would not be so easy to take out, except by deprecation. If you=
wish to propose it to the committee, please write the proposal and go for =
it. I think it's not ready at all. (try feeding the template with a ref=
erence type, for instance)<br>
<br></div></div></blockquote><div><br></div><div>Well, the time for such pr=
oposals for c++14 is well past, the NB ballot is over and the NB comments a=
re in<br>the pre-Chicago mailing, so whatever you come up with now is going=
to be out of scope for c++14 unless<br>
you convince the committee that it's an urgent bug fix, which I doubt w=
ill happen. <br></div></div><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 />
--089e013cbebc4c7c0b04e5913ef9--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 10:57:48 -0700 (PDT)
Raw View
------=_Part_3496_31010801.1378317468821
Content-Type: text/plain; charset=ISO-8859-1
Ville,
> Perhaps we should leave optional well alone and consider something like
> http://rk.hekko.pl/constrained_value/
> as a potential solution for cases where you want a type is a constrained
> value rather than a nullable
> proxy.
>
>
I've been OK for leaving optional<> alone from the beginning of this
thread. Tell me. Why I you interesting specifically in considering
constrained values types? (Possibly in another thread)
--
---
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_3496_31010801.1378317468821
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ville,<br><br><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote"><br><div>Perhaps we shoul=
d leave optional well alone and consider something like <a href=3D"http://r=
k.hekko.pl/constrained_value/" target=3D"_blank">http://rk.hekko.pl/<wbr>co=
nstrained_value/</a><br>
</div><div>as a potential solution for cases where you want a type is a con=
strained value rather than a nullable<br></div><div>proxy. <br></div></div>=
<br></div></div></blockquote><div><br>I've been OK for leaving optional<=
> alone from the beginning of this thread. Tell me. Why I you interestin=
g specifically in considering constrained values types? (Possibly in anothe=
r thread)<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_3496_31010801.1378317468821--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 4 Sep 2013 21:19:29 +0300
Raw View
--047d7b4724f6a3db3104e592d8f6
Content-Type: text/plain; charset=ISO-8859-1
On 4 September 2013 20:57, <the.ultimate.koala@gmail.com> wrote:
>
>
>> Perhaps we should leave optional well alone and consider something like
>> http://rk.hekko.pl/**constrained_value/<http://rk.hekko.pl/constrained_value/>
>> as a potential solution for cases where you want a type is a constrained
>> value rather than a nullable
>> proxy.
>>
>>
> I've been OK for leaving optional<> alone from the beginning of this
> thread. Tell me. Why I you interesting specifically in considering
> constrained values types? (Possibly in another thread)
>
>
>
>
It seems to me that constrained value types would solve the problem you
describe, whereas optional
is designed to solve a quite different problem.
--
---
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/.
--047d7b4724f6a3db3104e592d8f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 September 2013 20:57, <span dir=3D"ltr"><<a href=3D"mailto=
:the.ultimate.koala@gmail.com" target=3D"_blank">the.ultimate.koala@gmail.c=
om</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"im"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><br><div>Perhaps we should=
leave optional well alone and consider something like <a href=3D"http://rk=
..hekko.pl/constrained_value/" target=3D"_blank">http://rk.hekko.pl/<u></u>c=
onstrained_value/</a><br>
</div><div>as a potential solution for cases where you want a type is a con=
strained value rather than a nullable<br></div><div>proxy. <br></div></div>=
<br></div></div></blockquote></div><div><br>I've been OK for leaving op=
tional<> alone from the beginning of this thread. Tell me. Why I you =
interesting specifically in considering constrained values types? (Possibly=
in another thread)<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>It seems to me that co=
nstrained value types would solve the problem you describe, whereas optiona=
l<br>is designed to solve a quite different problem. <br></div></div><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 />
--047d7b4724f6a3db3104e592d8f6--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 12:02:09 -0700 (PDT)
Raw View
------=_Part_504_15491199.1378321329407
Content-Type: text/plain; charset=ISO-8859-1
Ville,
Sorry, I don't follow you. Which problem exactly is would constrained
values solve and how? I have described at least half a dozen problems in
this thread.
--
---
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_504_15491199.1378321329407
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr">Ville,<br><br>Sorry, I don't follow you. Which problem exactly is would constrained values solve and how? I have described at least half a dozen problems in this thread.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to 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="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_504_15491199.1378321329407--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 4 Sep 2013 22:26:59 +0300
Raw View
--047d7b47215e06ba6704e593ca86
Content-Type: text/plain; charset=ISO-8859-1
On 4 September 2013 22:02, <the.ultimate.koala@gmail.com> wrote:
> Ville,
>
> Sorry, I don't follow you. Which problem exactly is would constrained
> values solve and how? I have described at least half a dozen problems in
> this thread.
>
>
>
>
The one you originally requested feedback for. The possible values for a
player are a subset
of the values for a square.
--
---
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/.
--047d7b47215e06ba6704e593ca86
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 4 September 2013 22:02, <span dir=3D"ltr"><<a href=3D"mailto=
:the.ultimate.koala@gmail.com" target=3D"_blank">the.ultimate.koala@gmail.c=
om</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Ville,<br><br>Sorry, I don&=
#39;t follow you. Which problem exactly is would constrained values solve a=
nd how? I have described at least half a dozen problems in this thread.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>The one you originally=
requested feedback for. The possible values for a player are a subset<br><=
/div><div>of the values for a square.<br></div></div><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 />
--047d7b47215e06ba6704e593ca86--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 14:47:32 -0700 (PDT)
Raw View
------=_Part_616_3762381.1378331252673
Content-Type: text/plain; charset=ISO-8859-1
Ville,
> The one you originally requested feedback for. The possible values for a
> player are a subset
> of the values for a square.
>
>
I see. Yet, going the other way around is more natural. optional<> lets me
reuse the board with any set of tokens, because it has the right semantics.
A board is "9 squares that MAY include a token".
enum class Token { CROSS, NOUGHT };
vector<optional<Token>> board(9);
The above is more natural for me to write than:
enum class SquareState { EMPTY, CROSS, NOUGHT };
vector<SquareState> board(9);
using token_t = bounded_enum<SquareState, SquareState::CROSS, SquareState::
NOUGHT>;
If I use the latter form, the rest of the code is littered with tests like board[i]
!= SquareState::EMPTY. With the former, these cases amount to a
bool(board[i]).
With the former, a variable of type Token is either Token::CROSS or
Token::NOUGHT, provided that I preclude myself from explicitly constructing
a Token from an int. A variable accommodating for emptiness is an
optional<Token>.
More, I can write this:
template<typename TokenType, size_t nbRows, size_t nbCols>
struct Board {
using square_t = optional<TokenType>;
vector<square_t> squares = vector<square_t>(nbRows * nbCols);
};
And emptiness is a concept that is implemented in the board, not in the
token type. Emptiness is then treated uniformly across all games that will
use the struct Board.
--
---
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_616_3762381.1378331252673
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div>Ville,<br> </div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></d=
iv><div>The one you originally requested feedback for. The possible values =
for a player are a subset<br></div><div>of the values for a square.<br></di=
v></div><br></div></div></blockquote><div><br>I see. Yet, going the other w=
ay around is more natural. optional<> lets me reuse the board with an=
y set of tokens, because it has the right semantics. A board is "9 squares =
that MAY include a token".<br><br><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Token=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> CROSS</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> NOUGHT </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br>vector</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">optional</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Token</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">>></span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> board</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">9<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></=
code></div><br>The above is more natural for me to write than:<br><br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">enum</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">SquareState</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> EMPTY</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
CROSS</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> NOUGHT </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br><br>vector</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">SquareState</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> board</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">9</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">using</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> token_t </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bo=
unded_enum</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
<</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Square=
State</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">SquareState</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">CROSS</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">SquareState</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">NOUGHT</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">>;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span></div></code></div><br>If I use the latter form, the res=
t of the code is littered with tests like <span style=3D"font-family: couri=
er new,monospace;">board[i] !=3D SquareState::EMPTY</span>. With the former=
, these cases amount to a <span style=3D"font-family: courier new,monospace=
;">bool(board[i])</span>.<br><br>With the former, a variable of type <span =
style=3D"font-family: courier new,monospace;">Token</span> is either <span =
style=3D"font-family: courier new,monospace;">Token::CROSS</span> or <span =
style=3D"font-family: courier new,monospace;">Token::NOUGHT</span>, provide=
d that I preclude myself from explicitly constructing a <span style=3D"font=
-family: courier new,monospace;">Token</span> from an <span style=3D"font-f=
amily: courier new,monospace;">int</span>. A variable accommodating for emp=
tiness is an <span style=3D"font-family: courier new,monospace;">optional&l=
t;Token></span>.<br><br>More, I can write this:<br><br><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">typename</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
class=3D"styled-by-prettify">TokenType</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> size_t nbRows</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> size_t nbCols</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">></span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Board<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> square_t </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> optional</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">TokenType</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">>;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> vector</span><span style=3D"color: #080;=
" class=3D"styled-by-prettify"><square_t></span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> squares </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> vector</span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify"><square_t></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">nbRows </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> nbCols</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></=
div></code></div><br>And emptiness is a concept that is implemented in the =
board, not in the token type. Emptiness is then treated uniformly across al=
l games that will use the <span style=3D"font-family: courier new,monospace=
;">struct Board</span>.<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_616_3762381.1378331252673--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 4 Sep 2013 17:02:13 -0500
Raw View
--001a11c1e99a8fba4404e595f7d5
Content-Type: text/plain; charset=ISO-8859-1
On 4 September 2013 16:47, <the.ultimate.koala@gmail.com> wrote:
>
> And emptiness is a concept that is implemented in the board, not in the
> token type. Emptiness is then treated uniformly across all games that will
> use the struct Board.
>
Is there *any *usage experience with this? If not, why not? Unlike
optional (which has to worry about object lifetime), it isn't like this is
particularly difficult to implement, even in C++03.
I'm not seeing a need to standardize such a thing.
--
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/.
--001a11c1e99a8fba4404e595f7d5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 4 September 2013 16:47, <span dir=3D"ltr"><<a href=
=3D"mailto:the.ultimate.koala@gmail.com" target=3D"_blank">the.ultimate.koa=
la@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>And emptiness is a=
concept that is implemented in the board, not in the token type. Emptiness=
is then treated uniformly across all games that will use the <span style=
=3D"font-family:courier new,monospace">struct Board</span>.<br>
</div></div></blockquote><div><br></div><div>Is there <i>any </i>usage expe=
rience with this?=A0 If not, why not?=A0 Unlike optional (which has to worr=
y about object lifetime), it isn't like this is particularly difficult =
to implement, even in C++03.<br>
<br>I'm not seeing a need to standardize such a thing.<br></div></div>-=
- <br>=A0Nevin ":-)" 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 />
--001a11c1e99a8fba4404e595f7d5--
.
Author: the.ultimate.koala@gmail.com
Date: Wed, 4 Sep 2013 15:15:07 -0700 (PDT)
Raw View
------=_Part_493_33334773.1378332907682
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, September 5, 2013 12:02:13 AM UTC+2, Nevin ":-)" Liber wrote:
>
> On 4 September 2013 16:47, <the.ultim...@gmail.com <javascript:>> wrote:
>
>>
>> And emptiness is a concept that is implemented in the board, not in the
>> token type. Emptiness is then treated uniformly across all games that will
>> use the struct Board.
>>
>
> Is there *any *usage experience with this? If not, why not? Unlike
> optional (which has to worry about object lifetime), it isn't like this is
> particularly difficult to implement, even in C++03.
>
>
Are you talking about the struct Board, or the degenerate<> template? Both
have usage experience, although I can testify only of mine. I was only
proposing the degenerate<> template.
I'm not seeing a need to standardize such a thing.
>
What "such a thing"? I'm sorry, with all that has been said in this thread,
I can't know clearly what "thing" you're referring to.
--
---
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_493_33334773.1378332907682
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, September 5, 2013 12:02:13 AM UTC+2, =
Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On 4 September 2013 16:47, <span dir=3D"ltr"><<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"WRA7aWBDAtQJ">the.ulti=
m...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>And emptiness is a=
concept that is implemented in the board, not in the token type. Emptiness=
is then treated uniformly across all games that will use the <span style=
=3D"font-family:courier new,monospace">struct Board</span>.<br>
</div></div></blockquote><div><br></div><div>Is there <i>any </i>usage expe=
rience with this? If not, why not? Unlike optional (which has t=
o worry about object lifetime), it isn't like this is particularly difficul=
t to implement, even in C++03.<br>
<br></div></div></div></div></blockquote><div><br>Are you talking about the=
<span style=3D"font-family: courier new,monospace;">struct Board</span>, o=
r the <span style=3D"font-family: courier new,monospace;">degenerate<>=
;</span> template? Both have usage experience, although I can testify only =
of mine. I was only proposing the <span style=3D"font-family: courier new,m=
onospace;">degenerate<></span> template.<br><br></div><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"><div><div class=3D"gmail_quo=
te"><div>I'm not seeing a need to standardize such a thing.<br></div></div>=
</div></div></blockquote><div><br>What "such a thing"? I'm sorry, with all =
that has been said in this thread, I can't know clearly what "thing" you're=
referring to.<br></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 />
------=_Part_493_33334773.1378332907682--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 4 Sep 2013 17:24:20 -0500
Raw View
--047d7bdc0934bbf91004e59646eb
Content-Type: text/plain; charset=ISO-8859-1
On 4 September 2013 17:15, <the.ultimate.koala@gmail.com> wrote:
>
>
> Are you talking about the struct Board, or the degenerate<> template?
>
C'mon. Did you really think I meant struct Board??
Fine. I see no need to standardize either Board or degenerate. The use
case is fairly minor.
--
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/.
--047d7bdc0934bbf91004e59646eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 4 September 2013 17:15, <span dir=3D"ltr"><<a href=
=3D"mailto:the.ultimate.koala@gmail.com" target=3D"_blank">the.ultimate.koa=
la@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><br>Are you talkin=
g about the <span style=3D"font-family:courier new,monospace">struct Board<=
/span>, or the <span style=3D"font-family:courier new,monospace">degenerate=
<></span> template?</div>
</div></blockquote><div><br></div><div>C'mon.=A0 Did you really think I=
meant struct Board??<br><br></div><div>Fine.=A0 I see no need to standardi=
ze either Board or degenerate.=A0 The use case is fairly minor.<br></div></=
div>
-- <br>=A0Nevin ":-)" 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 />
--047d7bdc0934bbf91004e59646eb--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 4 Sep 2013 18:15:31 -0700 (PDT)
Raw View
------=_Part_4936_32612205.1378343731645
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, September 5, 2013 6:24:20 AM UTC+8, Nevin ":-)" Liber wrote:
>
>
> Fine. I see no need to standardize either Board or degenerate. The use
> case is fairly minor.
>
As I mentioned, the constrained type template and the user-defined
specialization of std::optional thereupon can both be provided as a
user-defined library. Boost would probably be very receptive, and promptly
get it tested by real users.
You don't need concepts for the implementation; as mentioned you don't even
need C++11. It should be easy to upgrade to concepts, but initial
implementation without would probably be easier.
--
---
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_4936_32612205.1378343731645
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, September 5, 2013 6:24:20 AM UTC+8, N=
evin ":-)" Liber wrote:<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"><br><div class=3D"gmail_quote"><div>Fine. I see no need to =
standardize either Board or degenerate. The use case is fairly minor.=
<br></div></div></div></blockquote><div><br>As I mentioned, the constrained=
type template and the user-defined specialization of <span style=3D"font-f=
amily: courier new,monospace;">std::optional</span> thereupon can both be p=
rovided as a user-defined library. Boost would probably be very receptive, =
and promptly get it tested by real users.<br><br>You don't need concepts fo=
r the implementation; as mentioned you don't even need C++11. It should be =
easy to upgrade to concepts, but initial implementation without would proba=
bly be easier.<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_4936_32612205.1378343731645--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 4 Sep 2013 18:17:05 -0700 (PDT)
Raw View
------=_Part_4960_17262633.1378343825041
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, September 5, 2013 9:15:31 AM UTC+8, David Krauss wrote:
>
> the constrained type template
>
> sorry, "constrained value template". And it would probably be a good idea
to look for such a library in preexisting form.
--
---
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_4960_17262633.1378343825041
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, September 5, 2013 9:15:31 AM UTC+8, D=
avid Krauss 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"=
ltr">the constrained type template<div><br></div></div></blockquote><div>so=
rry, "constrained value template". And it would probably be a good idea to =
look for such a library in preexisting form.<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_4960_17262633.1378343825041--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 5 Sep 2013 17:03:05 -0400
Raw View
--001a1133eb74924c8104e5a93ff3
Content-Type: text/plain; charset=ISO-8859-1
Just some comments on the entire thread:
- the "squeeze every last ounce" part of me likes the idea of an optional
that steals an unused value as the "disengaged" state (and I've toyed with
the idea in the past).
We do this all the time at hock with ints - returning -1 or 0, etc when we
want to return "can't give you a real value". So instead of a #define or
const int BAD_FOO_VALUE, using the language of optional<> might make some
sense. Or a separate class that has the same/similar interface as
optional. (Look at the upcoming Boost.Expected as another
similar-to-but-not-exacly-optional class).
- your original problem might just as well be solved by deriving enums from
enums, or an enum constructor:
enum token { CROSS, NOUGHT };
enum SquareState
{
CROSS, NOUGHT, EMPTY;
SquareState(token t)
{
* this = t;
}
};
I'm not saying we can derive enums from enums or give them constructors, but
- it has been mentioned more than once in the past
- you could make your own enum-like classes that had constructors and/or
derivation
Tony
--
---
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/.
--001a1133eb74924c8104e5a93ff3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra">Just some comments on the e=
ntire thread:<br><br></div><div class=3D"gmail_extra">- the "squeeze e=
very last ounce" part of me likes the idea of an optional that steals =
an unused value as the "disengaged" state (and I've toyed wit=
h the idea in the past).<br>
We do this all the time at hock with ints - returning -1 or 0, etc when we =
want to return "can't give you a real value". So instead of a=
#define or const int BAD_FOO_VALUE, using the language of optional<>=
might make some sense.=A0 Or a separate class that has the same/similar in=
terface as optional.=A0 (Look at the upcoming Boost.Expected as another sim=
ilar-to-but-not-exacly-optional class).<br>
<br></div><div class=3D"gmail_extra">- your original problem might just as =
well be solved by deriving enums from enums, or an enum constructor:<br><br=
></div><div class=3D"gmail_extra">enum token { CROSS, NOUGHT };<br><br></di=
v>
<div class=3D"gmail_extra">enum SquareState<br>{<br></div><div class=3D"gma=
il_extra">=A0=A0 CROSS, NOUGHT, EMPTY;<br><br></div><div class=3D"gmail_ext=
ra">=A0=A0 SquareState(token t)<br>=A0=A0 {<br></div><div class=3D"gmail_ex=
tra">=A0=A0=A0=A0=A0 * this =3D t;<br>
=A0=A0 }<br>};<br><br></div><div class=3D"gmail_extra">I'm not saying w=
e can derive enums from enums or give them constructors, but<br></div><div =
class=3D"gmail_extra">- it has been mentioned more than once in the past<br=
></div>
<div class=3D"gmail_extra">- you could make your own enum-like classes that=
had constructors and/or derivation<br><br></div><div class=3D"gmail_extra"=
>Tony<br><br></div><div class=3D"gmail_extra"><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 />
--001a1133eb74924c8104e5a93ff3--
.