------=_Part_551_26768948.1384815962847
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi all,

I recently went to isocpp.org and went across his discussion :
Quick Q: Does using std:: smart pointers mean not using raw=20
pointers?=97StackOverflow<http://stackoverflow.com/questions/19929970/c11-s=
mart-pointer-semantics>After=20
reading most of the posts, especially the one who said that=20

Even in C++11, raw pointers are still *perfectly valid* as non-owning=20
references to objects.

something becomes clear in my mind. Men, if using raw pointer is still the=
=20
recommended things to do in that case, isn't it the sign that something is=
=20
missing in the standard?
And the fact is that i'm quite sure that yes, something is missing=20
(especially because it's not the first time I read people posting about the=
=20
use of unique/shared/raw pointers).

Also, I've tried to adress this with a new class called std::ref_ptr.
The idea is to have a pointer wich will not take ownership, but wich can be=
=20
used for referencing object wich are owned but other pointer (both unique=
=20
and shared pointers should be supported).
This led me to propose that interface:

template<typename T>
class ref_ptr
{
    ref_ptr(const unique_ptr<T>&);
    ref_ptr(const shared_ptr<T>&); //can be construct from any=20
ownership-enabled pointer. I don't know if those ctors should be made=20
explicit though.
    ref_ptr(const ref_ptr<T>&); //copy constructible
   =20
    T& operator *() const;
    T* operator ->() const;
    explicit operator bool() const;
    ref_ptr& operator =3D(const ref_ptr<T>&);
   =20
    T* get() const;
    //you can add here any method wich can prove to be usefull
};


Advantage over raw pointers:
- can't be used to create new unique/shared_ptr (at least not directly),=20
avoiding potential programming errors.
- need an existing unique/shared_ptr, but can't be construct from raw=20
pointers. This guarantees that the referenced pointer is  to owned by=20
someone and won't be leaked.

Advantage over weak pointers:
- can be used with unique_ptr.
- no need to cast the pointer and construct a new one from it, resulting in=
=20
better performance. This class will have only one field wich is the pointer=
=20
itself. This will enable her to perform the same as raw pointers does.

Note :=20
- Since this class does not deal with ownership, referenced object must=20
outlive the pointer itself. Otherwise, the ref_ptr will become invalid and=
=20
derefencing it will lead to undefined behaviour.
- I did not add move constructors because I don't think it will any=20
functionnality/benefit over copy constructor.

Uses cases :
- You want to reference an existing object wich you know will still be=20
valid once you will have done with it : use ref_ptr
- You want to reference an existing object, but  you don't know if he will=
=20
still be valid when you'll need it. 2 possibility :
    --> you want your referenced object to still be valid : use shared_ptr.=
=20
(having this still valid means that you wanna deal with ownership afterall)=
..
    --> your object can become invalid, you can deal with it (typically,=20
cache systems) : use weak_ptr.

What do you think of this?

PS:
What about std::unique_ptr&?
Another solution for this could be to use reference to std::unique_ptr (or=
=20
eventually shared one). While I didn't test it, I do believe that a=20
reference to an existing pointer could become invalid at any time when the=
=20
pointer is moved for example. Can someone confirm me that?


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_551_26768948.1384815962847
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<br><br>I recently went to <a href=3D"http://isocpp=
..org" target=3D"_blank">isocpp.org</a> and went across his discussion :<br>=
<h2><a href=3D"http://stackoverflow.com/questions/19929970/c11-smart-pointe=
r-semantics" target=3D"_blank">Quick Q: Does using std:: smart pointers mea=
n not using raw pointers?=97StackOverflow</a></h2>After reading most of the=
 posts, especially the one who said that <br><blockquote>Even in C++11, raw=
 pointers are still <em>perfectly valid</em> as non-owning references to ob=
jects.</blockquote>something
 becomes clear in my mind. Men, if using raw pointer is still the=20
recommended things to do in that case, isn't it the sign that something=20
is missing in the standard?<br>And the fact is that i'm quite sure that=20
yes, something is missing (especially because it's not the first time I=20
read people posting about the use of unique/shared/raw pointers).<br><br>Al=
so, I've tried to adress this with a new class called std::ref_ptr.<br>The
 idea is to have a pointer wich will not take ownership, but wich can be
 used for referencing object wich are owned but other pointer (both=20
unique and shared pointers should be supported).<br>This led me to propose =
that interface:<br><br><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:bre=
ak-word"><code><div><div 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><div><span style=3D"color:#008">template</span><span style=3D"c=
olor:#660">&lt;</span><span style=3D"color:#008">typename</span><span style=
=3D"color:#000"> T</span><span style=3D"color:#660">&gt;</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">class</span><span sty=
le=3D"color:#000"> ref_ptr<br></span><span style=3D"color:#660">{</span><sp=
an style=3D"color:#000"><br>&nbsp; &nbsp; ref_ptr</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#008">const</span><span style=3D"color=
:#000"> unique_ptr</span><span style=3D"color:#660">&lt;</span><span style=
=3D"color:#000">T</span><span style=3D"color:#660">&gt;&amp;);</span><span =
style=3D"color:#000"><br>&nbsp; &nbsp; ref_ptr</span><span style=3D"color:#=
660">(</span><span style=3D"color:#008">const</span><span style=3D"color:#0=
00"> shared_ptr</span><span style=3D"color:#660">&lt;</span><span style=3D"=
color:#000">T</span><span style=3D"color:#660">&gt;&amp;);</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#800">//can be construct from=
 any ownership-enabled pointer</span><span style=3D"color:#000">. I don't k=
now if those ctors should be made explicit though.<br>&nbsp; &nbsp; ref_ptr=
</span><span style=3D"color:#660">(</span><span style=3D"color:#008">const<=
/span><span style=3D"color:#000"> ref_ptr</span><span style=3D"color:#660">=
&lt;</span><span style=3D"color:#000">T</span><span style=3D"color:#660">&g=
t;&amp;);</span><span style=3D"color:#000"> </span><span style=3D"color:#80=
0">//copy constructible</span><span style=3D"color:#000"><br>&nbsp; &nbsp; =
<br>&nbsp; &nbsp; T</span><span style=3D"color:#660">&amp;</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">operator</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">*()</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">const</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br>&nbsp; &nbsp; T</spa=
n><span style=3D"color:#660">*</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#008">operator</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">-&gt;()</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#008">const</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"><br>&nbsp; &nbsp; </span><span style=3D"color:#00=
8">explicit</span><span style=3D"color:#000"> </span><span style=3D"color:#=
008">operator</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">bool</span><span style=3D"color:#660">()</span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">const</span><span style=3D"color:#=
660">;</span><span style=3D"color:#000"><br>&nbsp; &nbsp; ref_ptr</span><sp=
an style=3D"color:#660">&amp;</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#008">operator</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">=3D(</span><span style=3D"color:#008">const</span>=
<span style=3D"color:#000"> ref_ptr</span><span style=3D"color:#660">&lt;</=
span><span style=3D"color:#000">T</span><span style=3D"color:#660">&gt;&amp=
;);</span><span style=3D"color:#000"><br>&nbsp; &nbsp; <br>&nbsp; &nbsp; T<=
/span><span style=3D"color:#660">*</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">get</span><span style=3D"color:#660">()</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">const</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br>&nbsp; &nbs=
p; </span><span style=3D"color:#800">//you can add here </span><span style=
=3D"color:#000">any method wich can prove to be usefull<br></span><span sty=
le=3D"color:#660">};</span><span style=3D"color:#000"><br></span></div></co=
de></div><span style=3D"color:#000"></span></div></code></div><br><br>Advan=
tage over raw pointers:<br>- can't be used to create new unique/shared_ptr =
(at least not directly), avoiding potential programming errors.<br>-
 need an existing unique/shared_ptr, but can't be construct from raw=20
pointers. This guarantees that the referenced pointer is&nbsp; to owned by=
=20
someone and won't be leaked.<br><br>Advantage over weak pointers:<br>- can =
be used with unique_ptr.<br>-
 no need to cast the pointer and construct a new one from it, resulting=20
in better performance. This class will have only one field wich is the=20
pointer itself. This will enable her to perform the same as raw pointers
 does.<br><br>Note : <br>- Since this class does not deal with=20
ownership, referenced object must outlive the pointer itself. Otherwise,
 the ref_ptr will become invalid and derefencing it will lead to=20
undefined behaviour.<br>- I did not add move constructors because I don't t=
hink it will any functionnality/benefit over copy constructor.<br><br>Uses =
cases :<br>- You want to reference an existing object wich you know will st=
ill be valid once you will have done with it : use ref_ptr<br>- You want to=
 reference an existing object, but&nbsp; you don't know if he will still be=
 valid when you'll need it. 2 possibility :<br>&nbsp;&nbsp;&nbsp;
 --&gt; you want your referenced object to still be valid : use=20
shared_ptr. (having this still valid means that you wanna deal with=20
ownership afterall).<br>&nbsp;&nbsp;&nbsp; --&gt; your object can become in=
valid, you can deal with it (typically, cache systems) : use weak_ptr.<br><=
br>What do you think of this?<br><br>PS:<br>What about std::unique_ptr&amp;=
?<br>Another
 solution for this could be to use reference to std::unique_ptr (or=20
eventually shared one). While I didn't test it, I do believe that a=20
reference to an existing pointer could become invalid at any time when=20
the pointer is moved for example. Can someone confirm me that?<br><br><br><=
/div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_551_26768948.1384815962847--

.

On Mon, Nov 18, 2013 at 6:06 PM,  <masse.nicolas@gmail.com> wrote:
> Even in C++11, raw pointers are still perfectly valid as non-owning
> references to objects.
> [...]
> Also, I've tried to adress this with a new class called std::ref_ptr.
> The idea is to have a pointer wich will not take ownership, but wich can be
> used for referencing object wich are owned but other pointer (both unique
> and shared pointers should be supported).

I believe this

  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3740.pdf

is a better choice.

This paper receives comments like "improve safety, no just T*
replacement of raw pointers" on Chicago.

--
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 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/.

.

--089e013d0db08bebbe04eb7c23ef
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 19, 2013 at 12:17 AM, Zhihao Yuan <zy@miator.net> wrote:

> This paper receives comments like "improve safety, no just T*
> replacement of raw pointers" on Chicago.
>

I think a good idea would have been to make impossible to delete through
this pointer.
This idea have been suggested by someone else on these forums or some other
I don't remember,
and I thought it was part of N3740 but apparently not.

--

---
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/.

--089e013d0db08bebbe04eb7c23ef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Nov 19, 2013 at 12:17 AM, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=
=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div id=3D":2kg" style=3D"overflow:hidden">This paper receives comments lik=
e &quot;improve safety, no just T*<br>
replacement of raw pointers&quot; on Chicago.</div></blockquote></div><br>I=
 think a good idea would have been to make impossible to delete through thi=
s pointer.</div><div class=3D"gmail_extra">This idea have been suggested by=
 someone else on these forums or some other I don&#39;t remember,<br>
and I thought it was part of N3740 but apparently not.</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e013d0db08bebbe04eb7c23ef--

.

On Mon, Nov 18, 2013 at 6:45 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>=
 wrote:
> I think a good idea would have been to make impossible to delete through
> this pointer.
> This idea have been suggested by someone else on these forums or some oth=
er
> I don't remember,
> and I thought it was part of N3740 but apparently not.

??

This is a smart pointer, of course you can't

  delete p;

since p is not a pointer.

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--e89a8ff1cbda4d26b304eb7cf20e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 19, 2013 at 12:56 AM, Zhihao Yuan <zy@miator.net> wrote:

> This is a smart pointer, of course you can't
>
>   delete p;
>
> since p is not a pointer.
>

Of course! I was being dumb by lack of sleep, sorry.
Did the committee have suggestions on the kind of additional safety that
would be useful?

--

---
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/.

--e89a8ff1cbda4d26b304eb7cf20e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Nov 19, 2013 at 12:56 AM, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=
=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div id=3D":1ql" style=3D"overflow:hidden">This is a smart pointer, of cour=
se you can&#39;t<br>
<br>
=A0 delete p;<br>
<br>
since p is not a pointer.</div></blockquote></div><br>Of course! I was bein=
g dumb by lack of sleep, sorry.<br>Did the committee have suggestions on th=
e kind of additional safety that would be useful?</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8ff1cbda4d26b304eb7cf20e--

.

On Mon, Nov 18, 2013 at 7:43 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>=
 wrote:
> Did the committee have suggestions on the kind of additional safety that
> would be useful?

Restrict the types of pointer comparison (T* _cmp_ V*, where
un-cv T and V should be the same or one is_base_of another).

Restrict the pointer arithmetic (to exempt_ptr<T[]> for example,
which should be able to be used wherever exempt_ptr<T> can
be used).

Explicit convertible to T*, not implicit.

(No poll taken) Disallow creating exempt_ptr from array reference.

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_132_8401496.1384866078516
Content-Type: text/plain; charset=ISO-8859-1

To be honest, I don't like the fact that exempt_ptr can be build from raw
pointers, because in that case you just don't know if somebody else is
already owning the pointer or not.
Also, (but this is mentionned in the proposal), this class isn't aware of
any other smart pointers, and consequently does not interact with any of
them. I think this must be added.
For the rest, I agree on the fact that safety must be improved (see comment
from Zhihao Yuan)


On Tuesday, November 19, 2013 12:17:03 AM UTC+1, Zhihao Yuan wrote:
>
> On Mon, Nov 18, 2013 at 6:06 PM,  <masse....@gmail.com <javascript:>>
> wrote:
> > Even in C++11, raw pointers are still perfectly valid as non-owning
> > references to objects.
> > [...]
> > Also, I've tried to adress this with a new class called std::ref_ptr.
> > The idea is to have a pointer wich will not take ownership, but wich can
> be
> > used for referencing object wich are owned but other pointer (both
> unique
> > and shared pointers should be supported).
>
> I believe this
>
>   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3740.pdf
>
> is a better choice.
>
> This paper receives comments like "improve safety, no just T*
> replacement of raw pointers" on Chicago.
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_132_8401496.1384866078516
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">To be honest, I don't like the fact that exempt_ptr can be=
 build from raw pointers, because in that case you just don't know if someb=
ody else is already owning the pointer or not.<br>Also, (but this is mentio=
nned in the proposal), this class isn't aware of any other smart pointers, =
and consequently does not interact with any of them. I think this must be a=
dded.<br>For the rest, I agree on the fact that safety must be improved (se=
e comment from <span class=3D"_username"><span style=3D"color: rgb(34, 34, =
34);" class=3D"GFLL15SBNB">Zhihao Yuan)</span></span><br><br><br>On Tuesday=
, November 19, 2013 12:17:03 AM UTC+1, Zhihao Yuan wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">On Mon, Nov 18, 2013 at 6:06 PM, &nbsp;&lt;<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"iQotvLvVT5MJ=
">masse....@gmail.com</a>&gt; wrote:
<br>&gt; Even in C++11, raw pointers are still perfectly valid as non-ownin=
g
<br>&gt; references to objects.
<br>&gt; [...]
<br>&gt; Also, I've tried to adress this with a new class called std::ref_p=
tr.
<br>&gt; The idea is to have a pointer wich will not take ownership, but wi=
ch can be
<br>&gt; used for referencing object wich are owned but other pointer (both=
 unique
<br>&gt; and shared pointers should be supported).
<br>
<br>I believe this
<br>
<br>&nbsp; <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/20=
13/n3740.pdf" target=3D"_blank">http://www.open-std.org/JTC1/<wbr>SC22/WG21=
/docs/papers/2013/<wbr>n3740.pdf</a>
<br>
<br>is a better choice.
<br>
<br>This paper receives comments like "improve safety, no just T*
<br>replacement of raw pointers" on Chicago.
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_132_8401496.1384866078516--

.