Topic: Custom function names for external linkage
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 17 Oct 2013 15:24:55 -0700
Raw View
--bcaec51a75469669f904e8f749b4
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Thu, Oct 17, 2013 at 3:20 PM, <paulo_torrens@ekolivre.com.br> wrote:
> According to =A77.5/2:
>
> Use of a *string-literal* other than "C" or "C++" is
> conditionally-supported, with implementation-defined semantics. [ Note:
> Therefore, a linkage-specification with a string- literal that is unknown
> to the implementation requires a diagnostic. =97 end note ] [ Note: It is
> recommended that the spelling of the string-literal be taken from the
> document defining that language. For example, Ada (not ADA) and Fortran o=
r
> FORTRAN, depending on the vintage. =97 end note ]
>
> Different semantics, same syntax. So I would need a syntax extension to
> support it.
>
> What I'm trying to propose is a way of handling such custom names in a
> standard way, so no extension is needed at all (only custom semantic, as
> allowed by the standard), meaning my implementation would still be fully
> conformant.
>
> That's why I'm proposing this. Even a simple a standard [[generalized
> attribute]] would be enough, and would make an implementation supporting
> such linkage conformant. Something like *void* initWithAnd*(int* a*,* *in=
t
> * b*)* *[[*name*(**"initWith:And:"**)]]*, for example.
>
> This way the implementation would parse ok on any compiler, just would
> give an error because of the invalid linkage specifier and unknown
> attribute; no syntax error, though.
>
Why would you care whether it's a syntax error or a semantic error?
> Em quinta-feira, 17 de outubro de 2013 18h16min06s UTC-3, tom...@gmail.co=
mescreveu:
>
>> I'm going to stop you right here:
>>>
>>> Since C++ supports external linkage specifying the source language
>>
>> No, it doesn't.
>>
>> The end.
>> Best regards
>>
>>
>> On Thursday, October 17, 2013 7:19:38 PM UTC+1, paulo_...@ekolivre.com.b=
rwrote:
>>>
>>> Hello there,
>>>
>>> I am working on a compiler suite which should support many programming
>>> languages. Since C++ supports external linkage specifying the source
>>> language, I intend to use C++ as a "bridge language" across programming
>>> languages when needed.
>>>
>>> A problem arrives when, for example, I need access to a method name
>>> which uses symbols that can't appear on a C++ identifier.
>>>
>>> Let's get an example, the Objective-C language (this could replace the
>>> ugly Objective-C++):
>>>
>>> *extern* *"Objective-C"* *{*
>>> *class* NSObject *{*
>>> *public:*
>>> *static* NSObject ***alloc*();*
>>> NSObject ***init*();*
>>> *};*
>>> *};*
>>>
>>> *// The C++ compiler should emit the the same code that the ObjC
>>> compiler would for [[NSObject alloc] init]*
>>> NSObject ***obj =3D NSObject*::*alloc*()->*init*();*
>>>
>>> Which is a fair example, and could work as it is. But... and for method
>>> like "initWith:And:", which uses the colons to specify it takes two
>>> arguments. As of the current standard, I can't specify such methods.
>>>
>>> Has anyone though of it yet? Was any proposal already offered to solve
>>> this possible issue?
>>>
>>> There are two things that come to my mind: first and obvious is to use
>>> the [Attributes] from C++11. What attribute should specify the names, t=
hen?
>>> The second thing would be to extend the syntax in order to accept strin=
g
>>> literals as identifiers as well.
>>>
>>> *extern* *"Common Lisp"* *{*
>>> *class* *"|My Class|"* *{*
>>> *public**:*
>>> *int* *"myv@r"**;*
>>> *void* ****"didStuff?"**(**int**);*
>>> *};*
>>> *void* *"some-random-function"();*
>>> *};*
>>>
>>> *"|My Class|"* ***x *=3D* *new* *"|My Class|"**;*
>>> *void* ***y *=3D* x*->**"didStuff?"**(*42*);*
>>> cout *<<* x*->**"myv@r"* *<<* endl;
>>> *"some-random-function"();*
>>>
>>>
>>> What do you guys think? Anyone has another idea?
>>>
>>> After implementing this behaviour on my compiler, I intend to propose
>>> this extension to the standard.
>>>
>> --
>
> ---
> 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/.
>
--=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/.
--bcaec51a75469669f904e8f749b4
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Oct 17, 2013 at 3:20 PM, <span dir=3D"ltr"><<a=
href=3D"mailto:paulo_torrens@ekolivre.com.br" target=3D"_blank">paulo_torr=
ens@ekolivre.com.br</a>></span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">According to =A77.5/2:<br><=
br><div style=3D"margin-left:40px">Use of a <em>string-literal</em> other t=
han "C" or "C++" is=20
conditionally-supported, with implementation-defined semantics. [ Note:=20
Therefore, a linkage-specification with a string- literal that is=20
unknown to the implementation requires a diagnostic. =97 end note ] [=20
Note: It is recommended that the spelling of the string-literal be taken
from the document defining that language. For example, Ada (not ADA)=20
and Fortran or FORTRAN, depending on the vintage. =97 end note ]</div><br>D=
ifferent semantics, same syntax. So I would need a syntax extension to supp=
ort it.<br><br>What I'm trying to propose is a way of handling such cus=
tom names in a standard way, so no extension is needed at all (only custom =
semantic, as allowed by the standard), meaning my implementation would stil=
l be fully conformant.<br>
<br>That's why I'm proposing this. Even a simple a standard [[gener=
alized attribute]] would be enough, and would make an implementation suppor=
ting such linkage conformant. Something like <span style=3D"font-family:cou=
rier new,monospace"><span style=3D"color:rgb(0,0,255)"><b>void</b></span> i=
nitWithAnd<b>(<span style=3D"color:rgb(0,0,255)">int</span></b> a<b>,</b> <=
span style=3D"color:rgb(0,0,255)"><b>int</b></span> b<b>)</b> <b>[[</b>name=
<b>(</b><span style=3D"color:rgb(153,0,255)"><b>"initWith:And:"</=
b></span><b>)]]</b></span>, for example.<br>
<br>This way the implementation would parse ok on any compiler, just would =
give an error because of the invalid linkage specifier and unknown attribut=
e; no syntax error, though.<br></div></blockquote><div><br></div><div>Why w=
ould you care whether it's a syntax error or a semantic error?</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 dir=3D"ltr">Em quinta-fei=
ra, 17 de outubro de 2013 18h16min06s UTC-3, <a href=3D"mailto:tom...@gmail=
..com" target=3D"_blank">tom...@gmail.com</a> escreveu:<div>
<div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
I'm going to stop you right here:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex">
Since C++ supports external linkage specifying the source language</blockqu=
ote><div>No, it doesn't.</div><div><br></div><div>The end.</div><div>Be=
st regards</div><div><br><br>On Thursday, October 17, 2013 7:19:38 PM UTC+1=
, <a>paulo_...@ekolivre.com.br</a> wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<div dir=3D"ltr">Hello there,<br><br>I am working on a compiler suite which=
should support many programming languages. Since C++ supports external lin=
kage specifying the source language, I intend to use C++ as a "bridge =
language" across programming languages when needed.<br>
<br>A problem arrives when, for example, I need access to a method name whi=
ch uses symbols that can't appear on a C++ identifier.<br><br>Let's=
get an example, the Objective-C language (this could replace the ugly Obje=
ctive-C++):<br>
<br><div style=3D"margin-left:40px"><span style=3D"font-family:courier new,=
monospace"><span style=3D"color:rgb(0,0,255)"><b>extern</b></span> <span st=
yle=3D"color:rgb(153,0,255)"><b>"Objective-C"</b></span> <b>{</b>=
</span><br>
<span style=3D"font-family:courier new,monospace">=A0 <b><span style=3D"col=
or:rgb(0,0,255)">class</span></b> NSObject <b>{</b></span><br><span style=
=3D"font-family:courier new,monospace">=A0=A0=A0 <b><span style=3D"color:rg=
b(0,0,255)">public</span>:</b></span><br>
<span style=3D"font-family:courier new,monospace">=A0=A0=A0=A0=A0 <span sty=
le=3D"color:rgb(0,0,255)"><b>static</b></span> NSObject <b>*</b>alloc<b>();=
</b></span><br><span style=3D"font-family:courier new,monospace">=A0=A0 =A0=
=A0 NSObject <b>*</b>init<b>();</b></span><br>
<span style=3D"font-family:courier new,monospace">=A0 <b>};</b></span><br><=
b><span style=3D"font-family:courier new,monospace">};</span></b><br><span =
style=3D"font-family:courier new,monospace"></span><br><span style=3D"color=
:rgb(56,118,29)"><i><span style=3D"font-family:courier new,monospace">// Th=
e C++ compiler should emit the the same code that the ObjC compiler would f=
or [[NSObject alloc] init]</span></i></span><br>
<span style=3D"font-family:courier new,monospace">NSObject <b>*</b>obj =3D =
NSObject<b>::</b>alloc<b>()-></b>init<b>();</b></span><br></div><br>Whic=
h is a fair example, and could work as it is. But... and for method like &q=
uot;initWith:And:", which uses the colons to specify it takes two argu=
ments. As of the current standard, I can't specify such methods.<br>
<br>Has anyone though of it yet? Was any proposal already offered to solve =
this possible issue?<br><br>There are two things that come to my mind: firs=
t and obvious is to use the [Attributes] from C++11. What attribute should =
specify the names, then?<br>
The second thing would be to extend the syntax in order to accept string li=
terals as identifiers as well.<br><br><div style=3D"margin-left:40px"><span=
style=3D"font-family:courier new,monospace"><b><span style=3D"color:rgb(0,=
0,255)">extern</span></b> <span style><span style=3D"color:rgb(153,0,255)">=
<b>"Common Lisp"</b></span></span> <b>{</b><br>
=A0 <span style=3D"color:rgb(0,0,255)"><b>class</b></span> <span style=3D"c=
olor:rgb(153,0,255)"><b>"|My Class|"</b></span> <b>{</b><br>=A0=
=A0=A0 <span style=3D"color:rgb(0,0,255)"><b>public</b></span><b>:</b><br>=
=A0=A0=A0=A0=A0 <span style=3D"color:rgb(0,0,255)"><b>int</b></span> <span =
style=3D"color:rgb(153,0,255)"><b>"myv@r"</b></span><b>;</b><br>
=A0=A0=A0=A0=A0 <span style=3D"color:rgb(0,0,255)"><b>void</b></span> <b>*<=
/b><span style=3D"color:rgb(153,0,255)"><b>"didStuff?"</b></span>=
<b>(</b><span style=3D"color:rgb(0,0,255)"><b>int</b></span><b>);</b><br>=
=A0 <b>};</b><br>
=A0 <b><span style=3D"color:rgb(0,0,255)">void</span></b> <b><span style=3D=
"color:rgb(153,0,255)">"some-random-function"</span>();</b><br><b=
>};</b><br><br><b><span style=3D"color:rgb(153,0,255)">"|My Class|&quo=
t;</span></b> <b>*</b>x <b>=3D</b> <span style=3D"color:rgb(0,0,255)"><b>ne=
w</b></span> <span style=3D"color:rgb(153,0,255)"><b>"|My Class|"=
</b></span><b>;</b><br>
<b><span style=3D"color:rgb(0,0,255)">void</span></b> <b>*</b>y <b>=3D</b> =
x<b>-></b><span style=3D"color:rgb(153,0,255)"><b>"didStuff?"<=
/b></span><b>(</b><span style=3D"color:rgb(61,133,198)">42</span><b>);</b><=
br>cout <b><<</b> x<b>-></b><span style=3D"color:rgb(153,0,255)"><=
b>"myv@r"</b></span> <b><<</b> endl;<br>
<b><span style=3D"color:rgb(153,0,255)">"some-random-function"</s=
pan>();</b></span><br></div><br><br>What do you guys think? Anyone has anot=
her idea?<br><br>After implementing this behaviour on my compiler, I intend=
to propose this extension to the standard.<br>
</div></blockquote></div></div></blockquote></div></div></div><div class=3D=
"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec51a75469669f904e8f749b4--
.
Author: paulo_torrens@ekolivre.com.br
Date: Thu, 17 Oct 2013 15:28:12 -0700 (PDT)
Raw View
------=_Part_718_9145173.1382048892253
Content-Type: text/plain; charset=ISO-8859-1
Em quinta-feira, 17 de outubro de 2013 19h24min55s UTC-3, Richard Smith
escreveu:
>
> Why would you care whether it's a syntax error or a semantic error?
>
>
Because then my implementation would still be fully-conformant to the
standard, supporting a conditionally-supported feature, but without adding
any custom extensions.
I could also write a patch for GCC and Clang to support this behaviour
(either by strings as identifiers, or by the generalized attribute, or by
any other idea someone could suggest, I'm not sure which way would be the
best).
--
---
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_718_9145173.1382048892253
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Em quinta-feira, 17 de outubro de 2013 19h24min55s UTC-3, =
Richard Smith escreveu:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div>Why would you care whether =
it's a syntax error or a semantic error?</div>
<div><br></div></div></div></div></blockquote><div><br>Because then my impl=
ementation would still be fully-conformant to the standard, supporting a co=
nditionally-supported feature, but without adding any custom extensions.<br=
><br>I could also write a patch for GCC and Clang to support this behaviour=
(either by strings as identifiers, or by the generalized attribute, or by =
any other idea someone could suggest, I'm not sure which way would be the b=
est).<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_718_9145173.1382048892253--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 17 Oct 2013 15:43:08 -0700
Raw View
--047d7b15a081b35c5304e8f78ab9
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Oct 17, 2013 at 3:28 PM, <paulo_torrens@ekolivre.com.br> wrote:
> Em quinta-feira, 17 de outubro de 2013 19h24min55s UTC-3, Richard Smith
> escreveu:
>
>> Why would you care whether it's a syntax error or a semantic error?
>>
>>
> Because then my implementation would still be fully-conformant to the
> standard, supporting a conditionally-supported feature, but without adding
> any custom extensions.
>
Why do you care about that? Users of your extension need to rely on
implementation-specific features either way.
Also, a compiler can accept *any syntax it likes* and still be
fully-conforming, so long as it issues at least one diagnostic message (eg,
"warning: this feature is not standard") and produces the right behavior
for all well-formed input programs. So you can implement this and still be
fully-conforming, whether or not the syntax is standardized.
> I could also write a patch for GCC and Clang to support this behaviour
> (either by strings as identifiers, or by the generalized attribute, or by
> any other idea someone could suggest, I'm not sure which way would be the
> best).
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b15a081b35c5304e8f78ab9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Oct 17, 2013 at 3:28 PM, <span dir=3D"ltr"><<a=
href=3D"mailto:paulo_torrens@ekolivre.com.br" target=3D"_blank">paulo_torr=
ens@ekolivre.com.br</a>></span> wrote:<br><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Em quinta-feira, 17 de outu=
bro de 2013 19h24min55s UTC-3, Richard Smith escreveu:<div class=3D"im"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Why would you care wh=
ether it's a syntax error or a semantic error?</div>
<div><br></div></div></div></div></blockquote></div><div><br>Because then m=
y implementation would still be fully-conformant to the standard, supportin=
g a conditionally-supported feature, but without adding any custom extensio=
ns.<br>
</div></div></blockquote><div><br></div><div>Why do you care about that? Us=
ers of your extension need to rely on implementation-specific features eith=
er way.</div><div><br></div><div>Also, a compiler can accept *any syntax it=
likes* and still be fully-conforming, so long as it issues at least one di=
agnostic message (eg, "warning: this feature is not standard") an=
d produces the right behavior for all well-formed input programs. So you ca=
n implement this and still be fully-conforming, whether or not the syntax i=
s standardized.</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 dir=3D"ltr"><div>I could =
also write a patch for GCC and Clang to support this behaviour (either by s=
trings as identifiers, or by the generalized attribute, or by any other ide=
a someone could suggest, I'm not sure which way would be the best).<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b15a081b35c5304e8f78ab9--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 17 Oct 2013 20:07:30 -0700
Raw View
On quinta-feira, 17 de outubro de 2013 15:28:12, paulo_torrens@ekolivre.com.br
wrote:
> I could also write a patch for GCC and Clang to support this behaviour
> (either by strings as identifiers, or by the generalized attribute, or by
> any other idea someone could suggest, I'm not sure which way would be the
> best).
They already have that, as an extension:
void f(int x, int y) __asm__("?f@@YAXHH@Z");
Obviously, we can't have any random collection of bytes as identifiers in C++,
they'd conflict with the language syntax. Therefore, you need a "C++ name" for
the function and you can then tell the compiler what the real symbol name
should be.
The __asm__ above is an extension, clearly. But it can be implemented with an
attribute.
Still, I don't see this ever becoming part of the standard. It will always be
compiler-dependent. Setting the symbol name is only half the problem. Getting
the calling convention right is the other half.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.