Topic: Any library proposal (Revision 2) draft available
Author: Beman Dawes <bdawes@acm.org>
Date: Wed, 9 Jan 2013 11:10:00 -0500
Raw View
A draft of the Any library proposal (Revision 2) is available.
See http://beman.github.com/dot16/any-proposal.html
As always, comments and corrections welcome!
--Beman
--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 09 Jan 2013 18:55:57 +0100
Raw View
This is a multi-part message in MIME format.
--------------000504040400080302010004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/01/13 17:10, Beman Dawes a =E9crit :
> A draft of the Any library proposal (Revision 2) is available.
>
> See http://beman.github.com/dot16/any-proposal.html
>
> As always, comments and corrections welcome!
>
> --Beman
>
Hi
there are yet two uses of |"::tbd" in the text.|
Shouldn't the overload of any_cast for pointers to any return a pointer=20
to ValueType in
template<typename ValueType>
ValueType any_cast(const any* operand) noexcept;
template<typename ValueType>
ValueType any_cast(any* operand) noexcept;
If any_cast doesn't modify its argument, why we do need the non-const=20
overload?
template<typename ValueType>
ValueType any_cast(any& operand);
template<typename ValueType>
ValueType any_cast(any* operand) noexcept;
Sorry if this has already been discussed. Is there a reason to prefer=20
the use of any_cast to the explicit conversion?
template<typename ValueType>
ValueType any_cast(const any& operand);
class any
{
public:
...
template<typename ValueType>
operator ValueType() const;
...
};
Vicente
--=20
--------------000504040400080302010004
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 09/01/13 17:10, Beman Dawes a
écrit :<br>
</div>
<blockquote
cite="mid:CAAygHNM6V5OKdieOz+0n03NG7fdDeVOXkSNMWe0nNJfzpYc2Aw@mail.gmail.com"
type="cite">
<pre wrap="">A draft of the Any library proposal (Revision 2) is available.
See <a class="moz-txt-link-freetext" href="http://beman.github.com/dot16/any-proposal.html">http://beman.github.com/dot16/any-proposal.html</a>
As always, comments and corrections welcome!
--Beman
</pre>
</blockquote>
Hi <br>
<br>
there are yet two uses of <code>"::tbd" in the text.</code><br>
<br>
<br>
Shouldn't the overload of any_cast for pointers to any return a
pointer to ValueType
in <br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre> template<typename ValueType>
ValueType any_cast(const any* operand) noexcept;
template<typename ValueType>
ValueType any_cast(any* operand) noexcept;</pre>
<br>
If any_cast doesn't modify its argument, why we do need the
non-const overload?<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre> template<typename ValueType>
ValueType any_cast(any& operand);</pre>
<pre> template<typename ValueType>
ValueType any_cast(any* operand) noexcept;</pre>
Sorry if this has already been discussed. Is there a reason to
prefer the use of any_cast to the explicit conversion?<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre> template<typename ValueType>
ValueType any_cast(const any& operand);
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> class any
{
public:<pre></pre> ...
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> template<typename ValueType>
operator ValueType() const;<pre></pre> ...
</pre>
};<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------000504040400080302010004--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 09 Jan 2013 21:39:38 +0100
Raw View
This is a multi-part message in MIME format.
--------------070308070503050009050508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/01/13 18:55, Vicente J. Botet Escriba a =E9crit :
> Le 09/01/13 17:10, Beman Dawes a =E9crit :
>> A draft of the Any library proposal (Revision 2) is available.
>>
>> Seehttp://beman.github.com/dot16/any-proposal.html
>>
>> As always, comments and corrections welcome!
>>
>> --Beman
>>
> Hi
>
> there are yet two uses of |"::tbd" in the text.|
Well three.
using|std::tbd||::any_cast|;
using std::tbd::any;
catch(const|std::tbd::bad_any_cast|&)
In order to know if the stored type is a given type without exception I=20
see two possibilities:
* using type()
if (aAny.type() =3D=3D typeid(VT)) ...
* using any_cast
if (any_cast<VT*>(&aAny)) ...
What are the advantages of one over the other?
What about a is() member function?
template <typename ValueType>
bool is() const noexcept;
So that the user can just do
if (aAny.is<VT>()) ...
I'm wondering if the any_cast<VT*> function shouldn't return a const=20
pointer, or is the intent to be able to modify the any value using this=20
pointer?
At the end I don't know even if it is a good idea to provide this=20
overload at all. E.g
int i =3D 0;
std::string str{"hehe"};
std::any a =3D i;
const int * ip =3D any_cast<int>(a);
a =3D str;
// Access to ip here will result on an unexpected value (if not invalid)
As std::any is used to cloak any value type, it seems to me that=20
std::any should not provide any function that get access to the address=20
of stored value.
Vicente
--=20
--------------070308070503050009050508
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 09/01/13 18:55, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:50EDAF2D.1080904@wanadoo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 09/01/13 17:10, Beman Dawes a
écrit :<br>
</div>
<blockquote
cite="mid:CAAygHNM6V5OKdieOz+0n03NG7fdDeVOXkSNMWe0nNJfzpYc2Aw@mail.gmail.com"
type="cite">
<pre wrap="">A draft of the Any library proposal (Revision 2) is available.
See <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://beman.github.com/dot16/any-proposal.html">http://beman.github.com/dot16/any-proposal.html</a>
As always, comments and corrections welcome!
--Beman
</pre>
</blockquote>
Hi <br>
<br>
there are yet two uses of <code>"::tbd" in the text.</code><br>
</blockquote>
Well three.<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre class="programlisting"><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">using <code>std::tbd</code><code class="computeroutput">::any_cast</code>;
using std::tbd::any;<pre class="programlisting"></pre> catch(const <code class="computeroutput">std::tbd::bad_any_cast</code>&)</pre>
<br>
<br>
In order to know if the stored type is a given type without
exception I see two possibilities:<br>
* using type() <br>
<br>
if (aAny.type() == typeid(VT)) ...<br>
<br>
* using any_cast<br>
<br>
if (any_cast<VT*>(&aAny)) ...<br>
<br>
What are the advantages of one over the other?<br>
<br>
What about a is() member function?<br>
<br>
template <typename ValueType><br>
bool is() const noexcept;<br>
<br>
So that the user can just do <br>
<br>
if (aAny.is<VT>()) ...<br>
<br>
<br>
I'm wondering if the any_cast<VT*> function shouldn't return a
const pointer, or is the intent to be able to modify the any value
using this pointer?<br>
<br>
At the end I don't know even if it is a good idea to provide this
overload at all. E.g<br>
<br>
int i = 0;<br>
std::string str{"hehe"};<br>
std::any a = i;<br>
const int * ip = any_cast<int>(a);<br>
a = str;<br>
<br>
// Access to ip here will result on an unexpected value (if not
invalid)<br>
<br>
As std::any is used to cloak any value type, it seems to me that
std::any should not provide any function that get access to the
address of stored value.<br>
<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------070308070503050009050508--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 9 Jan 2013 14:51:50 -0600
Raw View
--f46d0401fe7deae56d04d2e13d9b
Content-Type: text/plain; charset=ISO-8859-1
On 9 January 2013 14:39, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr>wrote:
> I'm wondering if the any_cast<VT*> function shouldn't return a const
> pointer, or is the intent to be able to modify the any value using this
> pointer?
>
Sure, why not?
> At the end I don't know even if it is a good idea to provide this overload
> at all. E.g
>
> int i = 0;
> std::string str{"hehe"};
> std::any a = i;
> const int * ip = any_cast<int>(a);
> a = str;
>
> // Access to ip here will result on an unexpected value (if not invalid)
>
How does that differ from many of the other library components?
vector<int> vi(1);
int* ip = vi.data();
vi = vector<int>(1);
// Access to ip here will result on an unexpected value (if not invalid)
>
> As std::any is used to cloak any value type, it seems to me that std::any
> should not provide any function that get access to the address of stored
> value.
>
That makes it *much* less useful; I don't want to have to pay a double
copying cost just to modify something or call a non-const member function
on an object an any is holding.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--f46d0401fe7deae56d04d2e13d9b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 9 January 2013 14:39, Vicente J. Botet Escriba <span dir=3D"ltr"><<a =
href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet@wa=
nadoo.fr</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">I'm wondering if the any_ca=
st<VT*> function shouldn't return a
const pointer, or is the intent to be able to modify the any value
using this pointer?<br></div></blockquote><div><br>Sure, why not?<br>=
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" text=
=3D"#000000">
At the end I don't know even if it is a good idea to provide this
overload at all. E.g<br>
<br>
=A0 int i =3D 0;<br>
=A0 std::string str{"hehe"};<br>
=A0 std::any a =3D i;<br>
=A0 const int * ip =3D any_cast<int>(a);<br>
=A0 a =3D str;<br>
<br>
=A0 // Access to ip here will result on an unexpected value (if not
invalid)<br></div></blockquote><div><br>How does that differ from many =
of the other library components?<br><br>vector<int> vi(1);<br>int* ip=
=3D vi.data();<br>vi =3D vector<int>(1);<br> // Access to ip here wi=
ll result on an unexpected value (if not
invalid)<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FF=
FFFF" text=3D"#000000">
<br>
As std::any is used to cloak any value type, it seems to me that
std::any should not provide any function that get access to the
address of stored value.<span class=3D"HOEnZb"><font color=3D"#888888">=
<br></font></span></div></blockquote><div><br>That makes it *much* less use=
ful; I don't want to have to pay a double copying cost just to modify s=
omething or call a non-const member function on an object an any is holding=
..<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
<p></p>
-- <br />
<br />
<br />
<br />
--f46d0401fe7deae56d04d2e13d9b--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 9 Jan 2013 23:05:15 +0200
Raw View
On 9 January 2013 22:51, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 9 January 2013 14:39, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>
> wrote:
>> I'm wondering if the any_cast<VT*> function shouldn't return a const
>> pointer, or is the intent to be able to modify the any value using this
>> pointer?
> Sure, why not?
Yep. And this same question applies to the rest of the "safety"
comments: have boost::any users ever
complained about these facilities? We seem to be pitting years of
actual practical use experience
against unsubstantiated safety concerns, and I think I'll pick the
less-safe-and-more-useful std::any as
a winner in that contest. ;)
--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 09 Jan 2013 22:32:43 +0100
Raw View
This is a multi-part message in MIME format.
--------------030703040201060001010300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/01/13 21:51, Nevin Liber a =E9crit :
> On 9 January 2013 14:39, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
> I'm wondering if the any_cast<VT*> function shouldn't return a
> const pointer, or is the intent to be able to modify the any value
> using this pointer?
>
>
> Sure, why not?
>
> At the end I don't know even if it is a good idea to provide this
> overload at all. E.g
>
> int i =3D 0;
> std::string str{"hehe"};
> std::any a =3D i;
> const int * ip =3D any_cast<int>(a);
> a =3D str;
>
> // Access to ip here will result on an unexpected value (if not
> invalid)
>
>
> How does that differ from many of the other library components?
>
> vector<int> vi(1);
> int* ip =3D vi.data();
> vi =3D vector<int>(1);
> // Access to ip here will result on an unexpected value (if not invalid)
>
>
> As std::any is used to cloak any value type, it seems to me that
> std::any should not provide any function that get access to the
> address of stored value.
>
>
> That makes it *much* less useful; I don't want to have to pay a double=20
> copying cost just to modify something or call a non-const member=20
> function on an object an any is holding.
>
Oh, I've forgotten the performance point. Beman, I don't know if it is=20
worth adding this to the rationale.
Vicente
--=20
--------------030703040201060001010300
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 09/01/13 21:51, Nevin Liber a
écrit :<br>
</div>
<blockquote
cite="mid:CAGg_6+M-oX2Y==Nv2hQAisbkXMbUsUxvuZ87w_hRoLjJQG2mgQ@mail.gmail.com"
type="cite">On 9 January 2013 14:39, Vicente J. Botet Escriba <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:vicente.botet@wanadoo.fr" target="_blank">vicente.botet@wanadoo.fr</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">I'm wondering if the
any_cast<VT*> function shouldn't return a const
pointer, or is the intent to be able to modify the any value
using this pointer?<br>
</div>
</blockquote>
<div><br>
Sure, why not?<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> At the end I don't know
even if it is a good idea to provide this overload at all.
E.g<br>
<br>
int i = 0;<br>
std::string str{"hehe"};<br>
std::any a = i;<br>
const int * ip = any_cast<int>(a);<br>
a = str;<br>
<br>
// Access to ip here will result on an unexpected value
(if not invalid)<br>
</div>
</blockquote>
<div><br>
How does that differ from many of the other library
components?<br>
<br>
vector<int> vi(1);<br>
int* ip = vi.data();<br>
vi = vector<int>(1);<br>
// Access to ip here will result on an unexpected value (if
not invalid)<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
As std::any is used to cloak any value type, it seems to me
that std::any should not provide any function that get
access to the address of stored value.<span class="HOEnZb"><font
color="#888888"><br>
</font></span></div>
</blockquote>
<div><br>
That makes it *much* less useful; I don't want to have to pay
a double copying cost just to modify something or call a
non-const member function on an object an any is holding.<br>
</div>
</div>
<br>
</blockquote>
Oh, I've forgotten the performance point. Beman, I don't know if it
is worth adding this to the rationale.<br>
<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------030703040201060001010300--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 09 Jan 2013 22:37:21 +0100
Raw View
This is a multi-part message in MIME format.
--------------030609010904020502000700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/01/13 18:55, Vicente J. Botet Escriba a =E9crit :
> Le 09/01/13 17:10, Beman Dawes a =E9crit :
>> A draft of the Any library proposal (Revision 2) is available.
>>
>> Seehttp://beman.github.com/dot16/any-proposal.html
>>
>> As always, comments and corrections welcome!
>>
>> --Beman
>>
>
>
> Shouldn't the overload of any_cast for pointers to any return a=20
> pointer to ValueType in
>
> template<typename ValueType>
> ValueType any_cast(const any* operand) noexcept;
>
> template<typename ValueType>
> ValueType any_cast(any* operand) noexcept;
>
> If any_cast doesn't modify its argument, why we do need the non-const=20
> overload?
>
> template<typename ValueType>
> ValueType any_cast(any& operand);
> template<typename ValueType>
> ValueType any_cast(any* operand) noexcept;
>
Please forget these comments. I believe I understand the why now.
Vicente
--=20
--------------030609010904020502000700
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 09/01/13 18:55, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:50EDAF2D.1080904@wanadoo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 09/01/13 17:10, Beman Dawes a
écrit :<br>
</div>
<blockquote
cite="mid:CAAygHNM6V5OKdieOz+0n03NG7fdDeVOXkSNMWe0nNJfzpYc2Aw@mail.gmail.com"
type="cite">
<pre wrap="">A draft of the Any library proposal (Revision 2) is available.
See <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://beman.github.com/dot16/any-proposal.html">http://beman.github.com/dot16/any-proposal.html</a>
As always, comments and corrections welcome!
--Beman
</pre>
</blockquote>
<br>
<br>
Shouldn't the overload of any_cast for pointers to any return a
pointer to ValueType in <br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre> template<typename ValueType>
ValueType any_cast(const any* operand) noexcept;
template<typename ValueType>
ValueType any_cast(any* operand) noexcept;</pre>
<br>
If any_cast doesn't modify its argument, why we do need the
non-const overload?<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre> template<typename ValueType>
ValueType any_cast(any& operand);</pre>
<pre> template<typename ValueType>
ValueType any_cast(any* operand) noexcept;</pre>
<br>
</blockquote>
Please forget these comments. I believe I understand the why now. <br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------030609010904020502000700--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Wed, 9 Jan 2013 14:34:11 -0800 (PST)
Raw View
------=_Part_3099_24429798.1357770851928
Content-Type: text/plain; charset=ISO-8859-1
From the proposal:
template<typename ValueType>
ValueType any_cast(const any* operand) noexcept;
template<typename ValueType>
ValueType any_cast(any* operand) noexcept;
*Returns: *A pointer to the value contained by operand if successful,
otherwise nullptr. The returned pointer is const qualified for the
signature with a const argument.
I understand that the idea here is to call any_cast with a T* template
argument. Like any_cast<int*>(a) when a is a pointer to any that holds an
int. However, the name ValueType doesn't really reflect that paradigm, as
in every other context ValueType is used to denote the type that an any
object holds. I would rename the template argument to something like
PtrToValueType, or at least anything other than ValueType itself.
--
------=_Part_3099_24429798.1357770851928
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
From the proposal:<div><br></div><blockquote style=3D"margin: 0 0 0 40px; b=
order: none; padding: 0px;"><div><pre style=3D"background-color: rgb(215, 2=
38, 255); color: rgb(0, 0, 0);">template<typename ValueType></pre></d=
iv><div><pre style=3D"background-color: rgb(215, 238, 255); color: rgb(0, 0=
, 0);"> ValueType any_cast(const any* operand) noexcept;</pre></div><div><=
pre style=3D"background-color: rgb(215, 238, 255); color: rgb(0, 0, 0);">te=
mplate<typename ValueType></pre></div><div><pre style=3D"background-c=
olor: rgb(215, 238, 255); color: rgb(0, 0, 0);"> ValueType any_cast(any* o=
perand) noexcept;</pre></div><div><blockquote style=3D"color: rgb(0, 0, 0);=
font-family: sans-serif; font-size: medium;"><p><i>Returns: </i>A poi=
nter to the value contained by <code>operand</code> if successful=
, otherwise <code>nullptr</code>. The returned pointer is <code>c=
onst</code> qualified for the signature with a <code>const</code>=
argument.</p></blockquote></div></blockquote><div>I understand that t=
he idea here is to call any_cast with a <font face=3D"courier new, monospac=
e">T*</font> template argument. Like <font face=3D"courier new, monospace">=
any_cast<int*>(a)</font> when <font face=3D"courier new, monospace">a=
</font> is a pointer to <font face=3D"courier new, monospace">any</font> th=
at holds an <font face=3D"courier new, monospace">int</font>. However, the =
name <font face=3D"courier new, monospace">ValueType</font> doesn't really =
reflect that paradigm, as in every other context <font face=3D"courier new,=
monospace">ValueType</font> is used to denote the type that an any object =
holds. I would rename the template argument to something like <font face=3D=
"courier new, monospace">PtrToValueType</font>, or at least anything other =
than <font face=3D"courier new, monospace">ValueType</font> itself.</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_3099_24429798.1357770851928--
.
Author: Beman Dawes <bdawes@acm.org>
Date: Thu, 10 Jan 2013 08:12:25 -0500
Raw View
On Wed, Jan 9, 2013 at 4:37 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 09/01/13 18:55, Vicente J. Botet Escriba a =E9crit :
>
> Le 09/01/13 17:10, Beman Dawes a =E9crit :
>
> A draft of the Any library proposal (Revision 2) is available.
>
> See http://beman.github.com/dot16/any-proposal.html
>
> As always, comments and corrections welcome!
>
> --Beman
>
>
>
> Shouldn't the overload of any_cast for pointers to any return a pointer t=
o
> ValueType in
>
> template<typename ValueType>
> ValueType any_cast(const any* operand) noexcept;
>
> template<typename ValueType>
> ValueType any_cast(any* operand) noexcept;
>
>
> If any_cast doesn't modify its argument, why we do need the non-const
> overload?
>
> template<typename ValueType>
> ValueType any_cast(any& operand);
>
> template<typename ValueType>
> ValueType any_cast(any* operand) noexcept;
>
>
> Please forget these comments. I believe I understand the why now.
On the contrary, I think your comments indicate a need to clarify the
spec at least by adding examples.
Thanks,
--Beman
--=20
.
Author: Beman Dawes <bdawes@acm.org>
Date: Thu, 10 Jan 2013 08:16:29 -0500
Raw View
On Wed, Jan 9, 2013 at 4:32 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 09/01/13 21:51, Nevin Liber a =E9crit :
>
> On 9 January 2013 14:39, Vicente J. Botet Escriba <vicente.botet@wanadoo.=
fr>
> wrote:
>>
>> I'm wondering if the any_cast<VT*> function shouldn't return a const
>> pointer, or is the intent to be able to modify the any value using this
>> pointer?
>
>
> Sure, why not?
>
>>
>> At the end I don't know even if it is a good idea to provide this overlo=
ad
>> at all. E.g
>>
>> int i =3D 0;
>> std::string str{"hehe"};
>> std::any a =3D i;
>> const int * ip =3D any_cast<int>(a);
>> a =3D str;
>>
>> // Access to ip here will result on an unexpected value (if not invali=
d)
>
>
> How does that differ from many of the other library components?
>
> vector<int> vi(1);
> int* ip =3D vi.data();
> vi =3D vector<int>(1);
> // Access to ip here will result on an unexpected value (if not invalid)
>
>>
>>
>> As std::any is used to cloak any value type, it seems to me that std::an=
y
>> should not provide any function that get access to the address of stored
>> value.
>
>
> That makes it *much* less useful; I don't want to have to pay a double
> copying cost just to modify something or call a non-const member function=
on
> an object an any is holding.
>
> Oh, I've forgotten the performance point. Beman, I don't know if it is wo=
rth
> adding this to the rationale.
Performance has always been important, and has been discussed at
length. But that is true of so many standard library components. Not
sure if any merits special mention of performance.
--Beman
--=20
.
Author: Beman Dawes <bdawes@acm.org>
Date: Thu, 10 Jan 2013 08:22:11 -0500
Raw View
On Wed, Jan 9, 2013 at 5:34 PM, Sylvester Hesp <s.hesp@oisyn.nl> wrote:
> From the proposal:
>
> template<typename ValueType>
>
> ValueType any_cast(const any* operand) noexcept;
>
> template<typename ValueType>
>
> ValueType any_cast(any* operand) noexcept;
>
> Returns: A pointer to the value contained by operand if successful,
> otherwise nullptr. The returned pointer is const qualified for the signature
> with a const argument.
>
> I understand that the idea here is to call any_cast with a T* template
> argument. Like any_cast<int*>(a) when a is a pointer to any that holds an
> int. However, the name ValueType doesn't really reflect that paradigm, as in
> every other context ValueType is used to denote the type that an any object
> holds. I would rename the template argument to something like
> PtrToValueType, or at least anything other than ValueType itself.
Changing the name of the template parameter was already on my list of
changes to clarify the any_cast pointer flavor, although I hadn't
given any thought to the exact name. PtrToValueType is much clearer
than ValueType, but ValueTypePtr also comes to mind.
Thanks,
--Beman
--
.
Author: Chris Jefferson <chris@bubblescope.net>
Date: Thu, 10 Jan 2013 13:28:00 +0000
Raw View
On 09/01/13 16:10, Beman Dawes wrote:
> A draft of the Any library proposal (Revision 2) is available.
>
> See http://beman.github.com/dot16/any-proposal.html
>
> As always, comments and corrections welcome!
>
> --Beman
>
I don't see any particular reason to require ValueType is
CopyConstructable. Like with (for example) vector, you need
CopyConstructable when you copy into the any, copy the any itself, or
copy back out. But when moving in, moving the any, and moving back out,
it seems fine to only require MoveConstructable.
I don't really see any explanation of when a bad_any_cast is thrown. You
say 'unsuccessful'. I assume the intention is that I have to ask for
exactly the type I put in, I can't put in an int and get a long back out?
While this is getting picky, it might be worth thinking about what, if
anything, happens if someone puts in a const or volatile (if you say you
have to get the exact same type back out, then this solves that), or
tries to an any_cast with 'const int', or 'int&', when they put in an
int. I assume that const gets ignored, but volatile probably doesn't.
While this might be a bit fiddly in the wording however, I don't think
it's any kind of serious issue.
Chris
--
.
Author: Paul Smith <pl.smith.mail@gmail.com>
Date: Thu, 10 Jan 2013 05:56:20 -0800 (PST)
Raw View
------=_Part_180_8017674.1357826180957
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, January 9, 2013 6:10:00 PM UTC+2, Beman Dawes wrote:
>
> A draft of the Any library proposal (Revision 2) is available.
>
> See http://beman.github.com/dot16/any-proposal.html
>
> As always, comments and corrections welcome!
>
> --Beman
>
A few notes:
* Why do the constructors and assignment operators doesn't take a reference
(i.e. ValueType&&)? I guess it has something to do with Sean Parent's
experiments mentioned in the acknowledgements sections, but that's not very
informative. Also, why is the requirement of ValueType to be only
CopyConstructible and not also MoveConstructible (which is met even if it
doesn't have a move constructor). Even if we take parameters by-value, it's
still better to move from them (when possible) than to copy from them.
* Shouldn't there be a requirement in the pointer versions of 'any_cast'
that 'ValueType' is a pointer?
* It's not clear what it takes for an 'any_cast' to succeed. What are the
exact conditions?
* How about an 'emplace' member?
template <typename T, typename... Args>
any& emplace(Args&&... args) &;
template <typename T, typename... Args>
any&& emplace(Args&&... args) &&;
Now we can do:
any a;
a.emplace<type_with_no_cheap_move>(x, y, z);
And also pseudo emplace-initialize:
any a = any().emplace<type_with_no_cheap_move>(x, y, z);
This has another advantage: Currently, it's tricky to store an 'any' inside
an 'any' (i.e. a recursive 'any'). This might sound useless, but in a
generic context you might want to store an arbitrary object type inside an
'any'. This type can happen to be an 'any':
any a;
template <typename T>
void store(T&& x) {
a.emplace<T>(std::forward<T&&>(x)); // same semantics for all 'T', even
'T = any'
}
I can see that a few more people have posted while I'm writing, so
apologies if I'm repeating anyone.
--
Paul Smith
--
------=_Part_180_8017674.1357826180957
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, January 9, 2013 6:10:00 PM UTC+2, Beman Dawes wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">A draft of the Any library prop=
osal (Revision 2) is available.
<br>
<br>See <a href=3D"http://beman.github.com/dot16/any-proposal.html" target=
=3D"_blank">http://beman.github.com/dot16/<wbr>any-proposal.html</a>
<br>
<br>As always, comments and corrections welcome!
<br>
<br>--Beman
<br></blockquote><div><br></div><div> A few notes:</div><div><br></div=
><div>* Why do the constructors and assignment operators doesn't take a ref=
erence (i.e. ValueType&&)? I guess it has something to do with Sean=
Parent's experiments mentioned in the acknowledgements sections, but that'=
s not very informative. Also, why is the requirement of ValueType to be onl=
y CopyConstructible and not also MoveConstructible (which is met even if it=
doesn't have a move constructor). Even if we take parameters by-value, it'=
s still better to move from them (when possible) than to copy from them.</d=
iv><div><br></div><div>* Shouldn't there be a requirement in the pointer ve=
rsions of 'any_cast' that 'ValueType' is a pointer?</div><div><br></div><di=
v>* It's not clear what it takes for an 'any_cast' to succeed. What are the=
exact conditions?</div><div><br></div><div>* How about an 'emplace' member=
?</div><div><br></div><div> template <typename T, typename... Args=
></div><div> any& emplace(Args&&... args) &;</div>=
<div><br></div><div><div> template <typename T, typename... Args&g=
t;</div><div> any&& emplace(Args&&... args) &&=
;;</div></div><div><br></div><div>Now we can do:</div><div><br></div><div>&=
nbsp; any a;</div><div> a.emplace<type_with_no_cheap_move>(x, y=
, z);</div><div><br></div><div>And also pseudo emplace-initialize:</div><di=
v><br></div><div> any a =3D any().emplace<type_with_no_cheap_=
move>(x, y, z);</div><div><br></div><div>This has another advantage: Cur=
rently, it's tricky to store an 'any' inside an 'any' (i.e. a recursive 'an=
y'). This might sound useless, but in a generic context you might want to s=
tore an arbitrary object type inside an 'any'. This type can happen to be a=
n 'any':</div><div><br></div><div> any a;</div><div><br></div><div>&n=
bsp; template <typename T></div><div> void store(T&& x)=
{</div><div> a.emplace<T>(std::forward<T&&&g=
t;(x)); // same semantics for all 'T', even 'T =3D any'</div><div> }<=
/div><div><br></div><div><br></div><div>I can see that a few more people ha=
ve posted while I'm writing, so apologies if I'm repeating anyone.</div><di=
v><br></div><div>--</div><div>Paul Smith</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_180_8017674.1357826180957--
.
Author: Paul Smith <pl.smith.mail@gmail.com>
Date: Thu, 10 Jan 2013 16:12:12 +0200
Raw View
On Thu, Jan 10, 2013 at 3:56 PM, Paul Smith <pl.smith.mail@gmail.com> wrote:
>
>
> On Wednesday, January 9, 2013 6:10:00 PM UTC+2, Beman Dawes wrote:
>
> A few notes:
>
> [snip]
Another quickie:
For the pointer 'any_cast's:
Returns: A pointer to the value contained by operand if successful,
otherwise <del>nullptr</del><ins>a null pointer value</ins>. The
returned pointer is const qualified for the signature with a const
argument.
'nullptr' is not a pointer.
--
Paul Smith
--
.
Author: Nevin Liber <nliber@gmail.com>
Date: Thu, 10 Jan 2013 08:12:28 -0600
Raw View
On Jan 10, 2013, at 7:28 AM, Chris Jefferson <chris@bubblescope.net> wrote:
> I don't see any particular reason to require ValueType is CopyConstructable.
The requirement is there because any has to have a copy constructor no
matter what type is stored in it, unless you want to change its
semantics to throw on copying when holding non-copyable types.
--
.
Author: Nevin Liber <nliber@gmail.com>
Date: Thu, 10 Jan 2013 08:16:46 -0600
Raw View
On Jan 10, 2013, at 7:56 AM, Paul Smith <pl.smith.mail@gmail.com> wrote:
> This has another advantage: Currently, it's tricky to store an 'any' inside an 'any' (i.e. a recursive 'any'). This might sound useless, but in a generic context you might want to store an arbitrary object type inside an 'any'.
We've had many years of experience with Boost.Any, and I don't
remember anyone asking for this.
--
.
Author: Chris Jefferson <chris@bubblescope.net>
Date: Thu, 10 Jan 2013 14:19:32 +0000
Raw View
On 10/01/13 14:12, Nevin Liber wrote:
> On Jan 10, 2013, at 7:28 AM, Chris Jefferson <chris@bubblescope.net> wrote:
>
>> I don't see any particular reason to require ValueType is CopyConstructable.
> The requirement is there because any has to have a copy constructor no
> matter what type is stored in it, unless you want to change its
> semantics to throw on copying when holding non-copyable types.
>
Oh, of course, thanks. Sorry.
Chris
--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 10 Jan 2013 16:23:05 +0200
Raw View
On 10 January 2013 16:16, Nevin Liber <nliber@gmail.com> wrote:
> On Jan 10, 2013, at 7:56 AM, Paul Smith <pl.smith.mail@gmail.com> wrote:
>> This has another advantage: Currently, it's tricky to store an 'any' inside an 'any' (i.e. a recursive 'any'). This might sound useless, but in a generic context you might want to store an arbitrary object type inside an 'any'.
> We've had many years of experience with Boost.Any, and I don't
> remember anyone asking for this.
We didn't have perfect forwarding during those years, so perhaps it's
worth considering?
I'm not referring to the ability to store any inside any, but the
ability to emplace.
--
.
Author: Paul Smith <pl.smith.mail@gmail.com>
Date: Thu, 10 Jan 2013 16:39:03 +0200
Raw View
On Thu, Jan 10, 2013 at 4:16 PM, Nevin Liber <nliber@gmail.com> wrote:
> On Jan 10, 2013, at 7:56 AM, Paul Smith <pl.smith.mail@gmail.com> wrote:
>
>> This has another advantage: Currently, it's tricky to store an 'any' inside an 'any' (i.e. a recursive 'any'). This might sound useless, but in a generic context you might want to store an arbitrary object type inside an 'any'.
>
> We've had many years of experience with Boost.Any, and I don't
> remember anyone asking for this.
I admit that this is mainly a made up case. It feels logical: 'any'
can store any object; 'any' is an object; 'any' can store an 'any'. In
the example I gave, my intention was that the containing 'any' ('a' in
the example) is hidden from the user, so he might not even know that
his object is stored inside an 'any'. Anyway, this is just something
you get for free with 'emplace', and I don't see the harm in it.
--
Paul Smith
--
.
Author: Beman Dawes <bdawes@acm.org>
Date: Thu, 10 Jan 2013 09:58:57 -0500
Raw View
On Thu, Jan 10, 2013 at 8:28 AM, Chris Jefferson <chris@bubblescope.net> wr=
ote:
> On 09/01/13 16:10, Beman Dawes wrote:
>>
>> A draft of the Any library proposal (Revision 2) is available.
>>
>> See http://beman.github.com/dot16/any-proposal.html
>>
>> As always, comments and corrections welcome!
>>
>> --Beman
>>
> I don't see any particular reason to require ValueType is CopyConstructab=
le.
> Like with (for example) vector, you need CopyConstructable when you copy
> into the any, copy the any itself, or copy back out. But when moving in,
> moving the any, and moving back out, it seems fine to only require
> MoveConstructable.
I'm going to leave that question for Daniel Kr=FCgler. He was the one
who suggested the CopyConstructible wording, and he is the oracle I
depend on for such questions:-)
> I don't really see any explanation of when a bad_any_cast is thrown. You =
say
> 'unsuccessful'. I assume the intention is that I have to ask for exactly =
the
> type I put in, I can't put in an int and get a long back out?
Replaced the uses of 'unsuccessful' and 'successful' with explicit
specifications.
> While this is getting picky, it might be worth thinking about what, if
> anything, happens if someone puts in a const or volatile (if you say you
> have to get the exact same type back out, then this solves that), or trie=
s
> to an any_cast with 'const int', or 'int&', when they put in an int. I
> assume that const gets ignored, but volatile probably doesn't.
The 'unsuccessful' and 'successful' fix answers some of that, and
coincidentally an example has been added that uses "int&", so it is
clear that should work, but I'm unsure about const and volatile. My
guess is that your assumption is correct. Does anyone else have an
opinion?
>
> While this might be a bit fiddly in the wording however, I don't think it=
's
> any kind of serious issue.
Agreed.
Thanks,
--Beman
--=20
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 10 Jan 2013 16:05:15 +0100
Raw View
2013/1/10 Beman Dawes <bdawes@acm.org>:
> On Thu, Jan 10, 2013 at 8:28 AM, Chris Jefferson <chris@bubblescope.net> =
wrote:
>> On 09/01/13 16:10, Beman Dawes wrote:
>>>
>>> A draft of the Any library proposal (Revision 2) is available.
>>>
>>> See http://beman.github.com/dot16/any-proposal.html
>>>
>>> As always, comments and corrections welcome!
>>>
>>> --Beman
>>>
>> I don't see any particular reason to require ValueType is CopyConstructa=
ble.
>> Like with (for example) vector, you need CopyConstructable when you copy
>> into the any, copy the any itself, or copy back out. But when moving in,
>> moving the any, and moving back out, it seems fine to only require
>> MoveConstructable.
>
> I'm going to leave that question for Daniel Kr=FCgler. He was the one
> who suggested the CopyConstructible wording, and he is the oracle I
> depend on for such questions:-)
Nevin already provided the answer, therefore I remained silent ;-)
- Daniel
--=20
.
Author: Beman Dawes <bdawes@acm.org>
Date: Thu, 10 Jan 2013 10:18:55 -0500
Raw View
On Thu, Jan 10, 2013 at 9:12 AM, Paul Smith <pl.smith.mail@gmail.com> wrote:
> On Thu, Jan 10, 2013 at 3:56 PM, Paul Smith <pl.smith.mail@gmail.com> wrote:
>>
>>
>> On Wednesday, January 9, 2013 6:10:00 PM UTC+2, Beman Dawes wrote:
>>
>> A few notes:
>>
>> [snip]
>
> Another quickie:
>
> For the pointer 'any_cast's:
>
> Returns: A pointer to the value contained by operand if successful,
> otherwise <del>nullptr</del><ins>a null pointer value</ins>. The
> returned pointer is const qualified for the signature with a const
> argument.
>
> 'nullptr' is not a pointer.
Fixed.
See updated http://beman.github.com/dot16/any-proposal.html
I need to shift to some other work right now, but I'll be thinking
about your emplace proposal, etc.
--Beman
--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 10 Jan 2013 13:25:22 -0600
Raw View
--bcaec550b3364a8cec04d2f426a1
Content-Type: text/plain; charset=ISO-8859-1
On 10 January 2013 08:23, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
> We didn't have perfect forwarding during those years, so perhaps it's
> worth considering?
> I'm not referring to the ability to store any inside any, but the
> ability to emplace.
>
+1.
If we do,we will have to minimally address whether or not an any can be
stored in an any; I was just pointing out earlier that it isn't a
motivating example.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--bcaec550b3364a8cec04d2f426a1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 10 January 2013 08:23, Ville Voutilainen <span dir=3D"ltr"><<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5"><br>
</div></div>We didn't have perfect forwarding during those years, so pe=
rhaps it's<br>
worth considering?<br>
I'm not referring to the ability to store any inside any, but the<br>
ability to emplace.<br></blockquote><div><br>+1.<br><br>If we do,we will ha=
ve to minimally address whether or not an any can be stored in an any; I wa=
s just pointing out earlier that it isn't a motivating example.<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
<p></p>
-- <br />
<br />
<br />
<br />
--bcaec550b3364a8cec04d2f426a1--
.
Author: Paul Smith <pl.smith.mail@gmail.com>
Date: Thu, 10 Jan 2013 22:59:44 +0200
Raw View
On Thu, Jan 10, 2013 at 9:25 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> If we do,we will have to minimally address whether or not an any can be
> stored in an any; I was just pointing out earlier that it isn't a motivating
> example.
It's a hypothetical case, but I'm a little surprised that you find it
that controversial. If a generic component (not necessarily part of
the standard library) uses 'any' internally in conjuction with client
types, it should forsee the possibility that the client uses 'any' as
well, especially if we are going to add it to the standard. If the use
of 'any' by the component is not documented, it's awkward to have
special semantics in this case. Construction and assignment yield an
unavoidable ambiguity, and the preference for treating them as
copy-construction and copy-assignment is obvious. This ambiguity
doesn't exist when using 'emplace', neither technically nor
conceptually.
Nevin, do you see a reason why we shouldn't allow it? Is there a
technical difficulity to implement this? Are there any practical
reasons why it's not desirable?
--
Paul Smith
--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 10 Jan 2013 15:22:32 -0600
Raw View
--0015174c12ce4d322504d2f5c99e
Content-Type: text/plain; charset=ISO-8859-1
On 10 January 2013 14:59, Paul Smith <pl.smith.mail@gmail.com> wrote:
> Construction and assignment yield an
>
unavoidable ambiguity, and the preference for treating them as
> copy-construction and copy-assignment is obvious. This ambiguity
> doesn't exist when using 'emplace', neither technically nor
> conceptually.
>
> Nevin, do you see a reason why we shouldn't allow it?
If we add emplace (and I think we should), we should allow it with the
above semantics. But they are special semantics, which happen to fall out
of a typical implementation of any.
> Is there a
> technical difficulity to implement this?
The implementation is easy; the word smithing is hard. :-) The semantics
need to be spelled out in the proposal, even though they shouldn't affect a
typical implementation. Given that we would need extra wording even if we
wanted to disallow it, I agree we are better off allowing it with the
semantics you specified.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--0015174c12ce4d322504d2f5c99e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 10 January 2013 14:59, Paul Smith <span dir=3D"ltr"><<a href=3D"mailt=
o:pl.smith.mail@gmail.com" target=3D"_blank">pl.smith.mail@gmail.com</a>>=
;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div class=3D"im">Construction and assignment yield an</div></blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
unavoidable ambiguity, and the preference for treating them as<br>
copy-construction and copy-assignment is obvious. This ambiguity<br>
doesn't exist when using 'emplace', neither technically nor<br>
conceptually.<br>
<br>
Nevin, do you see a reason why we shouldn't allow it?</blockquote><div>=
<br></div><div>If we add emplace (and I think we should), we should allow i=
t with the above semantics. =A0But they are special semantics, which happen=
to fall out of a typical implementation of any. =A0</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"> Is there a<br>
technical difficulity to implement this?</blockquote><div><br></div><div>Th=
e implementation is easy; the word smithing is hard. :-) =A0The semantics n=
eed to be spelled out in the proposal, even though they shouldn't affec=
t a typical implementation. =A0Given that we would need extra wording even =
if we wanted to disallow it, I agree we are better off allowing it with the=
semantics you specified.</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
<p></p>
-- <br />
<br />
<br />
<br />
--0015174c12ce4d322504d2f5c99e--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Thu, 10 Jan 2013 22:45:51 +0100
Raw View
> On Thu, Jan 10, 2013 at 9:25 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
>> If we do,we will have to minimally address whether or not an any can be
>> stored in an any; I was just pointing out earlier that it isn't a motivating
>> example.
> It's a hypothetical case, but I'm a little surprised that you find it
> that controversial. If a generic component (not necessarily part of
> the standard library) uses 'any' internally in conjuction with client
> types, it should forsee the possibility that the client uses 'any' as
> well, especially if we are going to add it to the standard. If the use
> of 'any' by the component is not documented, it's awkward to have
> special semantics in this case. Construction and assignment yield an
> unavoidable ambiguity, and the preference for treating them as
> copy-construction and copy-assignment is obvious. This ambiguity
> doesn't exist when using 'emplace', neither technically nor
> conceptually.
>
I certainly think we should allow any in any, but how to make the syntax
to construct such intuitive. Emplace is a good start but maybe not
enough. First thought that comes to mind is make_any ;)
Mikael
--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 10 Jan 2013 22:52:38 +0100
Raw View
Le 10/01/13 14:12, Beman Dawes a =E9crit :
> On Wed, Jan 9, 2013 at 4:37 PM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> Le 09/01/13 18:55, Vicente J. Botet Escriba a =E9crit :
>>
>> Le 09/01/13 17:10, Beman Dawes a =E9crit :
>>
>> A draft of the Any library proposal (Revision 2) is available.
>>
>> See http://beman.github.com/dot16/any-proposal.html
>>
>> As always, comments and corrections welcome!
>>
>> --Beman
>>
>>
>>
>> Shouldn't the overload of any_cast for pointers to any return a pointer =
to
>> ValueType in
>>
>> template<typename ValueType>
>> ValueType any_cast(const any* operand) noexcept;
>>
>> template<typename ValueType>
>> ValueType any_cast(any* operand) noexcept;
>>
>>
>> If any_cast doesn't modify its argument, why we do need the non-const
>> overload?
>>
>> template<typename ValueType>
>> ValueType any_cast(any& operand);
>>
>> template<typename ValueType>
>> ValueType any_cast(any* operand) noexcept;
>>
>>
>> Please forget these comments. I believe I understand the why now.
> On the contrary, I think your comments indicate a need to clarify the
> spec at least by adding examples.
>
As already suggested changing the template parameter name to ValeTypePtr=20
and improving the wording would help. An example that is used to change=20
the value of the stored vale type will of course make the things more=20
evident.
Vicente
--=20
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 10 Jan 2013 22:54:42 +0100
Raw View
This is a multi-part message in MIME format.
--------------080707040906020301010109
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/01/13 18:55, Vicente J. Botet Escriba a =E9crit :
> Le 09/01/13 17:10, Beman Dawes a =E9crit :
>> A draft of the Any library proposal (Revision 2) is available.
>>
>> Seehttp://beman.github.com/dot16/any-proposal.html
>>
>> As always, comments and corrections welcome!
>>
>> --Beman
>>
> Sorry if this has already been discussed. Is there a reason to prefer=20
> the use of any_cast to the explicit conversion?
>
> template<typename ValueType>
> ValueType any_cast(const any& operand);
>
> class any
> {
> public: ...
> template<typename ValueType>
> operator ValueType() const; ...
> };
>
I understand that any_cast was a need for c++98, but not for c++11.=20
Could someone comment on this point?
Vicente
--=20
--------------080707040906020301010109
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 09/01/13 18:55, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:50EDAF2D.1080904@wanadoo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 09/01/13 17:10, Beman Dawes a
écrit :<br>
</div>
<blockquote
cite="mid:CAAygHNM6V5OKdieOz+0n03NG7fdDeVOXkSNMWe0nNJfzpYc2Aw@mail.gmail.com"
type="cite">
<pre wrap="">A draft of the Any library proposal (Revision 2) is available.
See <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://beman.github.com/dot16/any-proposal.html">http://beman.github.com/dot16/any-proposal.html</a>
As always, comments and corrections welcome!
--Beman
</pre>
</blockquote>
Sorry if this has already been discussed. Is there a reason to
prefer the use of any_cast to the explicit conversion?<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre> template<typename ValueType>
ValueType any_cast(const any& operand);
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> class any
{
public: ...
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> template<typename ValueType>
operator ValueType() const; ...
</pre>
};<br>
<br>
</blockquote>
I understand that any_cast was a need for c++98, but not for c++11.
Could someone comment on this point?<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------080707040906020301010109--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 10 Jan 2013 22:56:36 +0100
Raw View
This is a multi-part message in MIME format.
--------------040404040505030506060504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/01/13 21:39, Vicente J. Botet Escriba a =E9crit :
> Le 09/01/13 18:55, Vicente J. Botet Escriba a =E9crit :
>> Le 09/01/13 17:10, Beman Dawes a =E9crit :
>>> A draft of the Any library proposal (Revision 2) is available.
>>>
>>> Seehttp://beman.github.com/dot16/any-proposal.html
>>>
>>> As always, comments and corrections welcome!
>>>
>>>
>
> What about a is() member function?
>
> template <typename ValueType>
> bool is() const noexcept;
>
> So that the user can just do
>
> if (aAny.is<VT>()) ...
>
>
Could someone comment on this?
Vicente
--=20
--------------040404040505030506060504
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 09/01/13 21:39, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:50EDD58A.5020601@wanadoo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 09/01/13 18:55, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:50EDAF2D.1080904@wanadoo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 09/01/13 17:10, Beman Dawes a
écrit :<br>
</div>
<blockquote
cite="mid:CAAygHNM6V5OKdieOz+0n03NG7fdDeVOXkSNMWe0nNJfzpYc2Aw@mail.gmail.com"
type="cite">
<pre wrap="">A draft of the Any library proposal (Revision 2) is available.
See <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://beman.github.com/dot16/any-proposal.html">http://beman.github.com/dot16/any-proposal.html</a>
As always, comments and corrections welcome!
</pre>
</blockquote>
</blockquote>
<br>
What about a is() member function?<br>
<br>
template <typename ValueType><br>
bool is() const noexcept;<br>
<br>
So that the user can just do <br>
<br>
if (aAny.is<VT>()) ...<br>
<br>
<br>
</blockquote>
Could someone comment on this?<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------040404040505030506060504--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Thu, 10 Jan 2013 22:59:48 +0100
Raw View
>> What about a is() member function?
>>
>> template <typename ValueType>
>> bool is() const noexcept;
>>
>> So that the user can just do
>>
>> if (aAny.is<VT>()) ...
>>
>>
> Could someone comment on this?
I find the _is_ much more intuitive than having to check the typeid
explicitly, so you have my +1.
Mikael
--
.
Author: Paul Smith <pl.smith.mail@gmail.com>
Date: Fri, 11 Jan 2013 00:01:22 +0200
Raw View
On Thu, Jan 10, 2013 at 11:22 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 10 January 2013 14:59, Paul Smith <pl.smith.mail@gmail.com> wrote:
>>
>> Construction and assignment yield an
>>
>> unavoidable ambiguity, and the preference for treating them as
>> copy-construction and copy-assignment is obvious. This ambiguity
>> doesn't exist when using 'emplace', neither technically nor
>> conceptually.
>>
>> Nevin, do you see a reason why we shouldn't allow it?
>
>
> If we add emplace (and I think we should), we should allow it with the above
> semantics. But they are special semantics, which happen to fall out of a
> typical implementation of any.
Maybe. I'm not familiar with all the implementations of any that are
out there. I perceive this as contributory to a worry-free use of any.
> The semantics
> need to be spelled out in the proposal, even though they shouldn't affect a
> typical implementation.
Agreed. A note in the description of 'emplace' sounds like a minimum.
--
Paul Smith
--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Thu, 10 Jan 2013 23:14:47 +0100
Raw View
This is a multi-part message in MIME format.
--------------080306090303020609030301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> Sorry if this has already been discussed. Is there a reason to prefer
>> the use of any_cast to the explicit conversion?
>>
>> template<typename ValueType>
>> ValueType any_cast(const any& operand);
>>
>> class any
>> {
>> public: ...
>> template<typename ValueType>
>> operator ValueType() const; ...
>> };
>>
> I understand that any_cast was a need for c++98, but not for c++11.
> Could someone comment on this point?
>
I find the cast notation to be useful (any_cast) but i see no reason to
not have the explicit conversion function as well.
Mikael
--
--------------080306090303020609030301
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<blockquote cite="mid:50EF38A2.4000205@wanadoo.fr" type="cite">
<blockquote cite="mid:50EDAF2D.1080904@wanadoo.fr" type="cite">
<blockquote
cite="mid:CAAygHNM6V5OKdieOz+0n03NG7fdDeVOXkSNMWe0nNJfzpYc2Aw@mail.gmail.com"
type="cite"> </blockquote>
Sorry if this has already been discussed. Is there a reason to
prefer the use of any_cast to the explicit conversion?<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<pre> template<typename ValueType>
ValueType any_cast(const any& operand);
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> class any
{
public: ...
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> template<typename ValueType>
operator ValueType() const; ...
</pre>
};<br>
<br>
</blockquote>
I understand that any_cast was a need for c++98, but not for
c++11. Could someone comment on this point?<br>
<br>
</blockquote>
<br>
I find the cast notation to be useful (any_cast) but i see no reason
to not have the explicit conversion function as well.<br>
<br>
<br>
Mikael<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------080306090303020609030301--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 10 Jan 2013 16:34:12 -0600
Raw View
--0015175cfccca3294304d2f6c9dc
Content-Type: text/plain; charset=ISO-8859-1
On 10 January 2013 07:22, Beman Dawes <bdawes@acm.org> wrote:
>
> Changing the name of the template parameter was already on my list of
> changes to clarify the any_cast pointer flavor, although I hadn't
> given any thought to the exact name. PtrToValueType is much clearer
> than ValueType, but ValueTypePtr also comes to mind.
>
Editorial:
template<typename ValueType ValueTypePtr>
ValueTypePtr ValueType any_cast(any* operand) noexcept;
The return type should be ValueTypePtr, not ValueType.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--0015175cfccca3294304d2f6c9dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 10 January 2013 07:22, Beman Dawes <span dir=3D"ltr"><<a href=3D"mail=
to:bdawes@acm.org" target=3D"_blank">bdawes@acm.org</a>></span> wrote:<b=
r><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5"><br>
</div></div>Changing the name of the template parameter was already on my l=
ist of<br>
changes to clarify the any_cast pointer flavor, although I hadn't<br>
given any thought to the exact name. PtrToValueType is much clearer<br>
than ValueType, but ValueTypePtr also comes to mind.<br></blockquote><div><=
br>Editorial:<br><br><pre> template<typename <del>ValueType</del> <ins>=
ValueTypePtr</ins>>
<del>ValueTypePtr</del> <ins>ValueType</ins> any_cast(any* operand) noe=
xcept;</pre><br>The return type should be ValueTypePtr, not ValueType.<br><=
/div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;=A0 (847) 691-1404
<p></p>
-- <br />
<br />
<br />
<br />
--0015175cfccca3294304d2f6c9dc--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 10 Jan 2013 17:43:00 -0600
Raw View
On Thu, Jan 10, 2013 at 3:54 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> I understand that any_cast was a need for c++98, but not for c++11. Could
> someone comment on this point?
static_cast<TargetType>(any_obj)
Surprised. It's the first time that I know that static_cast can
deduce a conversion function's template argument. (14.8.2.4/3)
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sun, 13 Jan 2013 21:57:17 -0500
Raw View
On Wed, Jan 9, 2013 at 11:10 AM, Beman Dawes <bdawes@acm.org> wrote:
> A draft of the Any library proposal (Revision 2) is available.
>
> See http://beman.github.com/dot16/any-proposal.html
>
> As always, comments and corrections welcome!
>
> --Beman
>
Maybe I missed it in the thread, but instead of:
operand.type() == typeid(int);
is there any value in
operand.is_type<int>();
ie more potential for compiler optimization? Or custom implementation
by the vendors?
operand.type() _must_ return the typeid, but is_type could do
whatever it wants.
Tony
--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 13 Jan 2013 21:32:35 -0600
Raw View
On Sun, Jan 13, 2013 at 8:57 PM, Tony V E <tvaneerd@gmail.com> wrote:
> operand.is_type<int>();
Very sad, the grammar has to be
operand.template is_type<int>();
here.
The idea is not bad, but I don't think compiler can do much optimization
here, since std::any intends to be a dynamic typed pointer.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.
Author: Jeremiah Willcock <jewillco@osl.iu.edu>
Date: Sun, 13 Jan 2013 22:34:32 -0500 (EST)
Raw View
On Sun, 13 Jan 2013, Zhihao Yuan wrote:
> On Sun, Jan 13, 2013 at 8:57 PM, Tony V E <tvaneerd@gmail.com> wrote:
>> operand.is_type<int>();
>
> Very sad, the grammar has to be
>
> operand.template is_type<int>();
>
> here.
Is that truly necessary? I had thought the proposed class was not a
template, and so the .template syntax would not be necessary.
-- Jeremiah Willcock
--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 13 Jan 2013 21:57:55 -0600
Raw View
On Sun, Jan 13, 2013 at 9:34 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
> Is that truly necessary? I had thought the proposed class was not a
> template, and so the .template syntax would not be necessary.
Ah, yeah. And a function using std::any does not need a template
parameters for it...
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
.
Author: Aleksandar Fabijanic <aleks.fabijanic@gmail.com>
Date: Sun, 13 Jan 2013 23:29:28 -0600
Raw View
On Sun, Jan 13, 2013 at 9:34 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
>> On Sun, Jan 13, 2013 at 8:57 PM, Tony V E <tvaneerd@gmail.com> wrote:
>>>
>>> operand.is_type<int>();
>>
>> Very sad, the grammar has to be operand.template is_type<int>();
>>
>> here.
>
> Is that truly necessary? I had thought the proposed class was not a
> template, and so the .template syntax would not be necessary.
As I see it, that is the main shortcoming of any - it is dynamic on
assignment side but when it comes time to retrieve value, you're back
to the original constraint of having to know what the type is (with
any even more rigid than C++ type system). The only scenario where I
found any being truly useful is two parties exchanging data and
knowing exactly what types to expect using any as a "typeless"
transport medium. Extending any in dynamic sense on the data retrieval
side is possible and desirable and I think it should be kept in mind.
For more elaboration on the topic, see DynamicAny articles:
http://accu.org/index.php/journals/1502
http://accu.org/index.php/journals/1511
Alex
--
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Sun, 13 Jan 2013 23:30:04 -0600
Raw View
Tony V E <tvaneerd@gmail.com> writes:
| On Wed, Jan 9, 2013 at 11:10 AM, Beman Dawes <bdawes@acm.org> wrote:
| > A draft of the Any library proposal (Revision 2) is available.
| >
| > See http://beman.github.com/dot16/any-proposal.html
| >
| > As always, comments and corrections welcome!
| >
| > --Beman
| >
|
| Maybe I missed it in the thread, but instead of:
|
| operand.type() == typeid(int);
|
| is there any value in
|
| operand.is_type<int>();
One issue with `typeid' is that it silently strips aways references and
cv-qualifiers.
any_cast is described as parameterized by a ValueType, but the next
instantiates ValueType to "int&", something that is NOT a value type.
-- Gaby
--
.
Author: Alberto Ganesh Barbati <albertobarbati@gmail.com>
Date: Tue, 15 Jan 2013 10:05:43 +0100
Raw View
Il giorno 09/gen/2013, alle ore 17:10, Beman Dawes <bdawes@acm.org> ha scritto:
> A draft of the Any library proposal (Revision 2) is available.
>
> See http://beman.github.com/dot16/any-proposal.html
>
> As always, comments and corrections welcome!
>
I find the note and example after the first overload set of any_cast improvable:
template<typename ValueType>
ValueType any_cast(const any& operand);
template<typename ValueType>
ValueType any_cast(any& operand);
Returns: The value contained by operand.
Throws: bad_any_cast if operand.type() != typeid(remove_reference<ValueType>::type).
[Note: For consistency with the C++ keyword casts, a copy is returned.--end note.]
[Example:
any x;
x = 51;
any_cast<int&>(x) = 42;
--end example]
The point is that the note says that a copy is always returned, so it's not clear whether the example is actually modifying the object or a copy of it (which would be pointless). I suggest to be a little more verbose, for the sake of clarify:
[Note: For consistency with the C++ keyword casts, a copy is returned <ins>if ValueType is not a reference type, otherwise a reference to the stored type is returned</ins>.--end note.]
[Example:
any x;
x = 51;
any_cast<int&>(x) = 42;
<ins>assert(any_cast<int>(x) == 42);</ins>
--end example]
Just my two eurocent,
Ganesh
--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 15 Jan 2013 03:55:31 -0800 (PST)
Raw View
------=_Part_974_1593396.1358250931194
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, January 15, 2013 1:05:43 AM UTC-8, Alberto Ganesh Barbati wrote:
>
>
> Il giorno 09/gen/2013, alle ore 17:10, Beman Dawes <bda...@acm.org<javascript:>>
> ha scritto:
>
> > A draft of the Any library proposal (Revision 2) is available.
> >
> > See http://beman.github.com/dot16/any-proposal.html
> >
> > As always, comments and corrections welcome!
> >
>
> I find the note and example after the first overload set of any_cast
> improvable:
>
> template<typename ValueType>
> ValueType any_cast(const any& operand);
> template<typename ValueType>
> ValueType any_cast(any& operand);
>
> Returns: The value contained by operand.
>
> Throws: bad_any_cast if operand.type() !=
> typeid(remove_reference<ValueType>::type).
>
> [Note: For consistency with the C++ keyword casts, a copy is
> returned.--end note.]
>
> [Example:
> any x;
> x = 51;
> any_cast<int&>(x) = 42;
> --end example]
>
> The point is that the note says that a copy is always returned, so it's
> not clear whether the example is actually modifying the object or a copy of
> it (which would be pointless). I suggest to be a little more verbose, for
> the sake of clarify:
>
> [Note: For consistency with the C++ keyword casts, a copy is returned
> <ins>if ValueType is not a reference type, otherwise a reference to the
> stored type is returned</ins>.--end note.]
>
> [Example:
> any x;
> x = 51;
> any_cast<int&>(x) = 42;
> <ins>assert(any_cast<int>(x) == 42);</ins>
> --end example]
>
> Just my two eurocent,
>
> Ganesh
>
>
Of course, it's also important to realize that if you do an `any_cast<T&>`
for a `const` any, you should be getting back a `const &`. Indeed, maybe
that whole section needs a bit of linguistic reworking to make it more
clear as to what's going on here.
--
------=_Part_974_1593396.1358250931194
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, January 15, 2013 1:05:43 AM UTC-8, Alberto Ganesh Barba=
ti wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Il giorno 09/gen/2013, alle ore 17:10, Beman Dawes <<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"C3d9KdQVOqwJ">bda...@acm=
..org</a>> ha scritto:
<br>
<br>> A draft of the Any library proposal (Revision 2) is available.
<br>>=20
<br>> See <a href=3D"http://beman.github.com/dot16/any-proposal.html" ta=
rget=3D"_blank">http://beman.github.com/dot16/<wbr>any-proposal.html</a>
<br>>=20
<br>> As always, comments and corrections welcome!
<br>>=20
<br>
<br>I find the note and example after the first overload set of any_cast im=
provable:
<br>
<br>template<typename ValueType>
<br> ValueType any_cast(const any& operand);
<br>template<typename ValueType>
<br> ValueType any_cast(any& operand);
<br>
<br>Returns: The value contained by operand.
<br>
<br>Throws: bad_any_cast if operand.type() !=3D typeid(remove_reference<=
<wbr>ValueType>::type).
<br>
<br>[Note: For consistency with the C++ keyword casts, a copy is returned.-=
-end note.]
<br>
<br>[Example:
<br> any x;
<br> x =3D 51;
<br> any_cast<int&>(x) =3D 42;
<br>--end example]
<br>
<br>The point is that the note says that a copy is always returned, so it's=
not clear whether the example is actually modifying the object or a copy o=
f it (which would be pointless). I suggest to be a little more verbose, for=
the sake of clarify:
<br>
<br>[Note: For consistency with the C++ keyword casts, a copy is returned &=
lt;ins>if ValueType is not a reference type, otherwise a reference to th=
e stored type is returned</ins>.--end note.]
<br>
<br>[Example:
<br> any x;
<br> x =3D 51;
<br> any_cast<int&>(x) =3D 42;
<br><ins>assert(any_cast<int>(x) =3D=3D 42);</ins>
<br>--end example]
<br>
<br>Just my two eurocent,
<br>
<br>Ganesh
<br>
<br></blockquote><div><br>Of course, it's also important to realize that if=
you do an `any_cast<T&>` for a `const` any, you should be gettin=
g back a `const &`. Indeed, maybe that whole section needs a bit of lin=
guistic reworking to make it more clear as to what's going on here.<br></di=
v>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_974_1593396.1358250931194--
.
Author: Alberto Ganesh Barbati <albertobarbati@gmail.com>
Date: Tue, 15 Jan 2013 13:32:27 +0100
Raw View
--Apple-Mail=_CEA9F417-E484-4169-901E-CA50D89AEC03
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
Il giorno 15/gen/2013, alle ore 12:55, Nicol Bolas <jmckesson@gmail.com> ha=
scritto:
>=20
>=20
> On Tuesday, January 15, 2013 1:05:43 AM UTC-8, Alberto Ganesh Barbati wro=
te:
>=20
> Il giorno 09/gen/2013, alle ore 17:10, Beman Dawes <bda...@acm.org> ha sc=
ritto:=20
>=20
> > A draft of the Any library proposal (Revision 2) is available.=20
> >=20
> > See http://beman.github.com/dot16/any-proposal.html=20
> >=20
> > As always, comments and corrections welcome!=20
> >=20
>=20
> I find the note and example after the first overload set of any_cast impr=
ovable:=20
>=20
> template<typename ValueType>=20
> ValueType any_cast(const any& operand);=20
> template<typename ValueType>=20
> ValueType any_cast(any& operand);=20
>=20
> Returns: The value contained by operand.=20
>=20
> Throws: bad_any_cast if operand.type() !=3D typeid(remove_reference<Value=
Type>::type).=20
>=20
> [Note: For consistency with the C++ keyword casts, a copy is returned.--e=
nd note.]=20
>=20
> [Example:=20
> any x;=20
> x =3D 51;=20
> any_cast<int&>(x) =3D 42;=20
> --end example]=20
>=20
> The point is that the note says that a copy is always returned, so it's n=
ot clear whether the example is actually modifying the object or a copy of =
it (which would be pointless). I suggest to be a little more verbose, for t=
he sake of clarify:=20
>=20
> [Note: For consistency with the C++ keyword casts, a copy is returned <in=
s>if ValueType is not a reference type, otherwise a reference to the stored=
type is returned</ins>.--end note.]=20
>=20
> [Example:=20
> any x;=20
> x =3D 51;=20
> any_cast<int&>(x) =3D 42;=20
> <ins>assert(any_cast<int>(x) =3D=3D 42);</ins>=20
> --end example]=20
>=20
> Just my two eurocent,=20
>=20
> Ganesh=20
>=20
>=20
> Of course, it's also important to realize that if you do an `any_cast<T&>=
` for a `const` any, you should be getting back a `const &`. Indeed, maybe =
that whole section needs a bit of linguistic reworking to make it more clea=
r as to what's going on here.
>=20
Good point, however, I would prefer the any_cast to fail in that case, whic=
h would be consistent with static_cast:
const int a =3D 0;
const int& ra =3D static_cast<int&>(a); // #1 ill-formed, cast removes co=
nst-ness: should be static_cast<const int&>
const any b =3D a;
const int& rb =3D any_cast<int&>(b); // #2 should be ill-formed too
If you make any_cast<int&>(b) silently return a const int&, line #2 would c=
ompile.
By the way, did we consider to have move-aware overloads of any_cast? I mea=
n, in the following case:
any f();
vector<int> v =3D any_cast<vector<int>>(f());
wouldn't it be nice if the vector were moved instead of copied? Currently, =
the call uses any_cast<>(const any&), which eventually makes a copy, but we=
could provide an additional overload for any_cast<>(any&&), which could ef=
fectively move-initialize the result.=20
Similarly, for the "target" type:
any x =3D f();
vector<int> v =3D any_cast<vector<int>&&>(x);
could move the vector out of x (notice that x is an lvalue here). However, =
I am not advocating this style, as I have mixed feelings about it. Consider=
that, if we had the any&& overload above, it could be written as
any_cast<std::vector<int>>(std::move(x));
which looks saner to me, with "std::move" clearly raising a red flag about =
x going to be modified.
Any comments?
Ganesh
--=20
--Apple-Mail=_CEA9F417-E484-4169-901E-CA50D89AEC03
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space; "><br><div><div>Il giorno=
15/gen/2013, alle ore 12:55, Nicol Bolas <<a href=3D"mailto:jmckesson@g=
mail.com">jmckesson@gmail.com</a>> ha scritto:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite"><br><br>On Tuesday, January 1=
5, 2013 1:05:43 AM UTC-8, Alberto Ganesh Barbati wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; b=
order-left-color: rgb(204, 204, 204); border-left-style: solid; padding-lef=
t: 1ex; position: static; z-index: auto; ">
<br>Il giorno 09/gen/2013, alle ore 17:10, Beman Dawes <<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"C3d9KdQVOqwJ">bda...@acm=
..org</a>> ha scritto:
<br>
<br>> A draft of the Any library proposal (Revision 2) is available.
<br>>=20
<br>> See <a href=3D"http://beman.github.com/dot16/any-proposal.html" ta=
rget=3D"_blank">http://beman.github.com/dot16/<wbr>any-proposal.html</a>
<br>>=20
<br>> As always, comments and corrections welcome!
<br>>=20
<br>
<br>I find the note and example after the first overload set of any_cast im=
provable:
<br>
<br>template<typename ValueType>
<br> ValueType any_cast(const any& operand);
<br>template<typename ValueType>
<br> ValueType any_cast(any& operand);
<br>
<br>Returns: The value contained by operand.
<br>
<br>Throws: bad_any_cast if operand.type() !=3D typeid(remove_reference<=
<wbr>ValueType>::type).
<br>
<br>[Note: For consistency with the C++ keyword casts, a copy is returned.-=
-end note.]
<br>
<br>[Example:
<br> any x;
<br> x =3D 51;
<br> any_cast<int&>(x) =3D 42;
<br>--end example]
<br>
<br>The point is that the note says that a copy is always returned, so it's=
not clear whether the example is actually modifying the object or a copy o=
f it (which would be pointless). I suggest to be a little more verbose, for=
the sake of clarify:
<br>
<br>[Note: For consistency with the C++ keyword casts, a copy is returned &=
lt;ins>if ValueType is not a reference type, otherwise a reference to th=
e stored type is returned</ins>.--end note.]
<br>
<br>[Example:
<br> any x;
<br> x =3D 51;
<br> any_cast<int&>(x) =3D 42;
<br><ins>assert(any_cast<int>(x) =3D=3D 42);</ins>
<br>--end example]
<br>
<br>Just my two eurocent,
<br>
<br>Ganesh
<br>
<br></blockquote><div><br>Of course, it's also important to realize that if=
you do an `any_cast<T&>` for a `const` any, you should be gettin=
g back a `const &`. Indeed, maybe that whole section needs a bit of lin=
guistic reworking to make it more clear as to what's going on here.<br></di=
v><div><br class=3D"webkit-block-placeholder"></div></blockquote><br></div>=
<div>Good point, however, I would prefer the any_cast to fail in that case,=
which would be consistent with static_cast:</div><div><br></div><div> =
; const int a =3D 0;</div><div> const int& ra =3D static_cast<=
int&>(a); // #1 ill-formed, cast removes const-ness: should be stati=
c_cast<const int&></div><div><br></div><div> const any b =
=3D a;</div><div> const int& rb =3D any_cast<int&>(b); =
// #2 should be ill-formed too</div><div><br></div><div>If you make any_cas=
t<int&>(b) silently return a const int&, line #2 would compil=
e.</div><div><br></div>By the way, did we consider to have move-aware overl=
oads of any_cast? I mean, in the following case:<div><br></div><div> =
any f();</div><div> vector<int> v =3D any_cast<vector<int=
>>(f());</div><div><br></div><div>wouldn't it be nice if the vector w=
ere moved instead of copied? Currently, the call uses any_cast<>(cons=
t any&), which eventually makes a copy, but we could provide an additio=
nal overload for any_cast<>(any&&), which could effectively m=
ove-initialize the result. </div><div><br></div><div>Similarly, for th=
e "target" type:</div><div><br></div><div> any x =3D f();</div><div><=
div> vector<int> v =3D any_cast<vector<int>&&&=
gt;(x);</div></div><div><br></div><div>could move the vector out of x (noti=
ce that x is an lvalue here). However, I am not advocating this style, as I=
have mixed feelings about it. Consider that, if we had the any&& o=
verload above, it could be written as</div><div><br></div><div> =
any_cast<std::vector<int>>(std::move(x));</div><div><br></div><=
div>which looks saner to me, with "std::move" clearly raising a red flag ab=
out x going to be modified.</div><div><br></div><div>Any comments?</div><di=
v><br></div><div>Ganesh</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
<br />
<br />
--Apple-Mail=_CEA9F417-E484-4169-901E-CA50D89AEC03--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 15 Jan 2013 09:37:40 -0500
Raw View
On Tue, Jan 15, 2013 at 7:32 AM, Alberto Ganesh Barbati
<albertobarbati@gmail.com> wrote:
> Good point, however, I would prefer the any_cast to fail in that case, which
> would be consistent with static_cast:
>
> const int a = 0;
> const int& ra = static_cast<int&>(a); // #1 ill-formed, cast removes
> const-ness: should be static_cast<const int&>
>
> const any b = a;
> const int& rb = any_cast<int&>(b); // #2 should be ill-formed too
>
+1
>
> By the way, did we consider to have move-aware overloads of any_cast? I
> mean, in the following case:
>
> any f();
> vector<int> v = any_cast<vector<int>>(f());
>
> wouldn't it be nice if the vector were moved instead of copied? Currently,
> the call uses any_cast<>(const any&), which eventually makes a copy, but we
> could provide an additional overload for any_cast<>(any&&), which could
> effectively move-initialize the result.
>
+1
> Similarly, for the "target" type:
>
> any x = f();
> vector<int> v = any_cast<vector<int>&&>(x);
>
-1
> could move the vector out of x (notice that x is an lvalue here). However, I
> am not advocating this style, as I have mixed feelings about it. Consider
> that, if we had the any&& overload above, it could be written as
>
> any_cast<std::vector<int>>(std::move(x));
>
+1
> which looks saner to me, with "std::move" clearly raising a red flag about x
> going to be modified.
>
> Any comments?
>
> Ganesh
>
....IMO.
Tony
--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Wed, 16 Jan 2013 08:34:03 +0100
Raw View
Il giorno 15/gen/2013, alle ore 15:37, Tony V E <tvaneerd@gmail.com> ha scr=
itto:
> On Tue, Jan 15, 2013 at 7:32 AM, Alberto Ganesh Barbati
> <albertobarbati@gmail.com> wrote:
>> Good point, however, I would prefer the any_cast to fail in that case, w=
hich
>> would be consistent with static_cast:
>>=20
>> const int a =3D 0;
>> const int& ra =3D static_cast<int&>(a); // #1 ill-formed, cast removes
>> const-ness: should be static_cast<const int&>
>>=20
>> const any b =3D a;
>> const int& rb =3D any_cast<int&>(b); // #2 should be ill-formed too
>=20
> +1
>=20
>>=20
>> By the way, did we consider to have move-aware overloads of any_cast? I
>> mean, in the following case:
>>=20
>> any f();
>> vector<int> v =3D any_cast<vector<int>>(f());
>>=20
>> wouldn't it be nice if the vector were moved instead of copied? Currentl=
y,
>> the call uses any_cast<>(const any&), which eventually makes a copy, but=
we
>> could provide an additional overload for any_cast<>(any&&), which could
>> effectively move-initialize the result.
>=20
> +1
>=20
>> Similarly, for the "target" type:
>>=20
>> any x =3D f();
>> vector<int> v =3D any_cast<vector<int>&&>(x);
>=20
> -1
As I said, I'm not really fond of that one. However, we need to address thi=
s case. What is the behavior we want? Should it work as I described (move t=
he vector out of x, leaving x with an empty vector) or be rejected at compi=
le-time? Do we have other options?
>=20
>> could move the vector out of x (notice that x is an lvalue here). Howeve=
r, I
>> am not advocating this style, as I have mixed feelings about it. Conside=
r
>> that, if we had the any&& overload above, it could be written as
>>=20
>> any_cast<std::vector<int>>(std::move(x));
>=20
> +1
>=20
>> which looks saner to me, with "std::move" clearly raising a red flag abo=
ut x
>> going to be modified.
>>=20
>> Any comments?
>>=20
>> Ganesh
>=20
> ...IMO.
> Tony
>=20
> --=20
>=20
>=20
>=20
--=20
.
Author: Cassio Neri <cassio.neri@gmail.com>
Date: Wed, 16 Jan 2013 08:17:26 -0800 (PST)
Raw View
------=_Part_426_5132160.1358353046026
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 14, 2013 2:57:17 AM UTC, Tony V E wrote:
>
>
> Maybe I missed it in the thread, but instead of:
>
> operand.type() == typeid(int);
>
> is there any value in
>
> operand.is_type<int>();
>
> ie more potential for compiler optimization? Or custom implementation
> by the vendors?
>
Consider this example (which I mentioned in another thread)
struct A {};
struct B : public A {};
int main() {
B b;
A& a(b);
any any_a(a); // slicing: arguably bad behavior but not UB.
assert(any_a.type() == typeid(A));
assert(any_a.type() == typeid(a));
}
Now, if A is given a virtual method, then the first assertion above
still passes but the second one fails. This shows how old code
(written prior to A becoming polymorphic) relying on any_a.type() ==
typeid(a) can be broken. I do understand the semantics of typeid but
one must agree that after the initialization 'any any_a(a);' the fact
that any_a and a don't have the same "type" might surprise a lot of
people.
The first assertion is more future proof because it uses typeid on a
type operand (A) rather than on an object (a). Since is_type<A>()
forces clients to provide a type rather than an object, IMHO this
is preferable over any::type().
--
------=_Part_426_5132160.1358353046026
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, January 14, 2013 2:57:17 AM UTC, Tony V E wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><br>Maybe I missed it in the thread, but inste=
ad of:
<br>
<br> operand.type() =3D=3D typeid(int);
<br>
<br>is there any value in
<br>
<br> operand.is_type<int>();
<br>
<br>ie more potential for compiler optimization? Or custom implementa=
tion
<br>by the vendors?
<br></blockquote><div><br>Consider this example (which I mentioned in anoth=
er thread)<br><br>struct A {};<br>struct B : public A {};<br><br>int main()=
{<br> B b;<br> A& a(b);<br> &=
nbsp; any any_a(a); // slicing: arguably bad behavior but not UB.<br>=
assert(any_a.type() =3D=3D typeid(A));<br> &n=
bsp; assert(any_a.type() =3D=3D typeid(a));<br>}<br><br>Now, if A is given =
a virtual method, then the first assertion above<br>still passes but the se=
cond one fails. This shows how old code<br>(written prior to A becoming pol=
ymorphic) relying on any_a.type() =3D=3D<br>typeid(a) can be broken. I do u=
nderstand the semantics of typeid but<br>one must agree that after the init=
ialization 'any any_a(a);' the fact<br>that any_a and a don't have the same=
"type" might surprise a lot of<br>people.<br><br>The first assertion is mo=
re future proof because it uses typeid on a<br>type operand (A) rather than=
on an object (a). Since is_type<A>()<br>forces clients to provide a =
type rather than an object, IMHO this<br>is preferable over any::type().<br=
><br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_426_5132160.1358353046026--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 16 Jan 2013 11:49:17 -0500
Raw View
On Wed, Jan 16, 2013 at 11:17 AM, Cassio Neri <cassio.neri@gmail.com> wrote:
> On Monday, January 14, 2013 2:57:17 AM UTC, Tony V E wrote:
>>
>>
>> Maybe I missed it in the thread, but instead of:
>>
>> operand.type() == typeid(int);
>>
>> is there any value in
>>
>> operand.is_type<int>();
>>
>> ie more potential for compiler optimization? Or custom implementation
>> by the vendors?
>
>
> Consider this example (which I mentioned in another thread)
>
> struct A {};
> struct B : public A {};
>
> int main() {
> B b;
> A& a(b);
> any any_a(a); // slicing: arguably bad behavior but not UB.
> assert(any_a.type() == typeid(A));
> assert(any_a.type() == typeid(a));
> }
>
> Now, if A is given a virtual method, then the first assertion above
> still passes but the second one fails. This shows how old code
> (written prior to A becoming polymorphic) relying on any_a.type() ==
> typeid(a) can be broken. I do understand the semantics of typeid but
> one must agree that after the initialization 'any any_a(a);' the fact
> that any_a and a don't have the same "type" might surprise a lot of
> people.
>
> The first assertion is more future proof because it uses typeid on a
> type operand (A) rather than on an object (a). Since is_type<A>()
> forces clients to provide a type rather than an object, IMHO this
> is preferable over any::type().
>
> --
>
That looks like an important distinction to me. I prefer is_type<T>
because that tends to be how any is used - the type is one of a fixed
set of compile-time types.
However, if I do need to compare the type of an any to a *runtime*
type of something else, I still need to compare type_ids. So either
a.type() == typeid(b)
or
a.is_type(typeid(b))
(Although I don't see any advantage to the second.)
Should there be both (is_type<T> and a.type())? Obviously just having
the second can handle all cases (a.type() == typeid(T) instead of
is_type<T>), but then we lose the distinction. Or at least it becomes
very subtle.
Tony
--
.
Author: Cassio Neri <cassio.neri@gmail.com>
Date: Wed, 16 Jan 2013 09:23:58 -0800 (PST)
Raw View
------=_Part_88_12922010.1358357038726
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, January 16, 2013 4:49:17 PM UTC, Tony V E wrote:
>
>
> That looks like an important distinction to me. I prefer is_type<T>
> because that tends to be how any is used - the type is one of a fixed
> set of compile-time types.
>
> However, if I do need to compare the type of an any to a *runtime*
> type of something else, I still need to compare type_ids. So either
>
> a.type() == typeid(b)
> or
> a.is_type(typeid(b))
>
> (Although I don't see any advantage to the second.)
>
> Should there be both (is_type<T> and a.type())? Obviously just having
> the second can handle all cases (a.type() == typeid(T) instead of
> is_type<T>), but then we lose the distinction. Or at least it becomes
> very subtle.
>
>
What about a.is_type<decltype(b)>()? Perhaps is_type<T>() is enough (and
safer).
--
------=_Part_88_12922010.1358357038726
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>On Wednesday, January 16, 2013 4:49:17 PM UTC, Tony V E wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
1px #ccc solid;padding-left: 1ex;"><br>That looks like an important distin=
ction to me. I prefer is_type<T>
<br>because that tends to be how any is used - the type is one of a fixed
<br>set of compile-time types.
<br>
<br>However, if I do need to compare the type of an any to a *runtime*
<br>type of something else, I still need to compare type_ids. So eith=
er
<br>
<br>a.type() =3D=3D typeid(b)
<br>or
<br>a.is_type(typeid(b))
<br>
<br>(Although I don't see any advantage to the second.)
<br>
<br>
Should there be both (is_type<T> and a.type())? Obviously just =
having
<br>the second can handle all cases (a.type() =3D=3D typeid(T) instead of
<br>is_type<T>), but then we lose the distinction. Or at least =
it becomes
<br>very subtle.
<br>
<br></blockquote><div> </div><div> What about a.is_type<declty=
pe(b)>()? Perhaps is_type<T>() is enough (and safer).<br><br></div=
>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_88_12922010.1358357038726--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Wed, 16 Jan 2013 18:53:33 +0100
Raw View
This is a multi-part message in MIME format.
--------------060808050408090307020301
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Should there be both (is_type<T> and a.type())? Obviously just
> having
> the second can handle all cases (a.type() == typeid(T) instead of
> is_type<T>), but then we lose the distinction. Or at least it
> becomes
> very subtle.
>
> What about a.is_type<decltype(b)>()? Perhaps is_type<T>() is enough
> (and safer).
>
No, I think you still need to be able to get the type_info out of the
any. Maybe for ordering, maybe to use as a key in container or perhaps
you want to log any.type().name().
We should have both imho.
Mikael
--
--------------060808050408090307020301
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<blockquote
cite="mid:92212651-6b1b-49e1-8097-3be6b465af20@isocpp.org"
type="cite">
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Should there be both (is_type<T> and a.type())? Obviously
just having
<br>
the second can handle all cases (a.type() == typeid(T) instead
of
<br>
is_type<T>), but then we lose the distinction. Or at
least it becomes
<br>
very subtle.
<br>
<br>
</blockquote>
<div> </div>
<div> What about a.is_type<decltype(b)>()? Perhaps
is_type<T>() is enough (and safer).<br>
<br>
</div>
</blockquote>
No, I think you still need to be able to get the type_info out of
the any. Maybe for ordering, maybe to use as a key in container or
perhaps you want to log any.type().name().<br>
We should have both imho.<br>
<br>
Mikael<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------060808050408090307020301--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 16 Jan 2013 15:36:36 -0500
Raw View
On Wed, Jan 16, 2013 at 12:23 PM, Cassio Neri <cassio.neri@gmail.com> wrote:
>>
>
> What about a.is_type<decltype(b)>()? Perhaps is_type<T>() is enough (and
> safer).
>
that only checks the compile time type of b, not the runtime type.
How do I check if a contains the runtime type of b?
--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Wed, 16 Jan 2013 14:19:01 -0800 (PST)
Raw View
------=_Part_118_5442056.1358374741964
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 10, 2013 5:56:20 PM UTC+4, Paul Smith wrote:
>
>
> * Why do the constructors and assignment operators doesn't take a
> reference (i.e. ValueType&&)?
>
+1, that implies unnecessary overhead.
On Thursday, January 10, 2013 6:12:28 PM UTC+4, Nevin ":-)" Liber wrote:
>
> On Jan 10, 2013, at 7:28 AM, Chris Jefferson <ch...@bubblescope.net>
> wrote:
>
> > I don't see any particular reason to require ValueType is
> CopyConstructable.
>
> The requirement is there because any has to have a copy constructor no
> matter what type is stored in it, unless you want to change its
> semantics to throw on copying when holding non-copyable types.
>
Theoretically it's possible to have two classes: non-copyable 'any' and
copyable 'copyable_any'.
copyable_any c = 5; // c holds value 5
any m = std::unique_ptr<int>(new int); // m holds the smart pointer
m = c; // m holds value 5
Example of partial implementation (I didn't check it thoroughly):
http://liveworkspace.org/code/ZrKiR$0
--
------=_Part_118_5442056.1358374741964
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, January 10, 2013 5:56:20 PM UTC+4, Paul Smith wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div><br></div><div>* Why do the constru=
ctors and assignment operators doesn't take a reference (i.e. ValueType&=
;&)?</div></blockquote><div><br>+1, that implies unnecessary overhead.<=
/div><br>On Thursday, January 10, 2013 6:12:28 PM UTC+4, Nevin ":-)" Liber =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Jan 10, 2013, at 7:28=
AM, Chris Jefferson <<a target=3D"_blank">ch...@bubblescope.net</a>>=
wrote:
<br>
<br>> I don't see any particular reason to require ValueType is CopyCons=
tructable.
<br>
<br>The requirement is there because any has to have a copy constructor no
<br>matter what type is stored in it, unless you want to change its
<br>semantics to throw on copying when holding non-copyable types.<br></blo=
ckquote><br>Theoretically it's possible to have two classes: non-copyable '=
any' and copyable 'copyable_any'.<br><br> copyable_any c =
=3D 5; // c holds value 5<br> any m =3D std::unique_ptr&l=
t;int>(new int); // m holds the smart pointer<br> m =
=3D c; // m holds value 5<br><br>Example of partial implementation (I didn'=
t check it thoroughly): http://liveworkspace.org/code/ZrKiR$0
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_118_5442056.1358374741964--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 16 Jan 2013 14:25:36 -0800 (PST)
Raw View
------=_Part_27_3405093.1358375136407
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, January 16, 2013 12:36:36 PM UTC-8, Tony V E wrote:
>
> On Wed, Jan 16, 2013 at 12:23 PM, Cassio Neri <cassi...@gmail.com<javascript:>>
> wrote:
> >>
> >
> > What about a.is_type<decltype(b)>()? Perhaps is_type<T>() is enough
> (and
> > safer).
> >
>
> that only checks the compile time type of b, not the runtime type.
> How do I check if a contains the runtime type of b?
>
You don't.
The idea with `any` is that it stores *exactly* what you tell it to. If you
give it some class `B`, that's what it stores. The fact that `B` might be
derived from `A` is irrelevant; you gave it a `B`, so that's what the `any`
stores.
And most importantly of all... you can't get *anything else* from it. If
you gave the `any` a `B`, and the receiver of that `any` expected an `A`,
then you have a miscommunication between the two sides that needs to be
sorted out. The receiver of an `any` should be casting it to exactly what
the sender provided.
Remember: `any` uses value semantics. So it can slice derived classes and
such (assuming you don't put a pointer to `B` in the `any`. In which case
you still have to `any_cast` it into a pointer-to-`B`, then convert it into
the base class).
--
------=_Part_27_3405093.1358375136407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, January 16, 2013 12:36:36 PM UTC-8, Tony V E wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Wed, Jan 16, 2013 at 12:23 PM=
, Cassio Neri <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"OIMJAuH5Jw0J">cassi...@gmail.com</a>> wrote:
<br>>>
<br>>
<br>> What about a.is_type<decltype(b)>()? Perhaps is_type&l=
t;T>() is enough (and
<br>> safer).
<br>>
<br>
<br>that only checks the compile time type of b, not the runtime type.
<br>How do I check if a contains the runtime type of b?
<br></blockquote><div><br>You don't.<br><br>The idea with `any` is that it =
stores <i>exactly</i> what you tell it to. If you give it some class `B`, t=
hat's what it stores. The fact that `B` might be derived from `A` is irrele=
vant; you gave it a `B`, so that's what the `any` stores.<br><br>And most i=
mportantly of all... you can't get <i>anything else</i> from it. If you gav=
e the `any` a `B`, and the receiver of that `any` expected an `A`, then you=
have a miscommunication between the two sides that needs to be sorted out.=
The receiver of an `any` should be casting it to exactly what the sender p=
rovided.<br><br>Remember: `any` uses value semantics. So it can slice deriv=
ed classes and such (assuming you don't put a pointer to `B` in the `any`. =
In which case you still have to `any_cast` it into a pointer-to-`B`, then c=
onvert it into the base class).<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_27_3405093.1358375136407--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Thu, 17 Jan 2013 00:45:42 -0800 (PST)
Raw View
------=_Part_502_18353075.1358412342798
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 17, 2013 2:19:01 AM UTC+4, Nikolay Ivchenkov wrote:
>
>
> Example of partial implementation (I didn't check it thoroughly):
> http://liveworkspace.org/code/ZrKiR$0
Correct reference:
http://liveworkspace.org/code/ZrKiR$1
--
------=_Part_502_18353075.1358412342798
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, January 17, 2013 2:19:01 AM UTC+4, Nikolay Ivchenkov wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><br>Example of partial implementa=
tion (I didn't check it thoroughly): <a href=3D"http://liveworkspace.org/co=
de/ZrKiR$0" target=3D"_blank">http://liveworkspace.org/code/<wbr>ZrKiR$0</a=
></blockquote><div><br>Correct reference:<br>http://liveworkspace.org/code/=
ZrKiR$1 <br></div><div> </div><div> </div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_502_18353075.1358412342798--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 17 Jan 2013 08:57:47 -0500
Raw View
On Wed, Jan 16, 2013 at 5:25 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Wednesday, January 16, 2013 12:36:36 PM UTC-8, Tony V E wrote:
>>
>> On Wed, Jan 16, 2013 at 12:23 PM, Cassio Neri <cassi...@gmail.com> wrote:
>> >>
>> >
>> > What about a.is_type<decltype(b)>()? Perhaps is_type<T>() is enough
>> > (and
>> > safer).
>> >
>>
>> that only checks the compile time type of b, not the runtime type.
>> How do I check if a contains the runtime type of b?
>
>
> You don't.
>
> The idea with `any` is that it stores exactly what you tell it to. If you
> give it some class `B`, that's what it stores. The fact that `B` might be
> derived from `A` is irrelevant; you gave it a `B`, so that's what the `any`
> stores.
>
> And most importantly of all... you can't get anything else from it. If you
> gave the `any` a `B`, and the receiver of that `any` expected an `A`, then
> you have a miscommunication between the two sides that needs to be sorted
> out. The receiver of an `any` should be casting it to exactly what the
> sender provided.
>
> Remember: `any` uses value semantics. So it can slice derived classes and
> such (assuming you don't put a pointer to `B` in the `any`. In which case
> you still have to `any_cast` it into a pointer-to-`B`, then convert it into
> the base class).
>
I agree that this is _almost_ always what you want. Which is why I
like is_type<T> better.
But there may be the odd case where you really need to compare against
the runtime type.
Or just for debugging.
Tony
--
.
Author: Nevin Liber <nliber@gmail.com>
Date: Thu, 17 Jan 2013 08:07:14 -0600
Raw View
On Jan 17, 2013, at 7:57 AM, Tony V E <tvaneerd@gmail.com> wrote:
> I agree that this is _almost_ always what you want. Which is why I
> like is_type<T> better.
> But there may be the odd case where you really need to compare against
> the runtime type.
Could you post some code? I'm not seeing how you would put a derived
type inside an any (but it is early in the morning for me :-)).
--
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Thu, 17 Jan 2013 15:17:41 +0100
Raw View
>> I agree that this is _almost_ always what you want. Which is why I
>> like is_type<T> better.
>> But there may be the odd case where you really need to compare against
>> the runtime type.
> Could you post some code? I'm not seeing how you would put a derived
> type inside an any (but it is early in the morning for me :-)).
>
I think he means something along the lines of..
struct A {
virtual ~A();
....
};
bool func( A const& a, std::any any ) {
return typeid(a) == any.type();
}
Does the any contain same type which is the a's most derived type.
That said, I don't really see how to use it.. but I believe we need to
get the type_info out of the any anyhow, for different reasons.
I would promote the 'is(_type)' for normal cases.
Mikael
--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 17 Jan 2013 09:23:27 -0500
Raw View
On Thu, Jan 17, 2013 at 9:07 AM, Nevin Liber <nliber@gmail.com> wrote:
> On Jan 17, 2013, at 7:57 AM, Tony V E <tvaneerd@gmail.com> wrote:
>
>> I agree that this is _almost_ always what you want. Which is why I
>> like is_type<T> better.
>> But there may be the odd case where you really need to compare against
>> the runtime type.
>
> Could you post some code? I'm not seeing how you would put a derived
> type inside an any (but it is early in the morning for me :-)).
>
I don't think it is always that you put a derived type in, but in
general, you may not know the type put in.
For example, take a look at the various ways Qt's QVariant is used.
One example is as an "extra data" field to Widget-like classes. What
we previously did with void *. Like GetWindowLong(GWL_USERDATA) under
Windows.
Here you are just holding onto data for some other class - you never
use it directly, just give it back later.
So sure, that probably means you don't need to know the type, it is
just "passing through". But you might want it for debugging.
But another use case is generic data transport - QVariantMap is a map
of string -> QVariant, and since the QVariant could be another
QVariantMap, you know have a runtime hierarchical data structure. So I
can build
QVariantMap:
{
"Corners" = QVariantMap:
{
"TopLeft" -> Point:
{
x = 10
y = 20
},
"TopRight",
...
}
"Name" = "Widget"
...
}
Now, if all the types in the hierarchy are known, I can write that out
to something like JSON. I can write a library function that does that
for you.
And more importantly, unserialize it as well.
Now, if you throw your own type in there, I can either skip your type
or output an error, or call obj->toString, or maybe for std::any call
some callback function - passing the typeid - for you to handle the
custom types.
Now maybe a more traditional way would be either using compile-time
types and something like <<, or using OOP and obj->toString() or
similar, but I can also imagine doing it with typeid().
Tony
--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 17 Jan 2013 09:24:50 -0600
Raw View
--000e0cd3b600f205bf04d37d9a10
Content-Type: text/plain; charset=ISO-8859-1
On 17 January 2013 08:23, Tony V E <tvaneerd@gmail.com> wrote:
> On Thu, Jan 17, 2013 at 9:07 AM, Nevin Liber <nliber@gmail.com> wrote:
> > On Jan 17, 2013, at 7:57 AM, Tony V E <tvaneerd@gmail.com> wrote:
> >
> >> I agree that this is _almost_ always what you want. Which is why I
> >> like is_type<T> better.
> >> But there may be the odd case where you really need to compare against
> >> the runtime type.
> >
> > Could you post some code? I'm not seeing how you would put a derived
> > type inside an any (but it is early in the morning for me :-)).
> >
>
>
> I don't think it is always that you put a derived type in, but in
> general, you may not know the type put in.
> For example, take a look at the various ways Qt's QVariant is used.
>
Isn't QVariant like Boost.Variant (but not quite as general)? A variant
holds 1 of a bounded list of types; that is different than any, which holds
1 of an unbounded list of types.
It sounds like you want a mechanism like dynamic_cast but more general, as
it should work for any type.
If this is possible, you should be able to prototype it with Boost.Type
Erasure. It sounds like a *lot* of additional complexity, but I could be
persuaded by a prototype implementation.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--000e0cd3b600f205bf04d37d9a10
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 17 January 2013 08:23, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:=
tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">On Thu, Jan 17, 2013 at 9:07 AM, Ne=
vin Liber <<a href=3D"mailto:nliber@gmail.com">nliber@gmail.com</a>> =
wrote:<br>
> On Jan 17, 2013, at 7:57 AM, Tony V E <<a href=3D"mailto:tvaneerd@g=
mail.com">tvaneerd@gmail.com</a>> wrote:<br>
><br>
>> I agree that this is _almost_ always what you want. =A0Which is wh=
y I<br>
>> like is_type<T> better.<br>
>> But there may be the odd case where you really need to compare aga=
inst<br>
>> the runtime type.<br>
><br>
> Could you post some code? =A0I'm not seeing how you would put a de=
rived<br>
> type inside an any (but it is early in the morning for me :-)).<br>
><br>
<br>
<br>
</div></div>I don't think it is always that you put a derived type in, =
but in<br>
general, you may not know the type put in.<br>
For example, take a look at the various ways Qt's QVariant is used.<br>=
</blockquote><div><br>Isn't QVariant like Boost.Variant (but not quite =
as general)?=A0 A variant holds 1 of a bounded list of types; that is diffe=
rent than any, which holds 1 of an unbounded list of types.<br>
<br>It sounds like you want a mechanism like dynamic_cast but more general,=
as it should work for any type.<br><br>If this is possible, you should be =
able to prototype it with Boost.Type Erasure.=A0 It sounds like a *lot* of =
additional complexity, but I could be persuaded by a prototype implementati=
on.<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
<p></p>
-- <br />
<br />
<br />
<br />
--000e0cd3b600f205bf04d37d9a10--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Thu, 17 Jan 2013 08:23:54 -0800 (PST)
Raw View
------=_Part_695_26191162.1358439834673
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 17, 2013 3:23:27 PM UTC+1, Tony V E wrote:
> I don't think it is always that you put a derived type in, but in
> general, you may not know the type put in.
>
You *always* know the type you put in. The any stores its own copy of the
value, so you can't give it a reference to a base class that is actually a
derived class. The instance will be sliced and only the base-part will
persist in the any object. This is similar to assigning the value of a
derived to a base.
--
------=_Part_695_26191162.1358439834673
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, January 17, 2013 3:23:27 PM UTC+1, Tony V E wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">I don't think it is always that you pu=
t a derived type in, but in
<br>general, you may not know the type put in.
<br></blockquote><div><br></div><div>You *always* know the type you put in.=
The any stores its own copy of the value, so you can't give it a reference=
to a base class that is actually a derived class. The instance will be sli=
ced and only the base-part will persist in the any object. This is similar =
to assigning the value of a derived to a base. </div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_695_26191162.1358439834673--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 17 Jan 2013 10:56:05 -0600
Raw View
--001517475cb05be3e204d37ee1c2
Content-Type: text/plain; charset=ISO-8859-1
On 17 January 2013 10:23, Sylvester Hesp <s.hesp@oisyn.nl> wrote:
> On Thursday, January 17, 2013 3:23:27 PM UTC+1, Tony V E wrote:
>
>> I don't think it is always that you put a derived type in, but in
>> general, you may not know the type put in.
>>
>
> You *always* know the type you put in. The any stores its own copy of the
> value, so you can't give it a reference to a base class that is actually a
> derived class. The instance will be sliced and only the base-part will
> persist in the any object. This is similar to assigning the value of a
> derived to a base.
>
You may want to ask type questions, such as:
struct B { virtual ~B() = default; };
struct D : B {};
any a = D();
// ...
auto& b = a.convert_to<B&>() // throw if not convertible to B&
That being said, I don't see how to implement it w/o adding run time
reflection to the language, which is well beyond this library proposal.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--001517475cb05be3e204d37ee1c2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 17 January 2013 10:23, Sylvester Hesp <span dir=3D"ltr"><<a href=3D"m=
ailto:s.hesp@oisyn.nl" target=3D"_blank">s.hesp@oisyn.nl</a>></span> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Thursday, January 17, 2013 3:23:27 PM UTC+1, Tony V E =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex">I don't think it is a=
lways that you put a derived type in, but in
<br>general, you may not know the type put in.
<br></blockquote><div><br></div></div><div>You *always* know the type you p=
ut in. The any stores its own copy of the value, so you can't give it a=
reference to a base class that is actually a derived class. The instance w=
ill be sliced and only the base-part will persist in the any object. This i=
s similar to assigning the value of a derived to a base.=A0</div>
</blockquote><div><br>You may want to ask type questions, such as:<br><br>s=
truct B { virtual ~B() =3D default; };<br>struct D : B {};<br><br>any a =3D=
D();<br><br>// ...<br>auto& b =3D a.convert_to<B&>() // thro=
w if not convertible to B&<br>
<br><br>That being said, I don't see how to implement it w/o adding run=
time reflection to the language, which is well beyond this library proposa=
l.<br></div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a hr=
ef=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.c=
om</a>>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
<br />
<br />
--001517475cb05be3e204d37ee1c2--
.
Author: Paul Smith <pl.smith.mail@gmail.com>
Date: Thu, 17 Jan 2013 19:15:50 +0200
Raw View
On Thu, Jan 17, 2013 at 6:23 PM, Sylvester Hesp <s.hesp@oisyn.nl> wrote:
> On Thursday, January 17, 2013 3:23:27 PM UTC+1, Tony V E wrote:
>>
>> I don't think it is always that you put a derived type in, but in
>> general, you may not know the type put in.
>
>
> You *always* know the type you put in.
You always know the stored type... at the point of store.
There could be all sorts of reasons to want to query the type of the
value instead of just testing for a specific type. Dynamic-dispatching
is probably the most prominent example, even though it's arguable that
'any' isn't necessarily the best tool for the job.
At any rate, I don't see a simple way to implement 'a.is_type<T>()'
other than 'a.type() == typeid(T)' (which really isn't *that* much
worse).
--
Paul Smith
--
.
Author: Cassio Neri <cassio.neri@gmail.com>
Date: Thu, 17 Jan 2013 09:25:28 -0800 (PST)
Raw View
------=_Part_769_7846322.1358443528886
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 17, 2013 1:57:47 PM UTC, Tony V E wrote:
>
>
> I agree that this is _almost_ always what you want. Which is why I
> like is_type<T> better.
> But there may be the odd case where you really need to compare against
> the runtime type.
> Or just for debugging.
>
Although I prefer is_type<T>() over type(), if the latter goes through and
since
the former can be implemented in terms of the latter, I would rather drop
is_type<T>().
There is another issue regarding one constructor and type(). Recall one of
Paul Smith's question:
> Why do the constructors and assignment operators doesn't take a reference
(i.e. ValueType&&)?
Let's also assume that the proposal is changed (+1 from me) and the
signature
becomes:
template <typename ValueType>
any(ValueType&& value);
Then, the description of this constructor and that of type() will require
more
clarification. Currently it says:
Constructor effects: Constructs an object of type any with initial content
equivalent in both type and value to value.
type() returns: The typeid of the contained value if instance is non-empty,
otherwise typeid(void).
The proposal isn't clear on what the "equivalent value" is (static?
dynamic?).
For instance, consider these to possible (partial) implementations:
struct any1 {
const std::type_info& type_;
template <typename ValueType>
any1(ValueType&& value) : type_(typeid(ValueType)) { }
const std::type_info& type() const { return type_; }
};
The second implementation, let's call it any2, is similar to any1 except
for the
constructor:
template <typename ValueType>
any2(ValueType&& value) : type_(typeid(value)) {}
Then, consider
struct A { virtual ~A() {} };
struct B : public A {};
B b;
A& a(b);
any1 a1(a);
assert(a1.type() == typeid(A));
assert(a1.type() != typeid(a));
any2 a2(a);
assert(a2.type() != typeid(A));
assert(a2.type() == typeid(a));
Hence, the result of type() very much depends on the implementation of the
constructor and I think the current draft is not very clear on what an
implementation should do. I emphasize that this problem doesn't occur if the
constructor's signature is kept as it is now (taking value by copy rather
than
reference).
The boost implementation gives similar results to any1.
HTH,
Cassio.
--
------=_Part_769_7846322.1358443528886
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, January 17, 2013 1:57:47 PM UTC, Tony V E wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><br>I agree that this is _almost_ always wha=
t you want. Which is why I
<br>like is_type<T> better.
<br>But there may be the odd case where you really need to compare against
<br>the runtime type.
<br>Or just for debugging.
<br></blockquote><div><br>Although I prefer is_type<T>() over type(),=
if the latter goes through and since<br>the former can be implemented in t=
erms of the latter, I would rather drop<br>is_type<T>().<br><br>There=
is another issue regarding one constructor and type(). Recall one of<br>Pa=
ul Smith's question:<br><br>> Why do the constructors and assignment ope=
rators doesn't take a reference<br>(i.e. ValueType&&)?<br><br>Let's=
also assume that the proposal is changed (+1 from me) and the signature<br=
>becomes:<br><br>template <typename ValueType><br>any(ValueType&&=
amp; value);<br><br>Then, the description of this constructor and that of t=
ype() will require more<br>clarification. Currently it says:<br><br>Constru=
ctor effects: Constructs an object of type any with initial content<br>equi=
valent in both type and value to value.<br><br>type() returns: The typeid o=
f the contained value if instance is non-empty,<br>otherwise typeid(void).<=
br><br>The proposal isn't clear on what the "equivalent value" is (static? =
dynamic?).<br>For instance, consider these to possible (partial) implementa=
tions:<br><br>struct any1 {<br> const std::type_info& type_;<br>&=
nbsp; <br> template <typename ValueType><br> any1(V=
alueType&& value) : type_(typeid(ValueType)) { }<br><br> cons=
t std::type_info& type() const { return type_; }<br>};<br><br>The secon=
d implementation, let's call it any2, is similar to any1 except for the<br>=
constructor:<br><br> template <typename ValueType><br> an=
y2(ValueType&& value) : type_(typeid(value)) {}<br><br>Then, consid=
er<br><br>struct A { virtual ~A() {} };<br>struct B : public A {};<br><br>B=
b;<br>A& a(b);<br><br>any1 a1(a);<br>assert(a1.type() =3D=3D typeid(A)=
);<br>assert(a1.type() !=3D typeid(a));<br><br>any2 a2(a);<br>assert(a2.typ=
e() !=3D typeid(A));<br>assert(a2.type() =3D=3D typeid(a));<br><br>Hence, t=
he result of type() very much depends on the implementation of the<br>const=
ructor and I think the current draft is not very clear on what an<br>implem=
entation should do. I emphasize that this problem doesn't occur if the<br>c=
onstructor's signature is kept as it is now (taking value by copy rather th=
an<br>reference).<br><br>The boost implementation gives similar results to =
any1.<br><br>HTH,<br>Cassio.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_769_7846322.1358443528886--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 17 Jan 2013 09:47:48 -0800 (PST)
Raw View
------=_Part_269_5693985.1358444868815
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 17, 2013 9:15:50 AM UTC-8, Paul Smith wrote:
>
> On Thu, Jan 17, 2013 at 6:23 PM, Sylvester Hesp <s.h...@oisyn.nl<javascript:>>
> wrote:
> > On Thursday, January 17, 2013 3:23:27 PM UTC+1, Tony V E wrote:
> >>
> >> I don't think it is always that you put a derived type in, but in
> >> general, you may not know the type put in.
> >
> >
> > You *always* know the type you put in.
>
> You always know the stored type... at the point of store.
> There could be all sorts of reasons to want to query the type of the
> value instead of just testing for a specific type. Dynamic-dispatching
> is probably the most prominent example, even though it's arguable that
> 'any' isn't necessarily the best tool for the job.
>
And that's exactly why we shouldn't support it through `any`.
Remember: `any` is only intended to be a value-semantic, type-safe version
of a `void*`. And C++ does not allow you to cast a `void*` to anything
except what you originally cast it from. Even base classes.
If we want dynamic dispatching in the language or a library, then we need
to create language/library features that are intended to solve that
specific problem. Co-opting `any` for that purpose only dilutes `any`.
--
------=_Part_269_5693985.1358444868815
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, January 17, 2013 9:15:50 AM UTC-8, Paul Smith wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On Thu, Jan 17, 2013 at 6:23 PM, Sylvest=
er Hesp <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"tufdkiO6kXYJ">s.h...@oisyn.nl</a>> wrote:
<br>> On Thursday, January 17, 2013 3:23:27 PM UTC+1, Tony V E wrote:
<br>>>
<br>>> I don't think it is always that you put a derived type in, but=
in
<br>>> general, you may not know the type put in.
<br>>
<br>>
<br>> You *always* know the type you put in.
<br>
<br>You always know the stored type... at the point of store.
<br>There could be all sorts of reasons to want to query the type of the
<br>value instead of just testing for a specific type. Dynamic-dispatching
<br>is probably the most prominent example, even though it's arguable that
<br>'any' isn't necessarily the best tool for the job.<br></blockquote><div=
><br>And that's exactly why we shouldn't support it through `any`.<br><br>R=
emember: `any` is only intended to be a value-semantic, type-safe version o=
f a `void*`. And C++ does not allow you to cast a `void*` to anything excep=
t what you originally cast it from. Even base classes.<br><br>If we want dy=
namic dispatching in the language or a library, then we need to create lang=
uage/library features that are intended to solve that specific problem. Co-=
opting `any` for that purpose only dilutes `any`.</div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_269_5693985.1358444868815--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 17 Jan 2013 13:10:41 -0500
Raw View
On Thu, Jan 17, 2013 at 11:23 AM, Sylvester Hesp <s.hesp@oisyn.nl> wrote:
> On Thursday, January 17, 2013 3:23:27 PM UTC+1, Tony V E wrote:
>>
>> I don't think it is always that you put a derived type in, but in
>> general, you may not know the type put in.
>
>
> You *always* know the type you put in. The any stores its own copy of the
> value, so you can't give it a reference to a base class that is actually a
> derived class. The instance will be sliced and only the base-part will
> persist in the any object. This is similar to assigning the value of a
> derived to a base.
>
It need not have anything to do with derivation - you can have the
same thing with int and string:
*You* always know if you are the only one writing all the code in your app.
If you only write part of the code, you might be handed an any someone
else constructed.
Now, you may or may not be able to do much with that any, given that
you don't know what is in there, but you could poke at it and support
standard types: int, string, etc, but not unknown types, and be able
to do limited things when it is a known type.
Like interpolate it. Write an animation system. Supports keyframes
of any type info. If the types are known, they are interpolated from
value x0 to value x1. Has smooth interpolators for numbers, colours,
strings. For unknown types, it does "stair step" interpolation (ie at
half way point jumps from changes from x0 to x1, no interpolation).
Tony
--
.
Author: Cassio Neri <cassio.neri@gmail.com>
Date: Thu, 17 Jan 2013 10:18:03 -0800 (PST)
Raw View
------=_Part_172_18914068.1358446683367
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 17, 2013 4:56:05 PM UTC, Nevin ":-)" Liber wrote:
>
>
> You may want to ask type questions, such as:
>
> struct B { virtual ~B() = default; };
> struct D : B {};
>
> any a = D();
>
> // ...
> auto& b = a.convert_to<B&>() // throw if not convertible to B&
>
> That being said, I don't see how to implement it w/o adding run time
> reflection to the language, which is well beyond this library proposal.
>
There's a way based on C++98 features only but some might consider it as a
hack.
The basic idea is exploiting exceptions as a form of "dynamic cast" since
the
RTTI system is already clever enough (with no extra runtime reflection) to
catch
a B* when a D* is thrown.
Taking a slightly different example (notice that B doesn't need to be
polymorphic but the inheritance must be public), consider:
struct B { };
struct D : public B {};
any a = D();
b* b_ptr = a.convert_to<B>() // returns nullptr if not convertible to B
Suppose in this example that at construction time, a stores a D*, namely
ptr,
pointing to the constructor argument (or rather to a copy of it). Then,
convert_to could be implemented in this way:
template <typename T>
T* convert_to() const {
try { throw ptr; }
catch(T* t) { return t;}
catch(...) {}
return nullptr;
}
This works almost like a dynamic_cast except that it's much slower and it
fails
to detect whether a B* is a D* or not (even when B is polymorphic). On the
upper
side it works with non-polymorphic types (as this example shows).
For more on this topic, please, take a look at:
http://www.drdobbs.com/cpp/twisting-the-rtti-system-for-safe-dynami/229401004
Cheers,
Cassio.
--
------=_Part_172_18914068.1358446683367
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, January 17, 2013 4:56:05 PM UTC, Nevin ":-)" Liber wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><br><div class=3D"gmail_quote"><div=
>You may want to ask type questions, such as:<br><br>struct B { virtual ~B(=
) =3D default; };<br>struct D : B {};<br><br>any a =3D D();<br><br>// ...<b=
r>auto& b =3D a.convert_to<B&>() // throw if not convertible =
to B&<br>
<br>That being said, I don't see how to implement it w/o adding run time re=
flection to the language, which is well beyond this library proposal.<br></=
div></div></blockquote><div><br>There's a way based on C++98 features only =
but some might consider it as a hack.<br>The basic idea is exploiting excep=
tions as a form of "dynamic cast" since the<br>RTTI system is already cleve=
r enough (with no extra runtime reflection) to catch<br>a B* when a D* is t=
hrown.<br><br>Taking a slightly different example (notice that B doesn't ne=
ed to be<br>polymorphic but the inheritance must be public), consider:<br><=
br> struct B { };<br> struct D : public=
B {};<br> any a =3D D();<br> b* b_ptr =
=3D a.convert_to<B>() // returns nullptr if not convertible to B<br><=
br>Suppose in this example that at construction time, a stores a D*, namely=
ptr,<br>pointing to the constructor argument (or rather to a copy of it). =
Then,<br>convert_to could be implemented in this way:<br><br>template <t=
ypename T><br>T* convert_to() const {<br> try { throw =
ptr; }<br> catch(T* t) { return t;}<br> =
catch(...) {}<br> return nullptr;<br>}<br><br>This works=
almost like a dynamic_cast except that it's much slower and it fails<br>to=
detect whether a B* is a D* or not (even when B is polymorphic). On the up=
per<br>side it works with non-polymorphic types (as this example shows).<br=
><br>For more on this topic, please, take a look at:<br>http://www.drdobbs.=
com/cpp/twisting-the-rtti-system-for-safe-dynami/229401004<br><br>Cheers,<b=
r>Cassio.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_172_18914068.1358446683367--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 17 Jan 2013 13:24:33 -0500
Raw View
On Thu, Jan 17, 2013 at 10:24 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 17 January 2013 08:23, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> On Thu, Jan 17, 2013 at 9:07 AM, Nevin Liber <nliber@gmail.com> wrote:
>> > On Jan 17, 2013, at 7:57 AM, Tony V E <tvaneerd@gmail.com> wrote:
>> >
>> >> I agree that this is _almost_ always what you want. Which is why I
>> >> like is_type<T> better.
>> >> But there may be the odd case where you really need to compare against
>> >> the runtime type.
>> >
>> > Could you post some code? I'm not seeing how you would put a derived
>> > type inside an any (but it is early in the morning for me :-)).
>> >
>>
>>
>> I don't think it is always that you put a derived type in, but in
>> general, you may not know the type put in.
>> For example, take a look at the various ways Qt's QVariant is used.
>
>
> Isn't QVariant like Boost.Variant (but not quite as general)? A variant
> holds 1 of a bounded list of types; that is different than any, which holds
> 1 of an unbounded list of types.
>
I *think* QVariant is closer to any. When declaring one, you don't
give a list of types (it is not a template). However, not ALL types
can be put into a variant, at least not without some extra macros
around the type you want to put in. Qt has this a meta-data
system.... don't want to go into that.
Basically, I think QVariant is close enough to apply here.
> It sounds like you want a mechanism like dynamic_cast but more general, as
> it should work for any type.
>
Just to be clear, I don't really want it, at least not right now. I
just want to point out what you gain and lose with is_type<T> versus
type() == typeid(T). In case someone wants/needs it in the future.
We just need to decide if it is worth it. And knowing the tradeoffs
is the first step.
> If this is possible, you should be able to prototype it with Boost.Type
> Erasure. It sounds like a *lot* of additional complexity, but I could be
> persuaded by a prototype implementation.
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 17 Jan 2013 12:27:33 -0600
Raw View
--f46d0434c396c1078504d38028ba
Content-Type: text/plain; charset=ISO-8859-1
On 17 January 2013 11:25, Cassio Neri <cassio.neri@gmail.com> wrote:
> > Why do the constructors and assignment operators doesn't take a reference
> (i.e. ValueType&&)?
>
> Let's also assume that the proposal is changed (+1 from me) and the
> signature
> becomes:
>
> template <typename ValueType>
> any(ValueType&& value);
>
If it is that, we have to add wording so that any(any&) does the equivalent
of copy construction.
Also, I think the following case still has to work:
struct B { /* ... */ };
struct D : B { /* ... */ };
any a = D();
D& d = any_cast<D&>(a);
B& b = d;
a = b;
which can get tricky if you are doing the small object optimization.
Passing by value has none of those issues.
>
> The second implementation, let's call it any2, is similar to any1 except
> for the
> constructor:
>
> template <typename ValueType>
> any2(ValueType&& value) : type_(typeid(value)) {}
>
> Then, consider
>
> struct A { virtual ~A() {} };
> struct B : public A {};
>
> B b;
> A& a(b);
>
> any1 a1(a);
> assert(a1.type() == typeid(A));
> assert(a1.type() != typeid(a));
>
Also true:
>
> any2 a2(a);
> assert(a2.type() != typeid(A));
> assert(a2.type() == typeid(a));
>
assert(typeid(any_cast<A&>(a1)) != a1.type())
I would consider such an implementation to be a bug; I cannot see a
reasonable person thinking that the typeid stored is for an object more
derived than the actual type of the concrete object being held; storing the
"type before you sliced" would just be silly.
> --
>
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--f46d0434c396c1078504d38028ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 17 January 2013 11:25, Cassio Neri <span dir=3D"ltr"><<a href=3D"mail=
to:cassio.neri@gmail.com" target=3D"_blank">cassio.neri@gmail.com</a>></=
span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">> Why do the constructors and assignment operators doe=
sn't take a reference</div><div><div class=3D"im">(i.e. ValueType&&=
amp;)?<br><br></div>Let's also assume that the proposal is changed (+1 =
from me) and the signature<br>
becomes:<br><br>template <typename ValueType><br>any(ValueType&&a=
mp; value);<br></div></blockquote><div><br></div><div>If it is that, we hav=
e to add wording so that any(any&) does the equivalent of copy construc=
tion.</div>
<div><br></div><div>Also, I think the following case still has to work:</di=
v><div><br></div><div>struct B { /* ... */ };</div><div>struct D : B { /* .=
... */ };</div><div><br></div><div>any a =3D D();</div><div>D& d =3D any=
_cast<D&>(a);</div>
<div>B& b =3D d;</div><div>a =3D b;</div><div><br></div><div>which can =
get tricky if you are doing the small object optimization.</div><div><br></=
div><div>Passing by value has none of those issues.</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div><br>The second implementation, let's call it any2, is similar to a=
ny1 except for the<br>constructor:<br><br>=A0 template <typename ValueTy=
pe><br>=A0 any2(ValueType&& value) : type_(typeid(value)) {}<br>
<br>Then, consider<br><br>struct A { virtual ~A() {} };<br>struct B : publi=
c A {};<br><br>B b;<br>A& a(b);<br><br>any1 a1(a);<br>assert(a1.type() =
=3D=3D typeid(A));<br>assert(a1.type() !=3D typeid(a));<br></div></blockquo=
te>
<div><br></div><div>Also true:</div><div><br></div><div>=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div><br>any2 a2(a);<br>assert(a2.type() !=3D typeid(A=
));<br>
assert(a2.type() =3D=3D typeid(a));<br></div></blockquote><div><br></div><d=
iv>=A0assert(typeid(any_cast<A&>(a1)) !=3D a1.type())</div><div><=
br></div><div>I would consider such an implementation to be a bug; I cannot=
see a reasonable person thinking that the typeid stored is for an object m=
ore derived than the actual type of the concrete object being held; storing=
the "type before you sliced" would just be silly.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>--=A0</div></blockquote><=
/div>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@e=
viloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) =
691-1404
<p></p>
-- <br />
<br />
<br />
<br />
--f46d0434c396c1078504d38028ba--
.
Author: Chris Jefferson <chris@bubblescope.net>
Date: Thu, 17 Jan 2013 18:29:21 +0000
Raw View
On 17/01/13 13:57, Tony V E wrote:
>
> I agree that this is _almost_ always what you want. Which is why I
> like is_type<T> better.
> But there may be the odd case where you really need to compare against
> the runtime type.
> Or just for debugging.
Certainly for debugging I would want type(). At least that way I can get
the stupid object out of the any and find how some weird thing ended up
in there. With is_type, there is no way of finding out what is actually
buried in the any.
Chris
--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 17 Jan 2013 12:35:50 -0600
Raw View
--e0cb4efe29882b447504d38046bf
Content-Type: text/plain; charset=ISO-8859-1
On 17 January 2013 12:10, Tony V E <tvaneerd@gmail.com> wrote:
> It need not have anything to do with derivation - you can have the
> same thing with int and string:
>
But you cannot do it between any two *arbitrary* types. Some template
somewhere has to see both types together at compile time in order to
generate the code.
I can solve this for variant; I cannot solve it for any. if you have an
implementation that proves me wrong, I'd love to see it and be proven
wrong. :-) The best we can do is the type() function.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--e0cb4efe29882b447504d38046bf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 17 January 2013 12:10, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:=
tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">It need not have anything to do wit=
h derivation - you can have the</div></div>
same thing with int and string:<br></blockquote><div><br></div><div>But you=
cannot do it between any two *arbitrary* types. =A0Some template somewhere=
has to see both types together at compile time in order to generate the co=
de.</div>
<div><br></div><div>I can solve this for variant; I cannot solve it for any=
.. =A0if you have an implementation that proves me wrong, I'd love to se=
e it and be proven wrong. :-) =A0The best we can do is the type() function.=
</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
<p></p>
-- <br />
<br />
<br />
<br />
--e0cb4efe29882b447504d38046bf--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 17 Jan 2013 10:39:43 -0800 (PST)
Raw View
------=_Part_772_14799957.1358447983326
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 17, 2013 10:10:41 AM UTC-8, Tony V E wrote:
>
> On Thu, Jan 17, 2013 at 11:23 AM, Sylvester Hesp <s.h...@oisyn.nl<javascript:>>
> wrote:
> > On Thursday, January 17, 2013 3:23:27 PM UTC+1, Tony V E wrote:
> >>
> >> I don't think it is always that you put a derived type in, but in
> >> general, you may not know the type put in.
> >
> >
> > You *always* know the type you put in. The any stores its own copy of
> the
> > value, so you can't give it a reference to a base class that is actually
> a
> > derived class. The instance will be sliced and only the base-part will
> > persist in the any object. This is similar to assigning the value of a
> > derived to a base.
> >
>
> It need not have anything to do with derivation - you can have the
> same thing with int and string:
>
> *You* always know if you are the only one writing all the code in your
> app.
>
> If you only write part of the code, you might be handed an any someone
> else constructed.
> Now, you may or may not be able to do much with that any, given that
> you don't know what is in there, but you could poke at it and support
> standard types: int, string, etc, but not unknown types, and be able
> to do limited things when it is a known type.
>
Then what you want is a `variant`, not an `any`. `any` is for when you
would use a `void*`; `variant` is when you, the caller, and everyone
in-between knows what types you're talking about.
Anytime you're considering writing a switch over a set of types, like this:
any a;
if(a.type() == type_info(int)) then
{
}
else if(a.type() == type_info(float)) then
{
}
else if(a.type() == type_info(float)) then
{
}
else ...
If you have more than one `if` clause here, you should be using a `variant`
with a proper visitor class. `any` is for when both you and the person who
calls you know what type you're talking about, but nobody in-between needs
to know (sending messages and so forth). `variant` is for when the user has
multiple options for what to call.
If you want to keep your `variant` types hidden from the in-betweens, then
you can stick your `variant` inside an `any`. But ultimately, your test for
your `any` should be boolean: either the user used the right type, or they
have broken the contract.
Like interpolate it. Write an animation system. Supports keyframes
> of any type info. If the types are known, they are interpolated from
> value x0 to value x1. Has smooth interpolators for numbers, colours,
> strings. For unknown types, it does "stair step" interpolation (ie at
> half way point jumps from changes from x0 to x1, no interpolation).
>
Here, you're talking about a `variant` where one of the possible types *is*an `any`. That is, you support real operations for specific types, but for
the rest, you can use some default.
--
------=_Part_772_14799957.1358447983326
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, January 17, 2013 10:10:41 AM UTC-8, Tony V E wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 17, 2013 at 11:23 AM,=
Sylvester Hesp <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"NqInkZx7MtMJ">s.h...@oisyn.nl</a>> wrote:
<br>> On Thursday, January 17, 2013 3:23:27 PM UTC+1, Tony V E wrote:
<br>>>
<br>>> I don't think it is always that you put a derived type in, but=
in
<br>>> general, you may not know the type put in.
<br>>
<br>>
<br>> You *always* know the type you put in. The any stores its own copy=
of the
<br>> value, so you can't give it a reference to a base class that is ac=
tually a
<br>> derived class. The instance will be sliced and only the base-part =
will
<br>> persist in the any object. This is similar to assigning the value =
of a
<br>> derived to a base.
<br>>
<br>
<br>It need not have anything to do with derivation - you can have the
<br>same thing with int and string:
<br>
<br>*You* always know if you are the only one writing all the code in your =
app.
<br>
<br>If you only write part of the code, you might be handed an any someone
<br>else constructed.
<br>Now, you may or may not be able to do much with that any, given that
<br>you don't know what is in there, but you could poke at it and support
<br>standard types: int, string, etc, but not unknown types, and be able
<br>to do limited things when it is a known type.<br></blockquote><div><br>=
Then what you want is a `variant`, not an `any`. `any` is for when you woul=
d use a `void*`; `variant` is when you, the caller, and everyone in-between=
knows what types you're talking about.<br><br>Anytime you're considering w=
riting a switch over a set of types, like this:<br><br><div class=3D"pretty=
print" 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"subprettyprint"><span style=3D"=
color: #000;" class=3D"styled-by-prettify">any a</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">if</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">type</sp=
an><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: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> type_info</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">))</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">then</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></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 style=3D"co=
lor: #008;" class=3D"styled-by-prettify">else</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">if</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">type</spa=
n><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: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> type_info</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">float</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">))</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">then</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><s=
pan 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"co=
lor: #008;" class=3D"styled-by-prettify">else</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">if</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">type</spa=
n><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: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> type_info</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">float</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">))</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">then</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><s=
pan 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"co=
lor: #008;" class=3D"styled-by-prettify">else</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span></div></code></div><br>If you have more than =
one `if` clause here, you should be using a `variant` with a proper visitor=
class. `any` is for when both you and the person who calls you know what t=
ype you're talking about, but nobody in-between needs to know (sending mess=
ages and so forth). `variant` is for when the user has multiple options for=
what to call.<br><br>If you want to keep your `variant` types hidden from =
the in-betweens, then you can stick your `variant` inside an `any`. But ult=
imately, your test for your `any` should be boolean: either the user used t=
he right type, or they have broken the contract.<br><br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;">
Like interpolate it. Write an animation system. Supports keyfra=
mes
<br>of any type info. If the types are known, they are interpolated f=
rom
<br>value x0 to value x1. Has smooth interpolators for numbers, colou=
rs,
<br>strings. For unknown types, it does "stair step" interpolation (i=
e at
<br>half way point jumps from changes from x0 to x1, no interpolation).<br>=
</blockquote><div><br>Here, you're talking about a `variant` where one of t=
he possible types <i>is</i> an `any`. That is, you support real operations =
for specific types, but for the rest, you can use some default.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_772_14799957.1358447983326--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 17 Jan 2013 13:24:19 -0600
Raw View
--bcaec552451662710104d380f302
Content-Type: text/plain; charset=ISO-8859-1
On 17 January 2013 12:18, Cassio Neri <cassio.neri@gmail.com> wrote:
> There's a way based on C++98 features only but some might consider it as a
> hack.
> The basic idea is exploiting exceptions as a form of "dynamic cast" since
> the
> RTTI system is already clever enough (with no extra runtime reflection) to
> catch
> a B* when a D* is thrown.
>
I forgot about that trick. :-) Still, it only partially solves it; it
really implements convert_to_base, not general convertibility.Then,
> convert_to could be implemented in this way:
>
> template <typename T>
> T* convert_to() const {
> try { throw ptr; }
> catch(T* t) { return t;}
> catch(...) {}
> return nullptr;
> }
>
I think the internal holder would have to have a virtual function to do the
throwing, since it is the only think that keeps track of the actual type.
>
> http://www.drdobbs.com/cpp/twisting-the-rtti-system-for-safe-dynami/229401004
>
I wouldn't be against adding this functionality if people see a need, but I
don't plan on encouraging it either.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--bcaec552451662710104d380f302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 17 January 2013 12:18, Cassio Neri <span dir=3D"ltr"><<a href=3D"mail=
to:cassio.neri@gmail.com" target=3D"_blank">cassio.neri@gmail.com</a>></=
span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">There's a way based on C++98 features only but some m=
ight consider it as a hack.</div><div>The basic idea is exploiting exceptio=
ns as a form of "dynamic cast" since the<br>RTTI system is alread=
y clever enough (with no extra runtime reflection) to catch<br>
a B* when a D* is thrown.<br></div></blockquote><div><br></div><div>I forgo=
t about that trick. :-) =A0Still, it only partially solves it; it really im=
plements convert_to_base, not general convertibility.Then,</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div>convert_to could be implemented in this way:<br><br>template <typen=
ame T><br>T* convert_to() const {<br>=A0=A0=A0 try { throw ptr; }<br>=A0=
=A0=A0 catch(T* t) { return t;}<br>=A0=A0=A0 catch(...) {}<br>=A0=A0=A0 ret=
urn nullptr;<br>}<br>
</div></blockquote><div><br></div><div>I think the internal holder would ha=
ve to have a virtual function to do the throwing, since it is the only thin=
k that keeps track of the actual type.</div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div><a href=3D"http://www.drdobbs.com/cpp/twisting-the-rtti-system-for-saf=
e-dynami/229401004" target=3D"_blank">http://www.drdobbs.com/cpp/twisting-t=
he-rtti-system-for-safe-dynami/229401004</a></div></blockquote><div><br></d=
iv>
<div>I wouldn't be against adding this functionality if people see a ne=
ed, but I don't plan on encouraging it either.=A0</div></div>-- <br>=A0=
Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverl=
ord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
<br />
<br />
--bcaec552451662710104d380f302--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 17 Jan 2013 13:31:51 -0600
Raw View
--bcaec55245166b8a9004d3810e4e
Content-Type: text/plain; charset=ISO-8859-1
On 17 January 2013 12:24, Tony V E <tvaneerd@gmail.com> wrote:
> I *think* QVariant is closer to any.
>
QVariant holds 1 object of a bounded number of known types. An
instantiation of boost::variant holds a 1 object of a bounded number of
known types. any can hold 1 object of any type which meets
CopyConstructible. That distinction is key.
> When declaring one, you don't
> give a list of types (it is not a template).
Sure, it already knows all the types it can hold; it cannot hold arbitrary
types.
> Basically, I think QVariant is close enough to apply here.
>
It isn't; it is much closer to an instance of variant.
> We just need to decide if it is worth it.
>
First it has to be possible. While it certainly is for variant, I don't
believe it is for any; please implement it and prove me wrong. :-)
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--bcaec55245166b8a9004d3810e4e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 17 January 2013 12:24, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:=
tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">I *think* QVariant is closer to any.</div></blockquote><d=
iv><br></div><div>QVariant holds 1 object of a bounded number of known type=
s. =A0An instantiation of boost::variant holds a 1 object of a bounded numb=
er of known types. =A0any can hold 1 object of any type which meets CopyCon=
structible. =A0That distinction is key.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"> =A0When dec=
laring one, you don't</div>
give a list of types (it is not a template).</blockquote><div><br></div><di=
v>Sure, it already knows all the types it can hold; it cannot hold arbitrar=
y types.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Basically, I think QVariant is close enough to apply here.<br></blockquote>=
<div><br></div><div>It isn't; it is much closer to an instance of varia=
nt.=A0</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">We just need to decide if it is worth it.</div></blockquo=
te><div><br></div><div>First it has to be possible. =A0While it certainly i=
s for variant, I don't believe it is for any; please implement it and p=
rove me wrong. :-)</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
<p></p>
-- <br />
<br />
<br />
<br />
--bcaec55245166b8a9004d3810e4e--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 17 Jan 2013 13:36:56 -0600
Raw View
--bcaec555559093f9e904d3812058
Content-Type: text/plain; charset=ISO-8859-1
To summarize my position:
I'm weakly against to changing the constructor to take ValueType by
universal reference instead of by value.
I'm strongly for type().
I'm weakly for is_type<T>().
I'm neutral on convert_to_base<>().
--
--bcaec555559093f9e904d3812058
Content-Type: text/html; charset=ISO-8859-1
To summarize my position:<div><br></div><div>I'm weakly against to changing the constructor to take ValueType by universal reference instead of by value.</div><div>I'm strongly for type().</div><div>I'm weakly for is_type<T>().</div>
<div>I'm neutral on convert_to_base<>().</div>
<p></p>
-- <br />
<br />
<br />
<br />
--bcaec555559093f9e904d3812058--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 17 Jan 2013 16:02:35 -0500
Raw View
On Thu, Jan 17, 2013 at 2:31 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 17 January 2013 12:24, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> I *think* QVariant is closer to any.
>
>
> QVariant holds 1 object of a bounded number of known types. An
> instantiation of boost::variant holds a 1 object of a bounded number of
> known types. any can hold 1 object of any type which meets
> CopyConstructible. That distinction is key.
>
I don't want to go on too much of a QVariant tangent. It is just an
example worth looking into how it is used. But...
QVariant can hold any CopyConstructible type (must also have zero-arg
constructor and public destructor).
Your type needs to be wrapped with a macro:
class MyType { };
Q_DECLARE_METATYPE(MyType);
So, yes, the number of types are known and bounded, but it is also the
same potential set as any - all copyable types in your app.
Depends on the meaning of "known", I guess. Who knows it and when.
>>
>> When declaring one, you don't
>> give a list of types (it is not a template).
>
>
> Sure, it already knows all the types it can hold; it cannot hold arbitrary
> types.
>
Depends on the meaning of arbitrary. See above.
>>
>> Basically, I think QVariant is close enough to apply here.
>
>
> It isn't; it is much closer to an instance of variant.
>
I think I could (maybe should) have done a search and replace of
QVariant with std::any in my email - I think main gist at least holds.
ie some of the things people do with QVariant, like in my example,
might be done with std::any.
Note sure if it _should_ be done, however.
>>
>> We just need to decide if it is worth it.
>
>
> First it has to be possible. While it certainly is for variant, I don't
> believe it is for any; please implement it and prove me wrong. :-)
I've lost track of what 'it' is :-). If it was magic dynamic_cast,
then maybe use that throw-catch magic. If it is just "this thing
contains an int, a string, or something I don't understand but maybe
this function over here could deal with it" then a series of if (this
type == that type) can deal with it.
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
>
Tony
--
.
Author: Jeffrey Yasskin <jyasskin@googlers.com>
Date: Thu, 17 Jan 2013 13:08:44 -0800
Raw View
On Wed, Jan 9, 2013 at 8:10 AM, Beman Dawes <bdawes@acm.org> wrote:
> A draft of the Any library proposal (Revision 2) is available.
>
> See http://beman.github.com/dot16/any-proposal.html
>
> As always, comments and corrections welcome!
This is something of a bikeshed comment. I expect to have some real
comments later after I've checked on Google's and Chrome's use of
concepts like this. Sorry for totally missing the mid-term mailing
deadline. :)
I'm wondering about the spelling of any_cast<T>(the_any). I see some
comments about an explicit conversion operator below, but no full
evaluation of the alternatives. It might be worth putting a discussion
like this into the paper if only to demonstrate that it's been
considered.
1) Why was any_cast<T>(the_any) chosen as the syntax in the first place?
2) Here are 3 alternatives with pros and cons. C++ could provide any
subset. What have I missed?
a) any_cast<T>(the_any)
Pro: Used by Boost.Any, presumably without many complaints.
Pro: Logically the operation is a cast.
Pro: Nice null-propagating behavior on pointers.
Con: I always read this as "pick any of static_cast, reinterpret_cast,
const_cast, or dynamic_cast, and apply it", which is wrong.
b) the_any.explicit operator T()
Pro: Really short initialization syntax: ExpectedType* t(the_any);
Pro: Helps establish a convention for conversions through explicit operators.
Con: More verbose call syntax: AFunction(static_cast<ExpectedType&>(the_any))
Con: This would be the first instance I can find where static_cast<T&>
could throw or static_cast<T*>(not_null) could return NULL.
Con: Can't use any_cast<>'s trick on pointers:
static_cast<ExpectedType*>(&the_any) tries to use the built-in
static_cast and compile-fails.
Con: Encourages less-safe casting: ExpectedType(the_any) is the
shortest way to call a function, but ExpectedType*(&the_any) likely
explodes at runtime.
c) the_any.as<T>() (or some other short method name, maybe cast<T>())
Pro: Fairly short, consistent conversion syntax: ExpectedType* t =
the_any.as<ExpectedType*>(); AFunction(the_any.as<ExpectedType&>()
Con: Can't use any_cast<>'s trick on pointers:
"static_cast<any*>(nullptr)->as<ExpectedType*>()" dereferences NULL
with undefined effects.
Con: This appears to be the first place we'd want to use a
ref-qualifier in the standard library.
I don't think any of the Cons are fatal, FWIW, just part of the tradeoff.
Jeffrey
--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 17 Jan 2013 16:20:05 -0500
Raw View
> c) the_any.as<T>() (or some other short method name, maybe cast<T>())
> Pro: Fairly short, consistent conversion syntax: ExpectedType* t =
> the_any.as<ExpectedType*>(); AFunction(the_any.as<ExpectedType&>()
> Con: Can't use any_cast<>'s trick on pointers:
> "static_cast<any*>(nullptr)->as<ExpectedType*>()" dereferences NULL
> with undefined effects.
FWIW, Technically, I don't think that dereferences NULL. The
implementation can check do:
if (this == nullptr)
return nullptr;
I'm not good at quoting chapter and verse, but I think this is allowed
(although somewhat scary).
Tony
--
.
Author: Paul Smith <pl.smith.mail@gmail.com>
Date: Thu, 17 Jan 2013 23:20:53 +0200
Raw View
On Thu, Jan 17, 2013 at 8:27 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 17 January 2013 11:25, Cassio Neri <cassio.neri@gmail.com> wrote:
>>
>> > Why do the constructors and assignment operators doesn't take a
>> > reference
>> (i.e. ValueType&&)?
>>
>> Let's also assume that the proposal is changed (+1 from me) and the
>> signature
>> becomes:
>>
>> template <typename ValueType>
>> any(ValueType&& value);
>
>
> If it is that, we have to add wording so that any(any&) does the equivalent
> of copy construction.
Right. But this is something we already do for other classes.
>
> Also, I think the following case still has to work:
>
> struct B { /* ... */ };
> struct D : B { /* ... */ };
>
> any a = D();
> D& d = any_cast<D&>(a);
> B& b = d;
> a = b;
>
> which can get tricky if you are doing the small object optimization.
I don't think this issue is specific to 'any', and I believe the
general rule is given by 17.6.4.9 [res.on.arguments] p1 b3. That is,
if an argument is bound to an rvalue-ref (which is not the case in
your example), the implementation is allowed to assume that it's a
unique reference. Whether or not we want to give a stronger guarantee
is a different question.
Anyway, I'm sure that there's a specific reason why those functions
don't take a reference, I was merely saying that it should be
explained in the proposal.
--
Paul Smith
--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 17 Jan 2013 15:24:23 -0600
Raw View
--e0cb4efe2988c7f9aa04d382a0f6
Content-Type: text/plain; charset=ISO-8859-1
On 17 January 2013 15:20, Tony V E <tvaneerd@gmail.com> wrote:
>
> FWIW, Technically, I don't think that dereferences NULL. The
> implementation can check do:
>
> if (this == nullptr)
> return nullptr;
>
A compiler can optimize that out, as this being null is undefined behavior.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--e0cb4efe2988c7f9aa04d382a0f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 17 January 2013 15:20, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:=
tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br>
</div>FWIW, Technically, I don't think that dereferences NULL. =A0The<b=
r>
implementation can check do:<br>
<br>
if (this =3D=3D nullptr)<br>
=A0 =A0return nullptr;<br></blockquote><div><br>A compiler can optimize tha=
t out, as this being null is undefined behavior.<br></div></div>-- <br>=A0N=
evin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlo=
rd.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
<br />
<br />
--e0cb4efe2988c7f9aa04d382a0f6--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 17 Jan 2013 15:32:15 -0600
Raw View
--f46d0408d6d90c875504d382bdf6
Content-Type: text/plain; charset=ISO-8859-1
On 17 January 2013 15:20, Paul Smith <pl.smith.mail@gmail.com> wrote:
>
> > Also, I think the following case still has to work:
> >
> > struct B { /* ... */ };
> > struct D : B { /* ... */ };
> >
> > any a = D();
> > D& d = any_cast<D&>(a);
> > B& b = d;
> > a = b;
> >
> > which can get tricky if you are doing the small object optimization.
>
> I don't think this issue is specific to 'any', and I believe the
> general rule is given by 17.6.4.9 [res.on.arguments] p1 b3. That is,
> if an argument is bound to an rvalue-ref (which is not the case in
> your example), the implementation is allowed to assume that it's a
> unique reference. Whether or not we want to give a stronger guarantee
> is a different question.
>
I don't think it is covered there. For instance, v.push_back(v.front()) is
legal for a vector, even if the vector has to grow. The trickiness comes
because the object being referenced is owned by the container.
> Anyway, I'm sure that there's a specific reason why those functions
> don't take a reference, I was merely saying that it should be
> explained in the proposal.
>
+1.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
--f46d0408d6d90c875504d382bdf6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 17 January 2013 15:20, Paul Smith <span dir=3D"ltr"><<a href=3D"mailt=
o:pl.smith.mail@gmail.com" target=3D"_blank">pl.smith.mail@gmail.com</a>>=
;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<br><div class=3D"im">
> Also, I think the following case still has to work:<br>
><br>
> struct B { /* ... */ };<br>
> struct D : B { /* ... */ };<br>
><br>
> any a =3D D();<br>
> D& d =3D any_cast<D&>(a);<br>
> B& b =3D d;<br>
> a =3D b;<br>
><br>
> which can get tricky if you are doing the small object optimization.<b=
r>
<br>
</div>I don't think this issue is specific to 'any', and I beli=
eve the<br>
general rule is given by 17.6.4.9 [res.on.arguments] p1 b3. That is,<br>
if an argument is bound to an rvalue-ref (which is not the case in<br>
your example), the implementation is allowed to assume that it's a<br>
unique reference. Whether or not we want to give a stronger guarantee<br>
is a different question.<br></blockquote><div><br>I don't think it is c=
overed there.=A0 For instance, v.push_back(v.front()) is legal for a vector=
, even if the vector has to grow.=A0 The trickiness comes because the objec=
t being referenced is owned by the container.<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
Anyway, I'm sure that there's a specific reason why those functions=
<br>
don't take a reference, I was merely saying that it should be<br>
explained in the proposal.<br></blockquote><div><br>+1.<br></div></div>-- <=
br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 69=
1-1404
<p></p>
-- <br />
<br />
<br />
<br />
--f46d0408d6d90c875504d382bdf6--
.
Author: Paul Smith <pl.smith.mail@gmail.com>
Date: Thu, 17 Jan 2013 23:50:33 +0200
Raw View
On Thu, Jan 17, 2013 at 11:32 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 17 January 2013 15:20, Paul Smith <pl.smith.mail@gmail.com> wrote:
>>
>>
>> > Also, I think the following case still has to work:
>> >
>> > struct B { /* ... */ };
>> > struct D : B { /* ... */ };
>> >
>> > any a = D();
>> > D& d = any_cast<D&>(a);
>> > B& b = d;
>> > a = b;
>> >
>> > which can get tricky if you are doing the small object optimization.
>>
>> I don't think this issue is specific to 'any', and I believe the
>> general rule is given by 17.6.4.9 [res.on.arguments] p1 b3. That is,
>> if an argument is bound to an rvalue-ref (which is not the case in
>> your example), the implementation is allowed to assume that it's a
>> unique reference. Whether or not we want to give a stronger guarantee
>> is a different question.
>
>
> I don't think it is covered there. For instance, v.push_back(v.front()) is
> legal for a vector, even if the vector has to grow. The trickiness comes
> because the object being referenced is owned by the container.
It isn't covered there, because this is another example of an argument
that binds to an lvalue reference. If it was 'v.insert(v.begin(),
move(v.back()))' I **think** there's nothing in the standard that
guarantees the "expected" behavior.
..
--
Paul Smith
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 17 Jan 2013 16:54:06 -0500
Raw View
On Thu, Jan 17, 2013 at 4:08 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> On Wed, Jan 9, 2013 at 8:10 AM, Beman Dawes <bdawes@acm.org> wrote:
>> A draft of the Any library proposal (Revision 2) is available.
>
> a) any_cast<T>(the_any)
> Pro: Used by Boost.Any, presumably without many complaints.
> Pro: Logically the operation is a cast.
> Pro: Nice null-propagating behavior on pointers.
> Con: I always read this as "pick any of static_cast, reinterpret_cast,
> const_cast, or dynamic_cast, and apply it", which is wrong.
>
so maybe a better name? Maybe we really want the *opposite* of "any"
because we are going from _any_ type to a specific type:
specific_cast<T>(the_any) ?
Alternatively, can we somehow instead get any::cast<T>(the_any)? (ie
are static member template functions allowed?)
Then it becomes clear the 'any' is referring to the "name-space" not
the type of cast. (And maybe ADL shortens that to just
cast<T>(the_any)).
> b) the_any.explicit operator T()
> Pro: Really short initialization syntax: ExpectedType* t(the_any);
> Pro: Helps establish a convention for conversions through explicit operators.
> Con: More verbose call syntax: AFunction(static_cast<ExpectedType&>(the_any))
> Con: This would be the first instance I can find where static_cast<T&>
> could throw or static_cast<T*>(not_null) could return NULL.
> Con: Can't use any_cast<>'s trick on pointers:
> static_cast<ExpectedType*>(&the_any) tries to use the built-in
> static_cast and compile-fails.
> Con: Encourages less-safe casting: ExpectedType(the_any) is the
> shortest way to call a function, but ExpectedType*(&the_any) likely
> explodes at runtime.
>
the throwing sounds like a show-stopper. Although isn't the rule
suppose to be "assume all code can throw" :-)
> c) the_any.as<T>() (or some other short method name, maybe cast<T>())
> Pro: Fairly short, consistent conversion syntax: ExpectedType* t =
> the_any.as<ExpectedType*>(); AFunction(the_any.as<ExpectedType&>()
> Con: Can't use any_cast<>'s trick on pointers:
> "static_cast<any*>(nullptr)->as<ExpectedType*>()" dereferences NULL
> with undefined effects.
> Con: This appears to be the first place we'd want to use a
> ref-qualifier in the standard library.
>
not useful on pointers is a big (medium?) one.
>
> I don't think any of the Cons are fatal, FWIW, just part of the tradeoff.
>
> Jeffrey
>
I agree it would be nice to see some discussion of the choice in the paper.
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 17 Jan 2013 16:02:49 -0600
Raw View
--f46d0401677d3a4e7604d3832a4d
Content-Type: text/plain; charset=ISO-8859-1
On 17 January 2013 15:54, Tony V E <tvaneerd@gmail.com> wrote:
> so maybe a better name? Maybe we really want the *opposite* of "any"
> because we are going from _any_ type to a specific type:
>
> specific_cast<T>(the_any) ?
>
Given that we have over a decade of existing practice with Boost.Any, I'm
loathe to break it just for bike shedding.
Putting a value in and getting access to that value are pretty much the two
most common operations; they should both be easy.
--
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 post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--f46d0401677d3a4e7604d3832a4d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 17 January 2013 15:54, Tony V E <span dir=3D"ltr"><<a href=3D"mailto:=
tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>></span> wro=
te:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
so maybe a better name? =A0Maybe we really want the *opposite* of "any=
"<br>
because we are going from _any_ type to a specific type:<br>
<br>
=A0 =A0specific_cast<T>(the_any) ?<br></blockquote><div><br>Given tha=
t we have over a decade of existing practice with Boost.Any, I'm loathe=
to break it just for bike shedding.<br><br>Putting a value in and getting =
access to that value are pretty much the two most common operations; they s=
hould both be easy.<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
<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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d0401677d3a4e7604d3832a4d--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Thu, 17 Jan 2013 16:14:24 -0600
Raw View
On Thu, Jan 17, 2013 at 3:54 PM, Tony V E <tvaneerd@gmail.com> wrote:
> Alternatively, can we somehow instead get any::cast<T>(the_any)? (ie
> are static member template functions allowed?)
Yea. Nice naming.
For me, I don't read `any_cast` as "any kinds of *_cast", but
I suppose that it is a richer `static_cast` instead of a function
template only working with `std::any` or `std::any*`. So such an
naming, `any::cast<T>` solves my problem.
> Then it becomes clear the 'any' is referring to the "name-space" not
> the type of cast. (And maybe ADL shortens that to just
> cast<T>(the_any)).
ADL does not work on a call with an explicitly specified template
argument.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Thu, 17 Jan 2013 14:27:47 -0800 (PST)
Raw View
------=_Part_553_21961080.1358461667233
Content-Type: text/plain; charset=ISO-8859-1
You always know the stored type... at the point of store.
> There could be all sorts of reasons to want to query the type of the
> value instead of just testing for a specific type.
Oh but I'm not arguing against being able to get the type_info of the
stored type - I very much like to see that.
- Sylvester
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_553_21961080.1358461667233
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
You always know the stored type... at the point of store. <br><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">There could be all sorts of reasons to=
want to query the type of the
<br>value instead of just testing for a specific type.</blockquote><div><br=
></div>Oh but I'm not arguing against being able to get the type_info of th=
e <br><div>stored type - I very much like to see that. </div><div=
><br></div><div>- Sylvester</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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_553_21961080.1358461667233--
.
Author: Nikolay Ivchenkov <tsoae@mail.ru>
Date: Fri, 18 Jan 2013 03:07:58 -0800 (PST)
Raw View
------=_Part_1263_1800757.1358507278508
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 17, 2013 10:27:33 PM UTC+4, Nevin ":-)" Liber wrote:
>
>
> Also, I think the following case still has to work:
>
> struct B { /* ... */ };
> struct D : B { /* ... */ };
>
> any a = D();
> D& d = any_cast<D&>(a);
> B& b = d;
> a = b;
>
> which can get tricky if you are doing the small object optimization.
>
It's easy to check if the small object optimization is used for the old
object and would be applied to new object (the later check can be performed
statically). Then an intermediate object could be created only when both
conditions hold.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_1263_1800757.1358507278508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, January 17, 2013 10:27:33 PM UTC+4, Nevin ":-)" Liber wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote"><br><=
div>Also, I think the following case still has to work:</div><div><br></div=
><div>struct B { /* ... */ };</div><div>struct D : B { /* ... */ };</div><d=
iv><br></div><div>any a =3D D();</div><div>D& d =3D any_cast<D&&=
gt;(a);</div>
<div>B& b =3D d;</div><div>a =3D b;</div><div><br></div><div>which can =
get tricky if you are doing the small object optimization.</div></div></blo=
ckquote><div><br>It's easy to check if the small object optimization is use=
d for the old object and would be applied to new object (the later check ca=
n be performed statically). Then an intermediate object could be created on=
ly when both conditions hold.<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 post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1263_1800757.1358507278508--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 18 Jan 2013 14:58:31 -0500
Raw View
On Thu, Jan 17, 2013 at 5:02 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 17 January 2013 15:54, Tony V E <tvaneerd@gmail.com> wrote:
>>
>> so maybe a better name? Maybe we really want the *opposite* of "any"
>> because we are going from _any_ type to a specific type:
>>
>> specific_cast<T>(the_any) ?
>
>
> Given that we have over a decade of existing practice with Boost.Any, I'm
> loathe to break it just for bike shedding.
>
does that go for any::cast<T> as well? I assume conversion from boost
-> std for existing code will involve some search and replace anyhow.
What does "break it" actually mean?
I do agree that there is value in that existing practice. Just wondering.
> Putting a value in and getting access to that value are pretty much the two
> most common operations; they should both be easy.
I actually don't like specific_cast<> because it is in the std
namespace, and you lose (somewhat) its association with std::any.
(Would there be other uses of specific_cast<> beyond any?).
any::cast<> doesn't have that problem.
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Beman Dawes <bdawes@acm.org>
Date: Mon, 21 Jan 2013 11:01:47 -0500
Raw View
On Thu, Jan 17, 2013 at 4:08 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> On Wed, Jan 9, 2013 at 8:10 AM, Beman Dawes <bdawes@acm.org> wrote:
>> A draft of the Any library proposal (Revision 2) is available.
>>
>> See http://beman.github.com/dot16/any-proposal.html
>>
>> As always, comments and corrections welcome!
>
> This is something of a bikeshed comment. I expect to have some real
> comments later after I've checked on Google's and Chrome's use of
> concepts like this. Sorry for totally missing the mid-term mailing
> deadline. :)
Sean Parent at Adobe has also put quite a bit of effort into looking
at the "any" concept. Adobe has followed the Boost any interface.
> I'm wondering about the spelling of any_cast<T>(the_any). I see some
> comments about an explicit conversion operator below, but no full
> evaluation of the alternatives. It might be worth putting a discussion
> like this into the paper if only to demonstrate that it's been
> considered.
>
> 1) Why was any_cast<T>(the_any) chosen as the syntax in the first place?
> 2) Here are 3 alternatives with pros and cons. C++ could provide any
> subset. What have I missed?
>
> a) any_cast<T>(the_any)
> Pro: Used by Boost.Any, presumably without many complaints.
> Pro: Logically the operation is a cast.
> Pro: Nice null-propagating behavior on pointers.
> Con: I always read this as "pick any of static_cast, reinterpret_cast,
> const_cast, or dynamic_cast, and apply it", which is wrong.
Nice summary. Viewing the operation as a cast works for some people
but confuses some others.
> b) the_any.explicit operator T()
> Pro: Really short initialization syntax: ExpectedType* t(the_any);
> Pro: Helps establish a convention for conversions through explicit operators.
> Con: More verbose call syntax: AFunction(static_cast<ExpectedType&>(the_any))
> Con: This would be the first instance I can find where static_cast<T&>
> could throw or static_cast<T*>(not_null) could return NULL.
> Con: Can't use any_cast<>'s trick on pointers:
> static_cast<ExpectedType*>(&the_any) tries to use the built-in
> static_cast and compile-fails.
> Con: Encourages less-safe casting: ExpectedType(the_any) is the
> shortest way to call a function, but ExpectedType*(&the_any) likely
> explodes at runtime.
The Cons markedly outweigh the Pros, IMO.
> c) the_any.as<T>() (or some other short method name, maybe cast<T>())
> Pro: Fairly short, consistent conversion syntax: ExpectedType* t =
> the_any.as<ExpectedType*>(); AFunction(the_any.as<ExpectedType&>()
> Con: Can't use any_cast<>'s trick on pointers:
> "static_cast<any*>(nullptr)->as<ExpectedType*>()" dereferences NULL
> with undefined effects.
> Con: This appears to be the first place we'd want to use a
> ref-qualifier in the standard library.
My variation on that was member functions:
template <class T>
T value() const;
template <class T>
T value_ptr() const noexcept;
but I never worked out the details.
--Beman
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Paul Smith <pl.smith.mail@gmail.com>
Date: Mon, 21 Jan 2013 18:38:59 +0200
Raw View
On Mon, Jan 21, 2013 at 6:01 PM, Beman Dawes <bdawes@acm.org> wrote:
> On Thu, Jan 17, 2013 at 4:08 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
>> On Wed, Jan 9, 2013 at 8:10 AM, Beman Dawes <bdawes@acm.org> wrote:
>>> A draft of the Any library proposal (Revision 2) is available.
>>>
>>> See http://beman.github.com/dot16/any-proposal.html
>>>
>>> As always, comments and corrections welcome!
>>
>> This is something of a bikeshed comment. I expect to have some real
>> comments later after I've checked on Google's and Chrome's use of
>> concepts like this. Sorry for totally missing the mid-term mailing
>> deadline. :)
>
> Sean Parent at Adobe has also put quite a bit of effort into looking
> at the "any" concept. Adobe has followed the Boost any interface.
If we're looking at existing practice, it might be a good idea to look
at std::function as well. Even though it has a more specific purpose,
it also has similar concepts and provides a somewhat different
interface. Not just a member 'target' function, but also different
assignment methods, conversion to bool instead of 'empty', etc'...
--
Paul Smith
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Thu, 24 Jan 2013 09:53:20 -0600
Raw View
Tony V E <tvaneerd@gmail.com> writes:
| > c) the_any.as<T>() (or some other short method name, maybe cast<T>())
| > Pro: Fairly short, consistent conversion syntax: ExpectedType* t =
| > the_any.as<ExpectedType*>(); AFunction(the_any.as<ExpectedType&>()
| > Con: Can't use any_cast<>'s trick on pointers:
| > "static_cast<any*>(nullptr)->as<ExpectedType*>()" dereferences NULL
| > with undefined effects.
|
| FWIW, Technically, I don't think that dereferences NULL. The
| implementation can check do:
|
| if (this == nullptr)
| return nullptr;
|
| I'm not good at quoting chapter and verse, but I think this is allowed
| (although somewhat scary).
No; 'this' can't be null -- no object has nullptr as address.
--
Gabriel Dos Reis, http://www.axiomatics.org/~gdr/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: 3dw4rd@verizon.net
Date: Mon, 8 Apr 2013 13:41:11 -0700 (PDT)
Raw View
------=_Part_4880_14326918.1365453671178
Content-Type: text/plain; charset=ISO-8859-1
I am wondering if variadic constructors would be useful. I'm thinking
something like the emplace in various containers. I think having any with
such constructors would help any work with emplace enabled containers:
So either add these:
template <typename... ValueTypes>
any(ValueTypes... value);
template <class Allocator, typename... ValueTypes>
any(allocator_arg_t, const Allocator& a, ValueTypes... value);
Or replace the current non-variadic constructors with these.
Is this a useful possibility?
On Wednesday, January 9, 2013 11:10:00 AM UTC-5, Beman Dawes wrote:
>
> A draft of the Any library proposal (Revision 2) is available.
>
> See http://beman.github.com/dot16/any-proposal.html
>
> As always, comments and corrections welcome!
>
> --Beman
>
--
---
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/?hl=en.
------=_Part_4880_14326918.1365453671178
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I am wondering if variadic constructors would be useful. I'm thinking=
something like the emplace in various containers. I think having any=
with such constructors would help any work with emplace enabled containers=
:<br><br>So either add these:<br><br><pre> template <typename... Valu=
eTypes>
any(ValueTypes... value);<br><br> <ins>template <class Allocato=
r, typename... ValueTypes></ins>
<ins>any(allocator_arg_t, const Allocator& a, ValueTypes... value=
);</ins>
<br>Or replace the current non-variadic constructors with these.<br><br>Is =
this a useful possibility? <br></pre><br><br>On Wednesday, January 9, 2013 =
11:10:00 AM UTC-5, Beman Dawes wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;">A draft of the Any library proposal (Revision 2) is available.
<br>
<br>See <a href=3D"http://beman.github.com/dot16/any-proposal.html" target=
=3D"_blank">http://beman.github.com/dot16/<wbr>any-proposal.html</a>
<br>
<br>As always, comments and corrections welcome!
<br>
<br>--Beman
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_4880_14326918.1365453671178--
.
Author: 3dw4rd@verizon.net
Date: Mon, 8 Apr 2013 13:46:24 -0700 (PDT)
Raw View
------=_Part_4784_21927272.1365453984206
Content-Type: text/plain; charset=ISO-8859-1
Nevermind... I can't think of a way to separate the thing being held with
the args used to construct it.
Maybe the first valueType is constructed with the remaining args.
On Monday, April 8, 2013 4:41:11 PM UTC-4, 3dw...@verizon.net wrote:
>
> I am wondering if variadic constructors would be useful. I'm thinking
> something like the emplace in various containers. I think having any with
> such constructors would help any work with emplace enabled containers:
>
> So either add these:
>
> template <typename... ValueTypes>
> any(ValueTypes... value);
>
> template <class Allocator, typename... ValueTypes>
> any(allocator_arg_t, const Allocator& a, ValueTypes... value);
> Or replace the current non-variadic constructors with these.
>
> Is this a useful possibility?
>
>
>
> On Wednesday, January 9, 2013 11:10:00 AM UTC-5, Beman Dawes wrote:
>>
>> A draft of the Any library proposal (Revision 2) is available.
>>
>> See http://beman.github.com/dot16/any-proposal.html
>>
>> As always, comments and corrections welcome!
>>
>> --Beman
>>
>
--
---
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/?hl=en.
------=_Part_4784_21927272.1365453984206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Nevermind... I can't think of a way to separate the thing being held =
with the args used to construct it.<br>Maybe the first valueType is constru=
cted with the remaining args.<br><br>On Monday, April 8, 2013 4:41:11 PM UT=
C-4, 3dw...@verizon.net wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
I am wondering if variadic constructors would be useful. I'm thinking=
something like the emplace in various containers. I think having any=
with such constructors would help any work with emplace enabled containers=
:<br><br>So either add these:<br><br><pre> template <typename... Valu=
eTypes>
any(ValueTypes... value);<br><br> <ins>template <class Allocato=
r, typename... ValueTypes></ins>
<ins>any(allocator_arg_t, const Allocator& a, ValueTypes... value=
);</ins>
<br>Or replace the current non-variadic constructors with these.<br><br>Is =
this a useful possibility? <br></pre><br><br>On Wednesday, January 9, 2013 =
11:10:00 AM UTC-5, Beman Dawes wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
">A draft of the Any library proposal (Revision 2) is available.
<br>
<br>See <a href=3D"http://beman.github.com/dot16/any-proposal.html" target=
=3D"_blank">http://beman.github.com/dot16/<wbr>any-proposal.html</a>
<br>
<br>As always, comments and corrections welcome!
<br>
<br>--Beman
<br></blockquote></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_4784_21927272.1365453984206--
.