------=_Part_5463_13051439.1367444730337
Content-Type: text/plain; charset=ISO-8859-1

I feel like C++ suffers from a lot of old stuff that needs to be mainted
for compatibility reasons. Has there been any discussion about splitting
C++ into a core and compatibility profile, similar to what the OpenGL guys
did? That would allow us to deprecate or get rid of stuff more easily while
maintining backwards compatibility.

--

---
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_5463_13051439.1367444730337
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I feel like C++ suffers from a lot of old stuff that needs to be mainted fo=
r compatibility reasons. Has there been any discussion about splitting C++ =
into a core and compatibility profile, similar to what the OpenGL guys did?=
 That would allow us to deprecate or get rid of stuff more easily while mai=
ntining backwards compatibility.<br>

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_5463_13051439.1367444730337--

.

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

I am not aware of such a discussion, although it is likely that in next
meeting we may have a discussion about compatibility with C.


On Wed, May 1, 2013 at 4:45 PM, <stackmachine@hotmail.com> wrote:

> I feel like C++ suffers from a lot of old stuff that needs to be mainted
> for compatibility reasons. Has there been any discussion about splitting
> C++ into a core and compatibility profile, similar to what the OpenGL guys
> did? That would allow us to deprecate or get rid of stuff more easily while
> maintining backwards compatibility.
>
> --
>
> ---
> 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.
>
>
>

--

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



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

<div dir=3D"ltr">I am not aware of such a discussion, although it is likely=
 that in next meeting we may have a discussion about compatibility with C.<=
div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, May 1,=
 2013 at 4:45 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:stackmachine@hot=
mail.com" target=3D"_blank">stackmachine@hotmail.com</a>&gt;</span> wrote:<=
br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I feel like C++ suffers from a lot of old st=
uff that needs to be mainted for compatibility reasons. Has there been any =
discussion about splitting C++ into a core and compatibility profile, simil=
ar to what the OpenGL guys did? That would allow us to deprecate or get rid=
 of stuff more easily while maintining backwards compatibility.<span class=
=3D"HOEnZb"><font color=3D"#888888"><br>



<p></p>

-- <br>
=A0<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 <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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div></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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bd770f4de51d704dbaf13b1--

.

------=_Part_5639_8231083.1367446270313
Content-Type: text/plain; charset=ISO-8859-1

He doesn't mean just C, he means with C-style C++.

And the simple answer is that that approach will never work for C++. It
works for DirectX and OGL to reinvent their APIs because firstly, it's just
an API and there's lots of components of the software that depend on it
that won't have to be changed, and secondly, developers typically re-write
their engines often anyway to remain visually competitive, so it's hardly a
big drain on them. Neither of these is true for C++. You'd be talking about
re-writing every single line of C++ code out there, and nobody wants to do
that.

--

---
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_5639_8231083.1367446270313
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

He doesn't mean just C, he means with C-style C++.<div><br></div><div>And t=
he simple answer is that that approach will never work for C++. It works fo=
r DirectX and OGL to reinvent their APIs because firstly, it's just an API =
and there's lots of components of the software that depend on it that won't=
 have to be changed, and secondly, developers typically re-write their engi=
nes often anyway to remain visually competitive, so it's hardly a big drain=
 on them. Neither of these is true for C++. You'd be talking about re-writi=
ng every single line of C++ code out there, and nobody wants to do that.</d=
iv>

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_5639_8231083.1367446270313--

.

------=_Part_6555_9297878.1367457922922
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, May 1, 2013 2:45:30 PM UTC-7, stackm...@hotmail.com wrote:
>
> I feel like C++ suffers from a lot of old stuff that needs to be mainted
> for compatibility reasons. Has there been any discussion about splitting
> C++ into a core and compatibility profile, similar to what the OpenGL guys
> did? That would allow us to deprecate or get rid of stuff more easily while
> maintining backwards compatibility.
>

God, I hope not. The core/compatibility profile stuff has been a disaster
for OpenGL. Well, maybe "disaster" is hyperbolic; it's been completely
useless for OpenGL.

Everyone not on MacOSX still implements the compatibility profile. They
still spend time keeping it up to date. And even after removing the
compatibility stuff, they still can't use any design space that wouldn't
work on compatibility. For example, they can't ever create a new function
called "glBegin" because the compatibility profile already has such a
function.

Doing this with a language would be terrible. You would have these holes in
the core profile language, these syntactic areas that wouldn't be legal
syntax. But you wouldn't be able to ever *use them* for some new
functionality, because you have to keep compatibility between the two
profiles. So let's say you remove C-style arrays from the language. You
still couldn't define `int[5]` to be equivalent to `std::array<int, 5>`,
because the compatibility profile defines that `int[5]` means something
else.

The core/compatibility distinction is useless from the perspective of
trying to open up design space. It's not useful from the perspective of
trying to free yourself from old functionality, since every compiler will
just implement compatibility like they always do. So... what's the point of
doing it?

--

---
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_6555_9297878.1367457922922
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, May 1, 2013 2:45:30 PM UTC-7, stackm...@hotmail.com wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">I feel like C++ suffers from a lo=
t of old stuff that needs to be mainted for compatibility reasons. Has ther=
e been any discussion about splitting C++ into a core and compatibility pro=
file, similar to what the OpenGL guys did? That would allow us to deprecate=
 or get rid of stuff more easily while maintining backwards compatibility.<=
br></blockquote><div><br>God, I hope not. The core/compatibility profile st=
uff has been a disaster for OpenGL. Well, maybe "disaster" is hyperbolic; i=
t's been completely useless for OpenGL.<br><br>Everyone not on MacOSX still=
 implements the compatibility profile. They still spend time keeping it up =
to date. And even after removing the compatibility stuff, they still can't =
use any design space that wouldn't work on compatibility. For example, they=
 can't ever create a new function called "glBegin" because the compatibilit=
y profile already has such a function.<br><br>Doing this with a language wo=
uld be terrible. You would have these holes in the core profile language, t=
hese syntactic areas that wouldn't be legal syntax. But you wouldn't be abl=
e to ever <i>use them</i> for some new functionality, because you have to k=
eep compatibility between the two profiles. So let's say you remove C-style=
 arrays from the language. You still couldn't define `int[5]` to be equival=
ent to `std::array&lt;int, 5&gt;`, because the compatibility profile define=
s that `int[5]` means something else.<br><br>The core/compatibility distinc=
tion is useless from the perspective of trying to open up design space. It'=
s not useful from the perspective of trying to free yourself from old funct=
ionality, since every compiler will just implement compatibility like they =
always do. So... what's the point of doing it?<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_6555_9297878.1367457922922--

.

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

On Thu, May 2, 2013 at 3:25 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, May 1, 2013 2:45:30 PM UTC-7, stackm...@hotmail.com wrote:
>>
>> I feel like C++ suffers from a lot of old stuff that needs to be mainted
>> for compatibility reasons. Has there been any discussion about splitting
>> C++ into a core and compatibility profile, similar to what the OpenGL guys
>> did? That would allow us to deprecate or get rid of stuff more easily while
>> maintining backwards compatibility.
>>
>
> God, I hope not. The core/compatibility profile stuff has been a disaster
> for OpenGL. Well, maybe "disaster" is hyperbolic; it's been completely
> useless for OpenGL.
>
> Everyone not on MacOSX still implements the compatibility profile. They
> still spend time keeping it up to date. And even after removing the
> compatibility stuff, they still can't use any design space that wouldn't
> work on compatibility. For example, they can't ever create a new function
> called "glBegin" because the compatibility profile already has such a
> function.
>
> Doing this with a language would be terrible. You would have these holes
> in the core profile language, these syntactic areas that wouldn't be legal
> syntax. But you wouldn't be able to ever *use them* for some new
> functionality, because you have to keep compatibility between the two
> profiles. So let's say you remove C-style arrays from the language. You
> still couldn't define `int[5]` to be equivalent to `std::array<int, 5>`,
> because the compatibility profile defines that `int[5]` means something
> else.
>
> The core/compatibility distinction is useless from the perspective of
> trying to open up design space. It's not useful from the perspective of
> trying to free yourself from old functionality, since every compiler will
> just implement compatibility like they always do. So... what's the point of
> doing it?
>

The only useful thing I could see coming out of this idea would be for
compiler writers to provide flags to disable certain language aspects (or
turn them into warnings?) , for people that want to stay away from
dangerous stuff. Kinda like we can disable exceptions and RTTI in some of
them. But that requires nothing of the committee, anyway.

Martinho

--

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



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

<div dir=3D"ltr">On Thu, May 2, 2013 at 3:25 AM, Nicol Bolas <span dir=3D"l=
tr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@=
gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">On Wedn=
esday, May 1, 2013 2:45:30 PM UTC-7, <a href=3D"mailto:stackm...@hotmail.co=
m" target=3D"_blank">stackm...@hotmail.com</a> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
I feel like C++ suffers from a lot of old stuff that needs to be mainted fo=
r compatibility reasons. Has there been any discussion about splitting C++ =
into a core and compatibility profile, similar to what the OpenGL guys did?=
 That would allow us to deprecate or get rid of stuff more easily while mai=
ntining backwards compatibility.<br>
</blockquote></div><div><br>God, I hope not. The core/compatibility profile=
 stuff has been a disaster for OpenGL. Well, maybe &quot;disaster&quot; is =
hyperbolic; it&#39;s been completely useless for OpenGL.<br><br>Everyone no=
t on MacOSX still implements the compatibility profile. They still spend ti=
me keeping it up to date. And even after removing the compatibility stuff, =
they still can&#39;t use any design space that wouldn&#39;t work on compati=
bility. For example, they can&#39;t ever create a new function called &quot=
;glBegin&quot; because the compatibility profile already has such a functio=
n.<br>
<br>Doing this with a language would be terrible. You would have these hole=
s in the core profile language, these syntactic areas that wouldn&#39;t be =
legal syntax. But you wouldn&#39;t be able to ever <i>use them</i> for some=
 new functionality, because you have to keep compatibility between the two =
profiles. So let&#39;s say you remove C-style arrays from the language. You=
 still couldn&#39;t define `int[5]` to be equivalent to `std::array&lt;int,=
 5&gt;`, because the compatibility profile defines that `int[5]` means some=
thing else.<br>
<br>The core/compatibility distinction is useless from the perspective of t=
rying to open up design space. It&#39;s not useful from the perspective of =
trying to free yourself from old functionality, since every compiler will j=
ust implement compatibility like they always do. So... what&#39;s the point=
 of doing it?<br>
</div></blockquote><div><br></div><div>The only useful thing I could see co=
ming out of this idea would be for compiler writers to provide flags to dis=
able certain language aspects (or turn them into warnings?) , for people th=
at want to stay away from dangerous stuff. Kinda like we can disable except=
ions and RTTI in some of them. But that requires nothing of the committee, =
anyway.<br>
</div><div><br><div>Martinho</div></div></div></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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7bb046f014912804dbb9d729--

.

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

On Thu, May 2, 2013 at 6:38 AM, Martinho Fernandes <
martinho.fernandes@gmail.com> wrote:

>
> The only useful thing I could see coming out of this idea would be for
> compiler writers to provide flags to disable certain language aspects (or
> turn them into warnings?) , for people that want to stay away from
> dangerous stuff. Kinda like we can disable exceptions and RTTI in some of
> them. But that requires nothing of the committee, anyway.
>
> Martinho
>
> --
>

I have always wondered if a version numbering scheme would help.  At the
top of the file do

#version C++11
(or whatever)

That allows breaking changes going forward, but it also means that
compilers would need to basically carry around all their old behaviour
forever.

And who knows whether/how you would allow interoperation between parts
compiled with different versions.

So as much as I'd like it, I doubt its feasibility.

Tony

--

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



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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, May 2, 2013 at 6:38 AM, Martinho Fernandes <span dir=3D"ltr=
">&lt;<a href=3D"mailto:martinho.fernandes@gmail.com" target=3D"_blank">mar=
tinho.fernandes@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div>The only useful thing I could see comin=
g out of this idea would be for compiler writers to provide flags to disabl=
e certain language aspects (or turn them into warnings?) , for people that =
want to stay away from dangerous stuff. Kinda like we can disable exception=
s and RTTI in some of them. But that requires nothing of the committee, any=
way.<span class=3D"HOEnZb"><font color=3D"#888888"><br>

</font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br=
><div>Martinho</div></div></font></span></div></div></div><div class=3D"HOE=
nZb"><div class=3D"h5">

<p></p>

-- <br></div></div></blockquote><div><br></div><div>I have always wondered =
if a version numbering scheme would help.=A0 At the top of the file do <br>=
<br></div><div>#version C++11<br></div><div>(or whatever)<br><br></div><div=
>
That allows breaking changes going forward, but it also means that compiler=
s would need to basically carry around all their old behaviour forever.<br>=
<br></div><div>And who knows whether/how you would allow interoperation bet=
ween parts compiled with different versions.<br>
<br></div><div>So as much as I&#39;d like it, I doubt its feasibility.<br><=
br></div><div>Tony <br></div></div></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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--089e011604f439bfe404dbbd220c--

.

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

If EcmaScript can do it without 're-writing every single line of .... code
out there', C++ could probably do it in a similar way.



2013/5/2 DeadMG <wolfeinstein@gmail.com>

> He doesn't mean just C, he means with C-style C++.
>
> And the simple answer is that that approach will never work for C++. It
> works for DirectX and OGL to reinvent their APIs because firstly, it's just
> an API and there's lots of components of the software that depend on it
> that won't have to be changed, and secondly, developers typically re-write
> their engines often anyway to remain visually competitive, so it's hardly a
> big drain on them. Neither of these is true for C++. You'd be talking about
> re-writing every single line of C++ code out there, and nobody wants to do
> that.
>
> --
>
> ---
> 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.
>
>
>

--

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



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

<div dir=3D"ltr">If EcmaScript can do it without &#39;re-writing every sing=
le line of .... code out there&#39;, C++ could probably do it in a similar =
way.<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"g=
mail_quote">
2013/5/2 DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailto:wolfeinstein@gmail.=
com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;</span><br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
He doesn&#39;t mean just C, he means with C-style C++.<div><br></div><div>A=
nd the simple answer is that that approach will never work for C++. It work=
s for DirectX and OGL to reinvent their APIs because firstly, it&#39;s just=
 an API and there&#39;s lots of components of the software that depend on i=
t that won&#39;t have to be changed, and secondly, developers typically re-=
write their engines often anyway to remain visually competitive, so it&#39;=
s hardly a big drain on them. Neither of these is true for C++. You&#39;d b=
e talking about re-writing every single line of C++ code out there, and nob=
ody wants to do that.</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&quot; 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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--14dae93409f759445704dbbd8ec3--

.

------=_Part_7123_21290123.1367507177486
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, May 2, 2013 7:34:36 AM UTC-7, Tony V E wrote:
>
> On Thu, May 2, 2013 at 6:38 AM, Martinho Fernandes <martinho....@gmail.com<javascript:>
> > wrote:
>
>>
>> The only useful thing I could see coming out of this idea would be for
>> compiler writers to provide flags to disable certain language aspects (or
>> turn them into warnings?) , for people that want to stay away from
>> dangerous stuff. Kinda like we can disable exceptions and RTTI in some of
>> them. But that requires nothing of the committee, anyway.
>>
>> Martinho
>>
>> --
>>
>
> I have always wondered if a version numbering scheme would help.  At the
> top of the file do
>
> #version C++11
> (or whatever)
>
> That allows breaking changes going forward, but it also means that
> compilers would need to basically carry around all their old behaviour
> forever.
>
> And who knows whether/how you would allow interoperation between parts
> compiled with different versions.
>
> So as much as I'd like it, I doubt its feasibility.
>

There's also the fact that #include is based on string copying. A #version
declaration (like in GLSL) would have to come first in a .cpp file. Which
means that every header you include must work with that version. If a lot
of your code is in headers, how do you deal with code that needs to be used
from two different C++ versions?

GLSL (being far less complex than C++. And not having an inclusion model)
doesn't have this problem.

--

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



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

On Thursday, May 2, 2013 7:34:36 AM UTC-7, Tony V E wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
">On Thu, May 2, 2013 at 6:38 AM, Martinho Fernandes <span dir=3D"ltr">&lt;=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"xL_XOZhA=
mQYJ">martinho....@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div><div class=3D"gmai=
l_quote"><div>The only useful thing I could see coming out of this idea wou=
ld be for compiler writers to provide flags to disable certain language asp=
ects (or turn them into warnings?) , for people that want to stay away from=
 dangerous stuff. Kinda like we can disable exceptions and RTTI in some of =
them. But that requires nothing of the committee, anyway.<span><font color=
=3D"#888888"><br>

</font></span></div><span><font color=3D"#888888"><div><br><div>Martinho</d=
iv></div></font></span></div></div></div><div><div>

<p></p>

-- <br></div></div></blockquote><div><br></div><div>I have always wondered =
if a version numbering scheme would help.&nbsp; At the top of the file do <=
br><br></div><div>#version C++11<br></div><div>(or whatever)<br><br></div><=
div>
That allows breaking changes going forward, but it also means that compiler=
s would need to basically carry around all their old behaviour forever.<br>=
<br></div><div>And who knows whether/how you would allow interoperation bet=
ween parts compiled with different versions.<br>
<br></div><div>So as much as I'd like it, I doubt its feasibility.</div></d=
iv></div></div></blockquote><div><br>There's also the fact that #include is=
 based on string copying. A #version declaration (like in GLSL) would have =
to come first in a .cpp file. Which means that every header you include mus=
t work with that version. If a lot of your code is in headers, how do you d=
eal with code that needs to be used from two different C++ versions?<br><br=
>GLSL (being far less complex than C++. And not having an inclusion model) =
doesn't have this problem.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_7123_21290123.1367507177486--

.

On 5/1/2013 23:45, stackmachine@hotmail.com wrote:
> I feel like C++ suffers from a lot of old stuff that needs to be
> mainted for compatibility reasons. Has there been any discussion about
> splitting C++ into a core and compatibility profile, similar to what
> the OpenGL guys did? That would allow us to deprecate or get rid of
> stuff more easily while maintining backwards compatibility.
Related (and open) question -- is something analogous to the Ravenscar
profile (a subset of the Ada) viable / feasible for C++?

Reference:
http://en.wikipedia.org/wiki/Ravenscar_profile

Best,

Matt

--

---
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_425_31386653.1367560003317
Content-Type: text/plain; charset=ISO-8859-1

My 2 cents.
From "The Unfolding of Languages" by Guy Deutscher
How (natural) languages and words evolve? The alternative for the existing
word enters the language. They both will be used simultaneously. After a
period of time the usage of the old word wanes and eventually gets fully
replaced by the new word. For e.g., the plural of cow was keyn in old
English. Later the word cows entered and both were used. Then cows replaced
keyn fully.
(I used a different example from the book to explain what happens)

Probably we can use a similar technique to see that the programming
languages also evolve.
Step 1. Introduce the new technique. The compiler should also support
converting the old technique employed in the existing files to new
technique. This should be done automatically. (Yes, there should be a
change in the specification for the compiler)
Step 2. The compiler should start warning if the old technique is used.
Step 3. The new technique completely takes over the older one.

Take the case of enum class.

1. Introduce enum class. Also introduce enum X = enum class X. This means
enums inside X should be used by :: operator.
2. Compiler should have the ability to replace enum X with enum class X
where it is defined.
3. A warning should be generated.
4. enum class X completely replaces enum X.

I did not take into consideration how to use a enum declared in a C header
file. I only used enum class to demonstrate how to use the technique
(Probably we can introduce #cinclude for C files but that's besides the
point). I don't think it will work for all the features that should be
replaced/deprecated. But for the features it works, we can use it.

Regards,
Hariharan S


On Thursday, May 2, 2013 3:15:30 AM UTC+5:30, stackm...@hotmail.com wrote:
>
> I feel like C++ suffers from a lot of old stuff that needs to be mainted
> for compatibility reasons. Has there been any discussion about splitting
> C++ into a core and compatibility profile, similar to what the OpenGL guys
> did? That would allow us to deprecate or get rid of stuff more easily while
> maintining backwards compatibility.
>

--

---
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_425_31386653.1367560003317
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My 2 cents.<div>From "The Unfolding of Languages" by Guy Deutscher</div><di=
v>How (natural) languages and words evolve? The alternative for the existin=
g word enters the language. They both will be used simultaneously. After a =
period of time the usage of the old word wanes and eventually gets fully re=
placed by the new word. For e.g., the plural of cow was keyn in old English=
.. Later the word cows entered and both were used. Then cows replaced keyn f=
ully.</div><div>(I used a different example from the book to explain what h=
appens)</div><div><br></div><div>Probably we can use a similar technique to=
 see that the programming languages also evolve.</div><div>Step 1. Introduc=
e the new technique. The compiler should also support converting the old te=
chnique employed in the existing files to new technique. This should be don=
e automatically. (Yes, there should be a change in the specification for th=
e compiler)</div><div>Step 2. The compiler should start warning if the old =
technique is used.</div><div>Step 3. The new technique completely takes ove=
r the older one.</div><div><br></div><div>Take the case of enum class.</div=
><div><br></div><div>1. Introduce enum class. Also introduce enum X =3D enu=
m class X. This means enums inside X should be used by :: operator.</div><d=
iv>2. Compiler should have the ability to replace enum X with enum class X =
where it is defined.</div><div>3.&nbsp;A warning should be generated.</div>=
<div>4. enum class X completely replaces enum X.</div><div><br></div><div>I=
 did not take into consideration how to use a enum declared in a C header f=
ile. I only used enum class to demonstrate how to use the technique (Probab=
ly we can introduce #cinclude for C files but that's besides the point). I =
don't think it will work for all the features that should be replaced/depre=
cated. But for the features it works, we can use it.</div><div><br></div><d=
iv>Regards,</div><div>Hariharan S</div><div><div><br><br>On Thursday, May 2=
, 2013 3:15:30 AM UTC+5:30, stackm...@hotmail.com wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">I feel like C++ suffers from a lot of old stuff=
 that needs to be mainted for compatibility reasons. Has there been any dis=
cussion about splitting C++ into a core and compatibility profile, similar =
to what the OpenGL guys did? That would allow us to deprecate or get rid of=
 stuff more easily while maintining backwards compatibility.<br></blockquot=
e></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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_425_31386653.1367560003317--

.

------=_Part_291_5699087.1367565931610
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, May 2, 2013 10:46:43 PM UTC-7, Hariharan Subramanian wrote:
>
> My 2 cents.
> From "The Unfolding of Languages" by Guy Deutscher
> How (natural) languages and words evolve? The alternative for the existing
> word enters the language. They both will be used simultaneously. After a
> period of time the usage of the old word wanes and eventually gets fully
> replaced by the new word. For e.g., the plural of cow was keyn in old
> English. Later the word cows entered and both were used. Then cows replaced
> keyn fully.
> (I used a different example from the book to explain what happens)
>

Once upon a time, that was possible. That's no longer possible now. In
either written English or C++. And oddly enough, for the same reason:
backwards compatibility.

If "cows" was invented in 1995, even if everyone accepted it immediately,
we would still have to learn that "keyn" was a viable alternative. Why?
Because there would still be millions of books printed with "keyn". And
most publishers aren't going to issue reprints to change one word to
another.

The same goes for C++. Even if everyone adopts a technique immediately, the
millions of lines of existing C++ code will not magically disappear or
metamorphosize into the new technique. People are not going to rewrite
functioning code, and quite frankly, they shouldn't. This means that the
standard must still support them.

So until you can come up with a zero-effort and automatic method of
converting one grammatical construct to another, throughout *any* C++
codebase (no matter how convoluted with macros), with *absolutely zero
chance of errors*, the standard must continue to support them. In
perpetuity.

Probably we can use a similar technique to see that the programming
> languages also evolve.
> Step 1. Introduce the new technique. The compiler should also support
> converting the old technique employed in the existing files to new
> technique. This should be done automatically. (Yes, there should be a
> change in the specification for the compiler)
> Step 2. The compiler should start warning if the old technique is used.
> Step 3. The new technique completely takes over the older one.
>
> Take the case of enum class.
>
> 1. Introduce enum class. Also introduce enum X = enum class X. This means
> enums inside X should be used by :: operator.
> 2. Compiler should have the ability to replace enum X with enum class X
> where it is defined.
> 3. A warning should be generated.
> 4. enum class X completely replaces enum X.
>

Um, no. `enum class` does not replace `enum`. Enumerators should not *have*to be strongly typed. To do otherwise not only destroys most of C++'s C
compatibility (ie: C code that can be compiled as C++), it removes a very
useful tool: when you *don't* want an enum to be strongly typed. It takes
away a legitimate choice, which forces people to use other methods like
global constant variables and so forth.


> I did not take into consideration how to use a enum declared in a C header
> file. I only used enum class to demonstrate how to use the technique
> (Probably we can introduce #cinclude for C files but that's besides the
> point). I don't think it will work for all the features that should be
> replaced/deprecated. But for the features it works, we can use it.
>

--

---
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_291_5699087.1367565931610
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, May 2, 2013 10:46:43 PM UTC-7, Hariharan Subramanian w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">My 2 cents.<div>From "The=
 Unfolding of Languages" by Guy Deutscher</div><div>How (natural) languages=
 and words evolve? The alternative for the existing word enters the languag=
e. They both will be used simultaneously. After a period of time the usage =
of the old word wanes and eventually gets fully replaced by the new word. F=
or e.g., the plural of cow was keyn in old English. Later the word cows ent=
ered and both were used. Then cows replaced keyn fully.</div><div>(I used a=
 different example from the book to explain what happens)</div></blockquote=
><div><br>Once upon a time, that was possible. That's no longer possible no=
w. In either written English or C++. And oddly enough, for the same reason:=
 backwards compatibility.<br><br>If "cows" was invented in 1995, even if ev=
eryone accepted it immediately, we would still have to learn that "keyn" wa=
s a viable alternative. Why? Because there would still be millions of books=
 printed with "keyn". And most publishers aren't going to issue reprints to=
 change one word to another.<br><br>The same goes for C++. Even if everyone=
 adopts a technique immediately, the millions of lines of existing C++ code=
 will not magically disappear or metamorphosize into the new technique. Peo=
ple are not going to rewrite functioning code, and quite frankly, they shou=
ldn't. This means that the standard must still support them.<br><br>So unti=
l you can come up with a zero-effort and automatic method of converting one=
 grammatical construct to another, throughout <i>any</i> C++ codebase (no m=
atter how convoluted with macros), with <i>absolutely zero chance of errors=
</i>, the standard must continue to support them. In perpetuity.<br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div>Probably we can use a =
similar technique to see that the programming languages also evolve.</div><=
div>Step 1. Introduce the new technique. The compiler should also support c=
onverting the old technique employed in the existing files to new technique=
.. This should be done automatically. (Yes, there should be a change in the =
specification for the compiler)</div><div>Step 2. The compiler should start=
 warning if the old technique is used.</div><div>Step 3. The new technique =
completely takes over the older one.</div><div><br></div><div>Take the case=
 of enum class.</div><div><br></div><div>1. Introduce enum class. Also intr=
oduce enum X =3D enum class X. This means enums inside X should be used by =
:: operator.</div><div>2. Compiler should have the ability to replace enum =
X with enum class X where it is defined.</div><div>3.&nbsp;A warning should=
 be generated.</div><div>4. enum class X completely replaces enum X.</div><=
/blockquote><div><br>Um, no. `enum class` does not replace `enum`. Enumerat=
ors should not <i>have</i> to be strongly typed. To do otherwise not only d=
estroys most of C++'s C compatibility (ie: C code that can be compiled as C=
++), it removes a very useful tool: when you <i>don't</i> want an enum to b=
e strongly typed. It takes away a legitimate choice, which forces people to=
 use other methods like global constant variables and so forth.<br>&nbsp;</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div>I did not take into c=
onsideration how to use a enum declared in a C header file. I only used enu=
m class to demonstrate how to use the technique (Probably we can introduce =
#cinclude for C files but that's besides the point). I don't think it will =
work for all the features that should be replaced/deprecated. But for the f=
eatures it works, we can use it.</div></blockquote>

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_291_5699087.1367565931610--

.

------=_Part_444_22038392.1367573279721
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, May 2, 2013 11:06:17 PM UTC+8, Nicol Bolas wrote:
>
> There's also the fact that #include is based on string copying. A #version
> declaration (like in GLSL) would have to come first in a .cpp file. Which
> means that every header you include must work with that version. If a lot
> of your code is in headers, how do you deal with code that needs to be used
> from two different C++ versions?
>
> GLSL (being far less complex than C++. And not having an inclusion model)
> doesn't have this problem.
>

Remember when a .cpp file wants to include a C's header, We may write
extern "C"{
  include "c_header.h"
}

A similar method could be introduced too. For example:
#version C++11
extern C++03{
  include "foo.h"
   // Or, the extern C++03 may be placed inside the foo.h:
   // #ifdef __cplusplus11__
   // extern "C++03{
  // ...
}
// blah blah blah...


--

---
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_444_22038392.1367573279721
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, May 2, 2013 11:06:17 PM UTC+8, Nicol Bolas wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">There's also the fact that #include is base=
d on string copying. A #version declaration (like in GLSL) would have to co=
me first in a .cpp file. Which means that every header you include must wor=
k with that version. If a lot of your code is in headers, how do you deal w=
ith code that needs to be used from two different C++ versions?<br><div><br=
>GLSL (being far less complex than C++. And not having an inclusion model) =
doesn't have this problem.<br></div></blockquote><div><br>Remember when a .=
cpp file wants to include a C's header, We may write<br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">extern</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">"C"</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; include </span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"c_header.h"</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span></div></code></div><br>A similar method could be intr=
oduced too. For example:<br><div class=3D"prettyprint" style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">#version C++11</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">extern</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> C</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">++</span><span style=3D"color: #066;" class=3D"styled-by-prettify">03</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; include </sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify">"foo.h"</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Or, the=
 extern C++03 may</span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify"> be placed inside the foo.h:</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// #ifdef __cplusplus11__</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;</span><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">// extern "C++03{</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </s=
pan><span style=3D"color: #800;" class=3D"styled-by-prettify">// ...</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #800;" class=3D"styled-by-prettify">// blah blah blah...</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></code>=
</div><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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_444_22038392.1367573279721--

.

------=_Part_179_31211112.1367575173448
Content-Type: text/plain; charset=ISO-8859-1



On Friday, May 3, 2013 10:27:59 AM UTC+1, pon...@qq.com wrote:
>
>
>
> Remember when a .cpp file wants to include a C's header, We may write
> extern "C"{
>   include "c_header.h"
> }
>
> A similar method could be introduced too. For example:
> #version C++11
> extern C++03{
>   include "foo.h"
>    // Or, the extern C++03 may be placed inside the foo.h:
>    // #ifdef __cplusplus11__
>

(This check should be __cplusplus == 201103L or __cplusplus >= 201103L)


>    // extern "C++03{
>   // ...
> }
> // blah blah blah...
>
>
>
But extern "C" doesn't change the language features available (except for
overloading function names), you can still use exceptions  and references
inside an extern "C" block, so I don't think it's a good analogy.




--

---
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_179_31211112.1367575173448
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, May 3, 2013 10:27:59 AM UTC+1, pon...@qq.com 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><br>Remember when a .cpp f=
ile wants to include a C's header, We may write<br><div style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008">=
extern</span><span style=3D"color:#000"> </span><span style=3D"color:#080">=
"C"</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br=
>&nbsp; include </span><span style=3D"color:#080">"c_header.h"</span><span =
style=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span st=
yle=3D"color:#000"><br></span></div></code></div><br>A similar method could=
 be introduced too. For example:<br><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:#800">#version C++11<=
/span><span style=3D"color:#000"><br></span><span style=3D"color:#008">exte=
rn</span><span style=3D"color:#000"> C</span><span style=3D"color:#660">++<=
/span><span style=3D"color:#066">03</span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#000"><br>&nbsp; include </span><span style=3D"color=
:#080">"foo.h"</span><span style=3D"color:#000"><br>&nbsp; &nbsp;</span><sp=
an style=3D"color:#800">// Or, the extern C++03 may</span><span style=3D"co=
lor:#800"> be placed inside the foo.h:</span><span style=3D"color:#000"><br=
>&nbsp; &nbsp;</span><span style=3D"color:#800">// #ifdef __cplusplus11__</=
span><span style=3D"color:#000"><br></span></div></code></div></div></block=
quote><div><br>(This check should be __cplusplus =3D=3D 201103L or __cplusp=
lus &gt;=3D 201103L)<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><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"><co=
de><div><span style=3D"color:#000">&nbsp; &nbsp;</span><span style=3D"color=
:#800">// extern "C++03{</span><span style=3D"color:#000"><br>&nbsp; </span=
><span style=3D"color:#800">// ...</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></spa=
n><span style=3D"color:#800">// blah blah blah...</span><span style=3D"colo=
r:#000"><br><br></span></div></code></div><br></div></blockquote><div><br>B=
ut extern "C" doesn't change the language features available (except for ov=
erloading function names), you can still use exceptions&nbsp; and reference=
s inside an extern "C" block, so I don't think it's a good analogy.<br><br>=
<br>&nbsp;</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_179_31211112.1367575173448--

.

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

I suspect you could do some versioning with modules.  Since modules greatly
reduce and constrain the interface between headers/libraries and cpp files.


On Fri, May 3, 2013 at 5:59 AM, Jonathan Wakely <cxx@kayari.org> wrote:

>
>
> On Friday, May 3, 2013 10:27:59 AM UTC+1, pon...@qq.com wrote:
>>
>>
>>
>> Remember when a .cpp file wants to include a C's header, We may write
>> extern "C"{
>>   include "c_header.h"
>> }
>>
>> A similar method could be introduced too. For example:
>> #version C++11
>> extern C++03{
>>   include "foo.h"
>>    // Or, the extern C++03 may be placed inside the foo.h:
>>    // #ifdef __cplusplus11__
>>
>
> (This check should be __cplusplus == 201103L or __cplusplus >= 201103L)
>
>
>>    // extern "C++03{
>>   // ...
>> }
>> // blah blah blah...
>>
>>
>>
> But extern "C" doesn't change the language features available (except for
> overloading function names), you can still use exceptions  and references
> inside an extern "C" block, so I don't think it's a good analogy.
>
>
>
>
> --
>
> ---
> 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.
>
>
>

--

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



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

<div dir=3D"ltr">I suspect you could do some versioning with modules.=A0 Si=
nce modules greatly reduce and constrain the interface between headers/libr=
aries and cpp files.<br></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">
On Fri, May 3, 2013 at 5:59 AM, Jonathan Wakely <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br><br>On Friday, May 3, 2013 10:27:59 AM UTC+1, <a href=
=3D"mailto:pon...@qq.com" target=3D"_blank">pon...@qq.com</a> wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<br><div><br>Remember when a .cpp file wants to include a C&#39;s header, W=
e may write<br><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">extern</span><span style> </span><spa=
n style=3D"color:#080">&quot;C&quot;</span><span style=3D"color:#660">{</sp=
an><span style><br>=A0 include </span><span style=3D"color:#080">&quot;c_he=
ader.h&quot;</span><span style><br>
</span><span style=3D"color:#660">}</span><span style><br></span></div></co=
de></div><br>A similar method could be introduced too. For example:<br><div=
 style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);b=
order-style:solid;border-width:1px;word-wrap:break-word">
<code><div><span style=3D"color:#800">#version C++11</span><span style><br>=
</span><span style=3D"color:#008">extern</span><span style> C</span><span s=
tyle=3D"color:#660">++</span><span style=3D"color:#066">03</span><span styl=
e=3D"color:#660">{</span><span style><br>
=A0 include </span><span style=3D"color:#080">&quot;foo.h&quot;</span><span=
 style><br>=A0 =A0</span><span style=3D"color:#800">// Or, the extern C++03=
 may</span><span style=3D"color:#800"> be placed inside the foo.h:</span><s=
pan style><br>
=A0 =A0</span><span style=3D"color:#800">// #ifdef __cplusplus11__</span><s=
pan style><br></span></div></code></div></div></blockquote></div><div><br>(=
This check should be __cplusplus =3D=3D 201103L or __cplusplus &gt;=3D 2011=
03L)<br>
=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><di=
v 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>=A0 =A0</span><span style=3D"color:#800">// extern &=
quot;C++03{</span><span style><br>=A0 </span><span style=3D"color:#800">// =
....</span><span style><br></span><span style=3D"color:#660">}</span><span s=
tyle><br>
</span><span style=3D"color:#800">// blah blah blah...</span><span style><b=
r><br></span></div></code></div><br></div></blockquote></div><div><br>But e=
xtern &quot;C&quot; doesn&#39;t change the language features available (exc=
ept for overloading function names), you can still use exceptions=A0 and re=
ferences inside an extern &quot;C&quot; block, so I don&#39;t think it&#39;=
s a good analogy.<br>
<br><br>=A0</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&quot; 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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--e89a8f83a63d57a65e04dbd526ec--

.

------=_Part_44_17686233.1367609064282
Content-Type: text/plain; charset=ISO-8859-1

Even if such a feature were to exist that could seamlessly interface "new"
code and "old" code, defining the "new" code to take full advantage of the
opportunity would be no more and no less than defining an entire new
language. That's more work than I think the Committee would be prepared to
risk on it.

--

---
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_44_17686233.1367609064282
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Even if such a feature were to exist that could seamlessly interface "new" =
code and "old" code, defining the "new" code to take full advantage of the =
opportunity would be no more and no less than defining an entire new langua=
ge. That's more work than I think the Committee would be prepared to risk o=
n it.

<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_44_17686233.1367609064282--

.