Topic: [N3628] C and C++: a Case for Compatibility
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 10 Apr 2013 12:28:45 -0700 (PDT)
Raw View
------=_Part_135_19416120.1365622125773
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Bjarne Stroustrup:
> It seems that a serious discussion about C/C++ compatibility is starting.
Where?
> What would be the result of a systematic process of increasing=20
compatibility? A single language called
C or C++? Possibly, I consider it more likely that it would be a language=
=20
called C++ with a preciselyspecified subset called C. I=92m no fan of=20
language subsetting, but I do respect the people who insist that
something smaller than C++ is important in some application areas and in=20
some communities.
I've been seriously wondering, what application areas and communites being=
=20
referred to?
What's stopping them from using this subset of C++ (and a C++ compiler)?
--=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/?hl=3Den.
------=_Part_135_19416120.1365622125773
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div>Bjarne Stroustrup:<br></div>> It seems that a serious discussi=
on about C/C++ compatibility is starting.<div><br></div><div>Where?</div><d=
iv><br></div><div>> What would be the result of a systematic process of =
increasing compatibility? A single language called</div><div>C or C++? Poss=
ibly, I consider it more likely that it would be a language called C++ with=
a preciselyspecified subset called C. I=92m no fan of language subsetting,=
but I do respect the people who insist that</div><div>something smaller th=
an C++ is important in some application areas and in some communities.</div=
><div><br></div><div>I've been seriously wondering, what application areas =
and communites being referred to?</div><div>What's stopping them from using=
this subset of C++ (and a C++ compiler)?</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_135_19416120.1365622125773--
.
Author: "Ricardo A." <ricardofabianodeandrade@gmail.com>
Date: Sat, 13 Apr 2013 21:06:06 -0700 (PDT)
Raw View
------=_Part_3843_9145084.1365912366722
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Wednesday, April 10, 2013 4:28:45 PM UTC-3, Olaf van der Spek wrote:
> Bjarne Stroustrup:
> > It seems that a serious discussion about C/C++ compatibility is startin=
g.
>
> Where?
>
AFAIK, internally in both WG21 and WG14.
> =20
>
> What would be the result of a systematic process of increasing=20
> compatibility? A single language called
> C or C++? Possibly, I consider it more likely that it would be a language=
=20
> called C++ with a preciselyspecified subset called C. I=92m no fan of=20
> language subsetting, but I do respect the people who insist that
> something smaller than C++ is important in some application areas and in=
=20
> some communities.
>
> I've been seriously wondering, what application areas and communites bein=
g=20
> referred to?
> What's stopping them from using this subset of C++ (and a C++ compiler)?
>
Embedded software development is one of them.=20
Some architectures (niches) don't have C++ compilers only plain C ones for=
=20
a number of reasons (spending/money time to write/port a complex C++=20
compiler is the biggest of them).
This community is greatly benefited of each improved C standard but they=20
even care about C++.
For each new C++ programmable device, there's a dozen of smaller/slowers=20
other that are only programmable in C.
I know Stroustrup doesn't like much this idea, but in my opinion is that we=
=20
should have a 'Classic C' standard (or it should be part of the WG14 work).
Then both modern C and modern C++ could freely derive from it. When=20
interoperability is required, either C or C++ code must rely on this=20
'Classic C' to talk each other.
It's something like we already have in the real world, it's just a question=
=20
of making it official and writing it down.
The alternative of forcing C++ to have a perfect subset of each latest C=20
standard is unlikely to work and dropping the C support from C++ would not=
=20
be beneficial for the C/C++ community (it shouldn't even be considered).
What 'Classic C' would look like? Probably equivalent to what C++11=20
supports from C plus some extra compatibility inside /extern "C"/ braces=20
(e.g. making void* behaving like in C).
I think it's a perfect time to discuss this subject.
--=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/?hl=3Den.
------=_Part_3843_9145084.1365912366722
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Wednesday, April 10, 2013 4:28:45 PM UTC-3, Olaf van der Spek wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div>Bjarne Stroustrup:<br></d=
iv>> It seems that a serious discussion about C/C++ compatibility i=
s starting.<div><br></div><div>Where?</div></blockquote><div>AFAIK, interna=
lly in both WG21 and WG14.</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div> </div></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div>> What would be the result of a systematic process of increasing =
compatibility? A single language called</div><div>C or C++? Possibly, I con=
sider it more likely that it would be a language called C++ with a precisel=
yspecified subset called C. I=92m no fan of language subsetting, but I do r=
espect the people who insist that</div><div>something smaller than C++ is i=
mportant in some application areas and in some communities.</div><div><br><=
/div><div>I've been seriously wondering, what application areas and communi=
tes being referred to?</div><div>What's stopping them from using this subse=
t of C++ (and a C++ compiler)?</div></blockquote><div><br></div><div>Embedd=
ed software development is one of them. </div><div>Some architectures =
(niches) don't have C++ compilers only plain C ones for a number of reasons=
(spending/money time to write/port a complex C++ compiler is the biggest o=
f them).</div><div>This community is greatly benefited of each improved C s=
tandard but they even care about C++.</div><div>For each new C++ progr=
ammable device, there's a dozen of smaller/slowers other that are only prog=
rammable in C.</div><div><br></div><div>I know Stroustrup doesn't like much=
this idea, but in my opinion is that we should have a 'Classic C' standard=
(or it should be part of the WG14 work).</div><div>Then both modern C and =
modern C++ could freely derive from it. When interoperability is required, =
either C or C++ code must rely on this 'Classic C' to talk each other.</div=
><div>It's something like we already have in the real world, it's just a qu=
estion of making it official and writing it down.</div><div><br></div><div>=
The alternative of forcing C++ to have a perfect subset of each latest C st=
andard is unlikely to work and dropping the C support from C++ would not be=
beneficial for the C/C++ community (it shouldn't even be considered).=
</div><div>What 'Classic C' would look like? Probably equivalent to what C+=
+11 supports from C plus some extra compatibility inside /extern "C"/ brace=
s (e.g. making void* behaving like in C).<br></div><div><br></div><div>I th=
ink it's a perfect time to discuss this subject.</div><div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_3843_9145084.1365912366722--
.
Author: Bb Hh <frankhb1989@gmail.com>
Date: Sun, 14 Apr 2013 12:45:05 +0800
Raw View
--20cf307f3626d4e60404da4acc51
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
extern "classic C" or just extern "C"?
2013/4/14 Ricardo A. <ricardofabianodeandrade@gmail.com>
> On Wednesday, April 10, 2013 4:28:45 PM UTC-3, Olaf van der Spek wrote:
>
>> Bjarne Stroustrup:
>> > It seems that a serious discussion about C/C++ compatibility is
>> starting.
>>
>> Where?
>>
> AFAIK, internally in both WG21 and WG14.
>
>>
>>
> > What would be the result of a systematic process of increasing
>> compatibility? A single language called
>> C or C++? Possibly, I consider it more likely that it would be a languag=
e
>> called C++ with a preciselyspecified subset called C. I=92m no fan of
>> language subsetting, but I do respect the people who insist that
>> something smaller than C++ is important in some application areas and in
>> some communities.
>>
>> I've been seriously wondering, what application areas and communites
>> being referred to?
>> What's stopping them from using this subset of C++ (and a C++ compiler)?
>>
>
> Embedded software development is one of them.
> Some architectures (niches) don't have C++ compilers only plain C ones fo=
r
> a number of reasons (spending/money time to write/port a complex C++
> compiler is the biggest of them).
> This community is greatly benefited of each improved C standard but they
> even care about C++.
> For each new C++ programmable device, there's a dozen of smaller/slowers
> other that are only programmable in C.
>
> I know Stroustrup doesn't like much this idea, but in my opinion is that
> we should have a 'Classic C' standard (or it should be part of the WG14
> work).
> Then both modern C and modern C++ could freely derive from it. When
> interoperability is required, either C or C++ code must rely on this
> 'Classic C' to talk each other.
> It's something like we already have in the real world, it's just a
> question of making it official and writing it down.
>
> The alternative of forcing C++ to have a perfect subset of each latest C
> standard is unlikely to work and dropping the C support from C++ would no=
t
> be beneficial for the C/C++ community (it shouldn't even be considered).
> What 'Classic C' would look like? Probably equivalent to what C++11
> supports from C plus some extra compatibility inside /extern "C"/ braces
> (e.g. making void* behaving like in C).
>
> I think it's a perfect time to discuss this subject.
>
> --
>
> ---
> 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=3Den.
>
>
>
--=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/?hl=3Den.
--20cf307f3626d4e60404da4acc51
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">extern "classic C" or just extern "C"?=
<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">201=
3/4/14 Ricardo A. <span dir=3D"ltr"><<a href=3D"mailto:ricardofabianodea=
ndrade@gmail.com" target=3D"_blank">ricardofabianodeandrade@gmail.com</a>&g=
t;</span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Wednesday, April 10, 20=
13 4:28:45 PM UTC-3, Olaf van der Spek wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div>Bjarne Stroustrup:<br></div>>=A0It seems that a serious discussion =
about C/C++ compatibility is starting.<div><br></div><div>Where?</div></blo=
ckquote></div><div>AFAIK, internally in both WG21 and WG14.</div><div class=
=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>=A0</div></blockquote><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div>> What would be the result of a systematic process of increasing co=
mpatibility? A single language called</div><div>C or C++? Possibly, I consi=
der it more likely that it would be a language called C++ with a preciselys=
pecified subset called C. I=92m no fan of language subsetting, but I do res=
pect the people who insist that</div>
<div>something smaller than C++ is important in some application areas and =
in some communities.</div><div><br></div><div>I've been seriously wonde=
ring, what application areas and communites being referred to?</div><div>
What's stopping them from using this subset of C++ (and a C++ compiler)=
?</div></blockquote><div><br></div></div><div>Embedded software development=
is one of them.=A0</div><div>Some architectures (niches) don't have C+=
+ compilers only plain C ones for a number of reasons (spending/money time =
to write/port a complex C++ compiler is the biggest of them).</div>
<div>This community is greatly benefited of each improved C standard but th=
ey even care about C++.</div><div>For each new C++=A0programmable device, t=
here's a dozen of smaller/slowers other that are only programmable in C=
..</div>
<div><br></div><div>I know Stroustrup doesn't like much this idea, but =
in my opinion is that we should have a 'Classic C' standard (or it =
should be part of the WG14 work).</div><div>Then both modern C and modern C=
++ could freely derive from it. When interoperability is required, either C=
or C++ code must rely on this 'Classic C' to talk each other.</div=
>
<div>It's something like we already have in the real world, it's ju=
st a question of making it official and writing it down.</div><div><br></di=
v><div>The alternative of forcing C++ to have a perfect subset of each late=
st C standard is unlikely to work and dropping the C support from C++ would=
not be=A0beneficial for the C/C++ community (it shouldn't even be cons=
idered).</div>
<div>What 'Classic C' would look like? Probably equivalent to what =
C++11 supports from C plus some extra compatibility inside /extern "C&=
quot;/ braces (e.g. making void* behaving like in C).<br></div><div><br>
</div><div>I think it's a perfect time to discuss this subject.</div><d=
iv class=3D"HOEnZb"><div class=3D"h5"><div><br></div>
<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/?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 />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--20cf307f3626d4e60404da4acc51--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Sun, 14 Apr 2013 01:18:06 -0700 (PDT)
Raw View
------=_Part_3951_18592973.1365927486824
Content-Type: text/plain; charset=ISO-8859-1
Ricardo, I'm not really seeing how that's going to happen. We already have
something like that, it's called C89. The problem of C and C++
compatibility, IME, isn't a problem for C++, it's a problem for C, because
it's the C users of the world who can't upgrade their compilers or
interfaces without breaking C++ compatibility.
Frankly, I would support divergence more than merging. I don't believe that
it would be desirable to do all of the work that would be necessary to
yield a real improvement in C and C++ compatibility at this stage. The
simple fact is that C and C++ have taken different paths on many issues.
Maybe if there had been a focus on maintaining compatibility whilst C99 and
C++98 were being Standardised.
The only other alternative is to take a radically new approach to
compatibility, like semantic compatibility, rather than aiming for source
compatibility. I've been investigating such an approach and it seems to
work well for now, so perhaps it's worth considering.
--
---
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_3951_18592973.1365927486824
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Ricardo, I'm not really seeing how that's going to happen. We already have =
something like that, it's called C89. The problem of C and C++ compatibilit=
y, IME, isn't a problem for C++, it's a problem for C, because it's the C u=
sers of the world who can't upgrade their compilers or interfaces without b=
reaking C++ compatibility.<div><br></div><div>Frankly, I would support dive=
rgence more than merging. I don't believe that it would be desirable to do =
all of the work that would be necessary to yield a real improvement in C an=
d C++ compatibility at this stage. The simple fact is that C and C++ have t=
aken different paths on many issues. Maybe if there had been a focus on mai=
ntaining compatibility whilst C99 and C++98 were being Standardised.</div><=
div><br></div><div>The only other alternative is to take a radically new ap=
proach to compatibility, like semantic compatibility, rather than aiming fo=
r source compatibility. I've been investigating such an approach and it see=
ms to work well for now, so perhaps it's worth considering.</div><div><br><=
/div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_3951_18592973.1365927486824--
.
Author: ricardofabianodeandrade@gmail.com
Date: Sun, 14 Apr 2013 10:41:25 -0700 (PDT)
Raw View
------=_Part_117_18189937.1365961285922
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Initially, I would rather just extern "C" was we know. But "classic C" is=
=20
not a bad idea at all.
On Sunday, April 14, 2013 1:45:05 AM UTC-3, FrankHB1989 wrote:
>
> extern "classic C" or just extern "C"?
>
>
> 2013/4/14 Ricardo A. <ricardofabi...@gmail.com <javascript:>>
>
>> On Wednesday, April 10, 2013 4:28:45 PM UTC-3, Olaf van der Spek wrote:
>>
>>> Bjarne Stroustrup:
>>> > It seems that a serious discussion about C/C++ compatibility is=20
>>> starting.
>>>
>>> Where?
>>>
>> AFAIK, internally in both WG21 and WG14.
>>
>>> =20
>>>
>> > What would be the result of a systematic process of increasing=20
>>> compatibility? A single language called
>>> C or C++? Possibly, I consider it more likely that it would be a=20
>>> language called C++ with a preciselyspecified subset called C. I=92m no=
fan=20
>>> of language subsetting, but I do respect the people who insist that
>>> something smaller than C++ is important in some application areas and i=
n=20
>>> some communities.
>>>
>>> I've been seriously wondering, what application areas and communites=20
>>> being referred to?
>>> What's stopping them from using this subset of C++ (and a C++ compiler)=
?
>>>
>>
>> Embedded software development is one of them.=20
>> Some architectures (niches) don't have C++ compilers only plain C ones=
=20
>> for a number of reasons (spending/money time to write/port a complex C++=
=20
>> compiler is the biggest of them).
>> This community is greatly benefited of each improved C standard but they=
=20
>> even care about C++.
>> For each new C++ programmable device, there's a dozen of smaller/slowers=
=20
>> other that are only programmable in C.
>>
>> I know Stroustrup doesn't like much this idea, but in my opinion is that=
=20
>> we should have a 'Classic C' standard (or it should be part of the WG14=
=20
>> work).
>> Then both modern C and modern C++ could freely derive from it. When=20
>> interoperability is required, either C or C++ code must rely on this=20
>> 'Classic C' to talk each other.
>> It's something like we already have in the real world, it's just a=20
>> question of making it official and writing it down.
>>
>> The alternative of forcing C++ to have a perfect subset of each latest C=
=20
>> standard is unlikely to work and dropping the C support from C++ would n=
ot=20
>> be beneficial for the C/C++ community (it shouldn't even be considered).
>> What 'Classic C' would look like? Probably equivalent to what C++11=20
>> supports from C plus some extra compatibility inside /extern "C"/ braces=
=20
>> (e.g. making void* behaving like in C).
>>
>> I think it's a perfect time to discuss this subject.
>>
>> --=20
>> =20
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den.
>> =20
>> =20
>>
>
>
--=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/?hl=3Den.
------=_Part_117_18189937.1365961285922
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Initially, I would rather just extern "C" was we know. But "classic C" is n=
ot a bad idea at all.<br><br>On Sunday, April 14, 2013 1:45:05 AM UTC-3, Fr=
ankHB1989 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"lt=
r">extern "classic C" or just extern "C"?<br></div><div><br><br><div class=
=3D"gmail_quote">2013/4/14 Ricardo A. <span dir=3D"ltr"><<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"eSw2r8O7nh0J">ricardofa=
bi...@<wbr>gmail.com</a>></span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On Wednesday, April 10, 2013 4:28:45 PM=
UTC-3, Olaf van der Spek wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div>Bjarne Stroustrup:<br></div>> It seems that a serious discussi=
on about C/C++ compatibility is starting.<div><br></div><div>Where?</div></=
blockquote></div><div>AFAIK, internally in both WG21 and WG14.</div><div>
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div> </div></blockquote><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div>> What would be the result of a systematic process of increasing co=
mpatibility? A single language called</div><div>C or C++? Possibly, I consi=
der it more likely that it would be a language called C++ with a preciselys=
pecified subset called C. I=92m no fan of language subsetting, but I do res=
pect the people who insist that</div>
<div>something smaller than C++ is important in some application areas and =
in some communities.</div><div><br></div><div>I've been seriously wondering=
, what application areas and communites being referred to?</div><div>
What's stopping them from using this subset of C++ (and a C++ compiler)?</d=
iv></blockquote><div><br></div></div><div>Embedded software development is =
one of them. </div><div>Some architectures (niches) don't have C++ com=
pilers only plain C ones for a number of reasons (spending/money time to wr=
ite/port a complex C++ compiler is the biggest of them).</div>
<div>This community is greatly benefited of each improved C standard but th=
ey even care about C++.</div><div>For each new C++ programmable device=
, there's a dozen of smaller/slowers other that are only programmable in C.=
</div>
<div><br></div><div>I know Stroustrup doesn't like much this idea, but in m=
y opinion is that we should have a 'Classic C' standard (or it should be pa=
rt of the WG14 work).</div><div>Then both modern C and modern C++ could fre=
ely derive from it. When interoperability is required, either C or C++ code=
must rely on this 'Classic C' to talk each other.</div>
<div>It's something like we already have in the real world, it's just a que=
stion of making it official and writing it down.</div><div><br></div><div>T=
he alternative of forcing C++ to have a perfect subset of each latest C sta=
ndard is unlikely to work and dropping the C support from C++ would not be&=
nbsp;beneficial for the C/C++ community (it shouldn't even be considered).<=
/div>
<div>What 'Classic C' would look like? Probably equivalent to what C++11 su=
pports from C plus some extra compatibility inside /extern "C"/ braces (e.g=
.. making void* behaving like in C).<br></div><div><br>
</div><div>I think it's a perfect time to discuss this subject.</div><div><=
div><div><br></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
eSw2r8O7nh0J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"eSw2r8O7nh0J">std-pr...@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/<wbr>i=
socpp.org/group/std-<wbr>proposals/?hl=3Den</a>.<br>
<br>
<br>
</div></div></blockquote></div><br></div>
</blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_117_18189937.1365961285922--
.
Author: ricardofabianodeandrade@gmail.com
Date: Sun, 14 Apr 2013 11:28:57 -0700 (PDT)
Raw View
------=_Part_4415_31410957.1365964137629
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, April 14, 2013 5:18:06 AM UTC-3, DeadMG wrote:
> Ricardo, I'm not really seeing how that's going to happen. We already have
> something like that, it's called C89. The problem of C and C++
> compatibility, IME, isn't a problem for C++, it's a problem for C, because
> it's the C users of the world who can't upgrade their compilers or
> interfaces without breaking C++ compatibility.
You may have a point.
>
> Frankly, I would support divergence more than merging. I don't believe
> that it would be desirable to do all of the work that would be necessary to
> yield a real improvement in C and C++ compatibility at this stage. The
> simple fact is that C and C++ have taken different paths on many issues.
> Maybe if there had been a focus on maintaining compatibility whilst C99 and
> C++98 were being Standardised.
>
> I also strongly believe both languages would benefit from being free to
diverge from each other.
I just don't think they should diverge at the point of being impossible to
include a C header or link a C library from C++ (and vice-versa).
I have been reading even further about C/C++ incompatibilities and while
some items would have a potential of being adopted by the C++ standard
others are complete nonsense in the C++ world.
Well, I still think that's a good idea to improve the C compatibility in
the context of /extern "C"/ braces (what would make that more than just a
linkage option).
> The only other alternative is to take a radically new approach to
> compatibility, like semantic compatibility, rather than aiming for source
> compatibility. I've been investigating such an approach and it seems to
> work well for now, so perhaps it's worth considering.
>
> Would you mind to explain, exemplify or point where we can see more about
this approach of "semantic compatibility"?
I think fresh ideas over this (very) old issue are always welcome.
--
---
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_4415_31410957.1365964137629
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>On Sunday, April 14, 2013 5:18:06 AM UTC-3, DeadMG wrote:<br></div><di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Ricardo, I'm not really seei=
ng how that's going to happen. We already have something like that, it's ca=
lled C89. The problem of C and C++ compatibility, IME, isn't a problem for =
C++, it's a problem for C, because it's the C users of the world who can't =
upgrade their compilers or interfaces without breaking C++ compatibility.</=
blockquote><div><br></div><div>You may have a point.<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
#ccc solid;padding-left: 1ex;"><div><br></div><div>Frankly, I would suppor=
t divergence more than merging. I don't believe that it would be desirable =
to do all of the work that would be necessary to yield a real improvement i=
n C and C++ compatibility at this stage. The simple fact is that C and C++ =
have taken different paths on many issues. Maybe if there had been a focus =
on maintaining compatibility whilst C99 and C++98 were being Standardised.<=
/div><div><br></div></blockquote><div>I also strongly believe both language=
s would benefit from being free to diverge from each other.</div><div>I jus=
t don't think they should diverge at the point of being impossible to inclu=
de a C header or link a C library from C++ (and vice-versa).</div><div>I ha=
ve been reading even further about C/C++ incompatibilities and while some i=
tems would have a potential of being adopted by the C++ standard others are=
complete nonsense in the C++ world.<br></div><div>Well, I still think that=
's a good idea to improve the C compatibility in the context of /extern "C"=
/ braces (what would make that more than just a linkage option).</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></div><di=
v>The only other alternative is to take a radically new approach to compati=
bility, like semantic compatibility, rather than aiming for source compatib=
ility. I've been investigating such an approach and it seems to work well f=
or now, so perhaps it's worth considering.</div><div><br></div></blockquote=
><div>Would you mind to explain, exemplify or point where we can see more a=
bout this approach of "semantic compatibility"?</div><div>I think fresh ide=
as over this (very) old issue are always welcome.</div><div><br></div><div>=
<br></div><div> </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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_4415_31410957.1365964137629--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Tue, 16 Apr 2013 03:42:34 -0700 (PDT)
Raw View
------=_Part_6276_30633189.1366108954749
Content-Type: text/plain; charset=ISO-8859-1
The basic idea behind semantic compatibility is to keep the two systems
separate- so you have an existing C++11 compiler and a separate C11
compiler. For my experience I used Clang for this purpose. Then, you
introduce a primitive that includes a C header, and you create a C++ "view"
of that C TU. So you might suggest that a _Generic macro could be "viewed"
as an overload set. So I might say
using ctu = c11_include("some_c11_header.h");
int main() {
ctu::some_type t; // equivalent to some_type t; in C
ctu::__struct::name s; // equivalent to struct name s; in C
ctu::sqrt(1.0f); // Invokes generic macro
}
You might say that a VLA could be "viewed" as a pair of pointers, or
something similar. The implementation builds a bridge between the two
systems, so the C code appears as a C++ interface, and then the
implementation is responsible for building trampolines and such things.
--
---
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_6276_30633189.1366108954749
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
The basic idea behind semantic compatibility is to keep the two systems sep=
arate- so you have an existing C++11 compiler and a separate C11 compiler. =
For my experience I used Clang for this purpose. Then, you introduce a prim=
itive that includes a C header, and you create a C++ "view" of that C TU. S=
o you might suggest that a _Generic macro could be "viewed" as an overload =
set. So I might say<div><br></div><div> using ctu =3D c11_incl=
ude("some_c11_header.h");</div><div> int main() {</div><div>&n=
bsp; ctu::some_type t; // equivalent to some_type t; i=
n C</div><div> ctu::__struct::name s; // equival=
ent to struct name s; in C</div><div> ctu::sqrt(=
1.0f); // Invokes generic macro</div><div> }</div><div><br></d=
iv><div>You might say that a VLA could be "viewed" as a pair of pointers, o=
r something similar. The implementation builds a bridge between the two sys=
tems, so the C code appears as a C++ interface, and then the implementation=
is responsible for building trampolines and such things.</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_6276_30633189.1366108954749--
.
Author: 3dw4rd@verizon.net
Date: Tue, 16 Apr 2013 15:46:00 -0700 (PDT)
Raw View
------=_Part_2061_12936621.1366152360893
Content-Type: text/plain; charset=ISO-8859-1
This looks tantalizingly close to a partial solution for modules. Either
that or it could interfere with modules ;-). Did you implementation use
the modules work that is going on in clang?
On Tuesday, April 16, 2013 6:42:34 AM UTC-4, DeadMG wrote:
>
> The basic idea behind semantic compatibility is to keep the two systems
> separate- so you have an existing C++11 compiler and a separate C11
> compiler. For my experience I used Clang for this purpose. Then, you
> introduce a primitive that includes a C header, and you create a C++ "view"
> of that C TU. So you might suggest that a _Generic macro could be "viewed"
> as an overload set. So I might say
>
> using ctu = c11_include("some_c11_header.h");
> int main() {
> ctu::some_type t; // equivalent to some_type t; in C
> ctu::__struct::name s; // equivalent to struct name s; in C
> ctu::sqrt(1.0f); // Invokes generic macro
> }
>
> You might say that a VLA could be "viewed" as a pair of pointers, or
> something similar. The implementation builds a bridge between the two
> systems, so the C code appears as a C++ interface, and then the
> implementation is responsible for building trampolines and such things.
>
--
---
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_2061_12936621.1366152360893
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
This looks tantalizingly close to a partial solution for modules. Eit=
her that or it could interfere with modules ;-). Did you implementati=
on use the modules work that is going on in clang?<br><br>On Tuesday, April=
16, 2013 6:42:34 AM UTC-4, DeadMG wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">The basic idea behind semantic compatibility is to keep the two =
systems separate- so you have an existing C++11 compiler and a separate C11=
compiler. For my experience I used Clang for this purpose. Then, you intro=
duce a primitive that includes a C header, and you create a C++ "view" of t=
hat C TU. So you might suggest that a _Generic macro could be "viewed" as a=
n overload set. So I might say<div><br></div><div> using ctu =
=3D c11_include("some_c11_header.<wbr>h");</div><div> int main=
() {</div><div> ctu::some_type t; // equivalent =
to some_type t; in C</div><div> ctu::__struct::n=
ame s; // equivalent to struct name s; in C</div><div> =
ctu::sqrt(1.0f); // Invokes generic macro</div><div> }<=
/div><div><br></div><div>You might say that a VLA could be "viewed" as a pa=
ir of pointers, or something similar. The implementation builds a bridge be=
tween the two systems, so the C code appears as a C++ interface, and then t=
he implementation is responsible for building trampolines and such things.<=
/div></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2061_12936621.1366152360893--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Wed, 17 Apr 2013 02:18:14 -0700 (PDT)
Raw View
------=_Part_2558_15624488.1366190294844
Content-Type: text/plain; charset=ISO-8859-1
No, because I have to be compatible with the existing TU system. I'd have
to only be compatible with modules. It is somewhat similar to modules, but
not identical. You are talking about the compiler bridging more than one TU
in a non-inclusive system, but it's fixed at compile-time, not included at
link-time, and the C module has to be available as source. It's more like
an implementation-defined SWIG.
--
---
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_2558_15624488.1366190294844
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
No, because I have to be compatible with the existing TU system. I'd have t=
o only be compatible with modules. It is somewhat similar to modules, but n=
ot identical. You are talking about the compiler bridging more than one TU =
in a non-inclusive system, but it's fixed at compile-time, not included at =
link-time, and the C module has to be available as source. It's more like a=
n implementation-defined SWIG.
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2558_15624488.1366190294844--
.