Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #152592 > unrolled thread
| Started by | Real Troll <real.troll@trolls.com> |
|---|---|
| First post | 2020-06-02 04:08 -1000 |
| Last post | 2020-06-06 00:07 -0400 |
| Articles | 20 on this page of 103 — 22 participants |
Back to article view | Back to comp.lang.c
Two different Results between C and C++ Real Troll <real.troll@trolls.com> - 2020-06-02 04:08 -1000
Re: Two different Results between C and C++ mark.bluemel@gmail.com - 2020-06-02 07:59 -0700
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-02 09:26 -0700
Re: Two different Results between C and C++ Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-06-02 12:41 -0400
Re: Two different Results between C and C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-06-02 18:09 +0100
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-02 11:51 -0700
Re: Two different Results between C and C++ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-06-02 20:44 +0100
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-02 12:59 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-02 16:06 -0400
Re: Two different Results between C and C++ mark.bluemel@gmail.com - 2020-06-03 00:27 -0700
Re: Two different Results between C and C++ John Bode <jfbode1029@gmail.com> - 2020-06-02 08:41 -0700
Re: Two different Results between C and C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-06-02 09:20 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-02 12:36 -0400
Re: Two different Results between C and C++ John Bode <jfbode1029@gmail.com> - 2020-06-02 11:39 -0700
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-02 12:06 -0700
Re: Two different Results between C and C++ Richard Damon <Richard@Damon-Family.org> - 2020-06-02 15:41 -0400
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-02 13:50 -0700
Re: Two different Results between C and C++ John Bode <jfbode1029@gmail.com> - 2020-06-04 13:16 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-04 16:41 -0400
Re: Two different Results between C and C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 16:54 +0200
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-04 16:04 -0700
Re: Two different Results between C and C++ raltbos@xs4all.nl (Richard Bos) - 2020-06-04 20:47 +0000
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-04 17:35 -0400
Re: Two different Results between C and C++ raltbos@xs4all.nl (Richard Bos) - 2020-06-04 22:01 +0000
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-04 20:11 -0400
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-04 16:10 -0700
Re: Two different Results between C and C++ Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-06-05 02:26 -0700
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-05 11:33 -0700
Re: Two different Results between C and C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-06-05 11:28 +0000
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-06-21 00:53 -0700
Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-06-21 03:57 -0700
Re: Two different Results between C and C++ Richard Damon <Richard@Damon-Family.org> - 2020-06-21 08:08 -0400
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-06-28 04:59 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-21 10:59 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-04 05:21 -0700
Re: Two different Results between C and C++ "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-09-05 13:02 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-10 06:36 -0700
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-10 12:03 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-12 21:55 -0700
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-21 11:40 -0700
Re: Two different Results between C and C++ Richard Damon <Richard@Damon-Family.org> - 2020-06-21 19:50 -0400
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-02 23:00 -0700
Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-03 09:57 -0700
Re: Two different Results between C and C++ David Brown <david.brown@hesbynett.no> - 2020-09-03 20:04 +0200
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-04 06:44 -0700
Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-05 06:51 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-08 07:34 -0700
Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-10 23:47 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-11 10:17 -0400
Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-11 08:32 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-11 12:03 -0400
Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-12 02:49 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-12 22:24 -0700
Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-13 06:25 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-15 05:01 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-15 10:59 -0700
Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-09-15 15:58 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-28 21:38 -0800
Re: Two different Results between C and C++ Öö Tiib <ootiib@hot.ee> - 2020-12-30 05:39 -0800
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-03 12:46 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-10 06:20 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-10 07:37 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-10 10:44 -0400
Re: Two different Results between C and C++ raltbos@xs4all.nl (Richard Bos) - 2020-06-29 16:20 +0000
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-29 11:18 -0700
Re: Two different Results between C and C++ raltbos@xs4all.nl (Richard Bos) - 2020-06-29 21:46 +0000
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-29 14:59 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-29 18:53 -0400
Re: Two different Results between C and C++ Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2020-06-30 01:40 +0200
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-29 17:48 -0700
Re: Two different Results between C and C++ David Brown <david.brown@hesbynett.no> - 2020-06-30 07:45 +0200
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-30 15:11 -0400
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-06-29 17:45 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-04 03:13 -0700
Re: Two different Results between C and C++ Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-04 18:44 +0000
Re: Two different Results between C and C++ David Brown <david.brown@hesbynett.no> - 2020-09-05 15:57 +0200
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-08 08:27 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-08 17:50 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-08 21:07 -0400
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-08 18:28 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-09-08 22:14 -0400
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-10 06:35 -0700
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-04 11:46 -0700
Re: Two different Results between C and C++ Kaz Kylheku <793-849-0957@kylheku.com> - 2020-09-04 19:07 +0000
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-10 04:15 -0700
Re: Two different Results between C and C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-09-10 12:46 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-06 16:49 -0800
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-02 15:51 -0400
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-06-21 01:25 -0700
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-21 10:34 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-04 06:38 -0700
Re: Two different Results between C and C++ "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2020-09-06 05:52 -0700
Re: Two different Results between C and C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-10 06:37 -0700
Re: Two different Results between C and C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 16:54 +0200
Re: Two different Results between C and C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-09-08 16:52 +0200
Re: Two different Results between C and C++ Juha Nieminen <nospam@thanks.invalid> - 2020-06-02 18:45 +0000
Re: Two different Results between C and C++ Bart <bc@freeuk.com> - 2020-06-02 19:55 +0100
Re: Two different Results between C and C++ Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-06-02 15:11 -0400
Re: Two different Results between C and C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-06-02 20:14 +0000
Re: Two different Results between C and C++ Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-06-02 16:19 -0400
Re: Two different Results between C and C++ Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-06-02 15:06 -0400
Re: Two different Results between C and C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-02 16:20 -0400
Re: Two different Results between C and C++ Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2020-06-06 00:07 -0400
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-06-04 16:04 -0700 |
| Message-ID | <87lfl2v3fd.fsf@nosuchdomain.example.com> |
| In reply to | #152659 |
John Bode <jfbode1029@gmail.com> writes:
> On Tuesday, June 2, 2020 at 2:06:54 PM UTC-5, Keith Thompson wrote:
>> John Bode <jfbode1029@gmail.com> writes:
>
> [snip]
>
>>
>> > So yeah, I'm going to continue to emphasize that they are different languages
>> > with different rules and behavior, regardless of how much they may have in
>> > common.
>>
>> Sure, they're different languages, but why ignore their
>> commonalities?
>
> I'm not *ignoring* their commonalities, I'm *emphasizing* their differences
> precisely because of questions like the one that started this thread. This
> is one of the places where C and C++ really do differ.
>
> Yes, in most cases C and C++ will do the same thing, but you should never be
> *surprised* when they don't (modulo undefined behavior). Hence why I say it's
> less ass-bitey to treat them as completely different languages, at least until
> you reach some minimum level of understanding of both.
If you had said that in the first place, I would have had no
objection.
But you said "C and C++ are completely different languages", which
is simply not true. Calling them "completely different language" *is*
ignoring their commonalities.
No doubt you knew what you meant, but I don't think that meaning was
correctly expressed by your words.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2020-06-04 20:47 +0000 |
| Message-ID | <5ed95cf6.762046@news.xs4all.nl> |
| In reply to | #152610 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > There are also an infinite number of programs that are legal C and legal > C++ with the same behavior. Sure. There are also an infinite number(!) of rationals that are a member of the reals. C and C++ are, by now, fundamentally different. The only similatiry, from a practical point of view, is the same as than between C++ and JavaS...(sorry, I've been in trouble over this before, in this very newsgroup no less: ECMA*barf*SCRIPT): curly braces instead of BEGIN...END. OP's expectations are understandable, but unwarranted. Anything further than that is just silly. Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-06-04 17:35 -0400 |
| Message-ID | <rbbpeu$a60$1@dont-email.me> |
| In reply to | #152665 |
On 6/4/20 4:47 PM, Richard Bos wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >> There are also an infinite number of programs that are legal C and legal >> C++ with the same behavior. > > Sure. There are also an infinite number(!) of rationals that are a > member of the reals. > > C and C++ are, by now, fundamentally different. The only similatiry, > from a practical point of view, is the same as than between C++ and > JavaS...(sorry, I've been in trouble over this before, in this very > newsgroup no less: ECMA*barf*SCRIPT): curly braces instead of > BEGIN...END. Virtually every C operator is also a C++ operator, with almost exactly the same meaning when applied to values of types that can be expressed in both languages. Virtually every type of C statement is also a C++ statement, with almost exactly the same meaning. Virtually every feature of C type declarations is also a feature of C++ type declarations, with the same (or almost the same) meaning in both languages. The C++ preprocessing phase works according to almost exactly the same rules as the C preprocessing phase. Virtually the entire C standard library has been incorporated, by reference, into the C++ standard library, with only minor modifications. That's a lot more that those two languages have in common than just the curly braces, and being familiar with those shared features of the two languages is of extreme practical importance for anyone working in either language (I'm not implying that you need to be aware of the fact that they are shared, only that you need to be aware of those features). Sure, there's a fair number of tricky differences between the two languages with regard to their shared features, and C++ certainly has a lot of features that are not shared with C, and you need to at least be aware of those features to be a good C++ programmer, but that doesn't make the features that are shared between the languages unimportant.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2020-06-04 22:01 +0000 |
| Message-ID | <5ed96eeb.5358875@news.xs4all.nl> |
| In reply to | #152666 |
James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > Sure, there's a fair number of tricky differences between the two > languages with regard to their shared features, and C++ certainly has a > lot of features that are not shared with C, and you need to at least be > aware of those features to be a good C++ programmer, but that doesn't > make the features that are shared between the languages unimportant. You know damned well that the feature in question is _not_ shared between C and C++. Richard
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-06-04 20:11 -0400 |
| Message-ID | <rbc2jm$tcq$1@dont-email.me> |
| In reply to | #152668 |
On 6/4/20 6:01 PM, Richard Bos wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > >> Sure, there's a fair number of tricky differences between the two >> languages with regard to their shared features, and C++ certainly has a >> lot of features that are not shared with C, and you need to at least be >> aware of those features to be a good C++ programmer, but that doesn't >> make the features that are shared between the languages unimportant. > > You know damned well that the feature in question is _not_ shared > between C and C++. Sure, and I've never said anything to suggest otherwise. My comments on this thread have only been in response to the incorrect assertion that "C and C++ are completely different languages". If you had instead identified this feature as one of the minor exceptions to the general rule that C code which can also be compiled as C++ code (which is an awful lot of C code) generally has the same behavior in both languages, I would have had no objections.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-06-04 16:10 -0700 |
| Message-ID | <87h7vqv345.fsf@nosuchdomain.example.com> |
| In reply to | #152665 |
raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> There are also an infinite number of programs that are legal C and legal
>> C++ with the same behavior.
>
> Sure. There are also an infinite number(!) of rationals that are a
> member of the reals.
Yes. I fail to see the relevance. In fact my point in saying that
(which you snipped) is that comparing infinite numbers of programs is
not meaningful.
> C and C++ are, by now, fundamentally different. The only similatiry,
> from a practical point of view, is the same as than between C++ and
> JavaS...(sorry, I've been in trouble over this before, in this very
> newsgroup no less: ECMA*barf*SCRIPT): curly braces instead of
> BEGIN...END.
That is simply untrue. There are far more similarities between C and
C++ than you admit. (Presumably you already know that.)
> OP's expectations are understandable, but unwarranted. Anything further
> than that is just silly.
It's not at all clear what the OP's expections were. They said
they had "just noticed" that sizeof('a') and sizeof(1+=1) yield
different results in C and C++. (Both differences are well known,
and rarely affect real programs; how often do you apply sizeof to a
constant expression? And in principle they can yield the same result
if sizeof(int)==1, but that's rare and not particularly relevant.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-06-05 02:26 -0700 |
| Message-ID | <02e52edb-b1b0-4226-962e-c6bfba0167cdo@googlegroups.com> |
| In reply to | #152671 |
On Friday, 5 June 2020 00:11:01 UTC+1, Keith Thompson wrote:
> raltbos@xs4all.nl (Richard Bos) writes:
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> >> There are also an infinite number of programs that are legal C and legal
> >> C++ with the same behavior.
> >
> > Sure. There are also an infinite number(!) of rationals that are a
> > member of the reals.
>
> Yes. I fail to see the relevance. In fact my point in saying that
> (which you snipped) is that comparing infinite numbers of programs is
> not meaningful.
>
> > C and C++ are, by now, fundamentally different. The only similatiry,
> > from a practical point of view, is the same as than between C++ and
> > JavaS...(sorry, I've been in trouble over this before, in this very
> > newsgroup no less: ECMA*barf*SCRIPT): curly braces instead of
> > BEGIN...END.
>
> That is simply untrue. There are far more similarities between C and
> C++ than you admit. (Presumably you already know that.)
>
> > OP's expectations are understandable, but unwarranted. Anything further
> > than that is just silly.
>
> It's not at all clear what the OP's expections were. They said
> they had "just noticed" that sizeof('a') and sizeof(1+=1) yield
> different results in C and C++. (Both differences are well known,
> and rarely affect real programs; how often do you apply sizeof to a
> constant expression? And in principle they can yield the same result
> if sizeof(int)==1, but that's rare and not particularly relevant.)
>
THe example was sizeof(1 != 1). sizeof(1 += 1) is illegal, but would
resolve to sizeof(int) if it were allowed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-06-05 11:33 -0700 |
| Message-ID | <874krpuzvf.fsf@nosuchdomain.example.com> |
| In reply to | #152673 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Friday, 5 June 2020 00:11:01 UTC+1, Keith Thompson wrote:
[...]
>> It's not at all clear what the OP's expections were. They said
>> they had "just noticed" that sizeof('a') and sizeof(1+=1) yield
>> different results in C and C++. (Both differences are well known,
>> and rarely affect real programs; how often do you apply sizeof to a
>> constant expression? And in principle they can yield the same result
>> if sizeof(int)==1, but that's rare and not particularly relevant.)
>>
> THe example was sizeof(1 != 1). sizeof(1 += 1) is illegal, but would
> resolve to sizeof(int) if it were allowed.
Yeah, that was just a typo on my part.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-06-05 11:28 +0000 |
| Message-ID | <slrnrdkb3o.kpi.grahn+nntp@frailea.sa.invalid> |
| In reply to | #152671 |
On Thu, 2020-06-04, Keith Thompson wrote: > raltbos@xs4all.nl (Richard Bos) writes: ... >> OP's expectations are understandable, but unwarranted. Anything further >> than that is just silly. > > It's not at all clear what the OP's expections were. I think the OP was just trolling. Masterfully executed as well: if you've followed comp.lang.c* for some years, you can be sure that such a seemingly innocent posting will generate at least a week of pointless rehashing of old arguments. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-06-21 00:53 -0700 |
| Message-ID | <86d05skg6z.fsf@linuxsc.com> |
| In reply to | #152610 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > John Bode <jfbode1029@gmail.com> writes: > >> On Tuesday, June 2, 2020 at 11:36:43 AM UTC-5, James Kuyper wrote: >> >>> On 6/2/20 11:41 AM, John Bode wrote: > > [...] > >>>> C and C++ are completely different languages, so this shouldn't >>>> be surprising. >>> >>> C and C++ are two different but very similar languages. The >>> overwhelming majority of the features of C are also features of >>> C++ (the reverse is not true - it doesn't even come close). >>> Therefore, it is entirely reasonable to be surprised by two of >>> the few exceptions to that rule. > > [...] > >> The two languages have diverged *enough* at this point that it's >> much less ass-bitey to approach them as being completely different. >> Maybe not *as* different as, say, C and Java, but we're all better >> served by viewing them that way. >> >> There are an infinite number of programs that are legal C but not >> legal C++. There are an infinite number of programs that are legal >> in both languages but exhibit different behavior. > > There are also an infinite number of programs that are legal C and > legal C++ with the same behavior. > > All these statements are true, but none are particularly relevant. > You can construct an infinite number of valid C or C++ programs by > playing games with the grammar. There are an infinite number of > legal C programs that use conditional operators nested 10,000 levels > deep, but I doubt that any such programs exist in the wild (except > *maybe* as compiler capacity tests). I think it's more useful to > look at actual code rather than contrived infinite sets of programs. > > There are *some* programs that are legal C but not legal C++. The > most common causes of this are probably C++'s tighter restrictions on > implicit conversions involving void*, C code that uses C++ keywords > as identifiers, and C features that haven't been incorporated into > C++, such as VLAs, _Generic, and compound literals. But almost all > programs that are legal C but not legal C++ can be made into legal > C++ with a small effort. This claim sounds like an article of faith, being offered without either proof or evidence. If meant as just an empirical statement then of course there is no way anyone can know that. If we consider the set of finite and well-formed C programs (meaning having no constraint violations or other compile-time errors), only a vanishingly small fraction of those are also well-formed C++ programs. This statement is mathematically precise in the sense that the limit of the density goes to zero. Furthermore, for any given amount of effort, the subset that can be converted to well-formed and equivalent C++ with that effort or less (including those that are already well-formed C++ and so take no effort) is a vanishingly small fraction of the total, again in the mathematically precise sense that the limit of the density goes to zero. So if we are going to make a statement about "almost all" C programs, almost all C programs take more than a small effort to be transformed into well-formed and equivalent C++, for any value of "small effort" one might choose. > There are *some* programs that are legal C and legal C++ with > different behavior. I don't think I've ever seen such a program > that wasn't contrived for the purpose of making that point. Probably you have but just didn't realize it. Do you think you can list all the ways that C programs can have a different meaning when compiled as C++, even considering only those C programs that are also well-formed C++? Try it, you might be surprised by the results. >> So yeah, I'm going to continue to emphasize that they are different >> languages with different rules and behavior, regardless of how much >> they may have in common. > > Sure, they're different languages, but why ignore their > commonalities? [...] Because in practice what the languages have in common is swamped by their differences when considered in the context of real-world programs.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-06-21 03:57 -0700 |
| Message-ID | <ce9a4ef4-8449-4212-a106-0db8b7d42994o@googlegroups.com> |
| In reply to | #152857 |
On Sunday, 21 June 2020 10:53:49 UTC+3, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > > > John Bode <jfbode1029@gmail.com> writes: > > > >> On Tuesday, June 2, 2020 at 11:36:43 AM UTC-5, James Kuyper wrote: > >> > >>> On 6/2/20 11:41 AM, John Bode wrote: > > > > [...] > > > >>>> C and C++ are completely different languages, so this shouldn't > >>>> be surprising. > >>> > >>> C and C++ are two different but very similar languages. The > >>> overwhelming majority of the features of C are also features of > >>> C++ (the reverse is not true - it doesn't even come close). > >>> Therefore, it is entirely reasonable to be surprised by two of > >>> the few exceptions to that rule. > > > > [...] > > > >> The two languages have diverged *enough* at this point that it's > >> much less ass-bitey to approach them as being completely different. > >> Maybe not *as* different as, say, C and Java, but we're all better > >> served by viewing them that way. > >> > >> There are an infinite number of programs that are legal C but not > >> legal C++. There are an infinite number of programs that are legal > >> in both languages but exhibit different behavior. > > > > There are also an infinite number of programs that are legal C and > > legal C++ with the same behavior. > > > > All these statements are true, but none are particularly relevant. > > You can construct an infinite number of valid C or C++ programs by > > playing games with the grammar. There are an infinite number of > > legal C programs that use conditional operators nested 10,000 levels > > deep, but I doubt that any such programs exist in the wild (except > > *maybe* as compiler capacity tests). I think it's more useful to > > look at actual code rather than contrived infinite sets of programs. > > > > There are *some* programs that are legal C but not legal C++. The > > most common causes of this are probably C++'s tighter restrictions on > > implicit conversions involving void*, C code that uses C++ keywords > > as identifiers, and C features that haven't been incorporated into > > C++, such as VLAs, _Generic, and compound literals. But almost all > > programs that are legal C but not legal C++ can be made into legal > > C++ with a small effort. > > This claim sounds like an article of faith, being offered without > either proof or evidence. If meant as just an empirical statement > then of course there is no way anyone can know that. > > If we consider the set of finite and well-formed C programs (meaning > having no constraint violations or other compile-time errors), only > a vanishingly small fraction of those are also well-formed C++ > programs. This statement is mathematically precise in the sense > that the limit of the density goes to zero. > > Furthermore, for any given amount of effort, the subset that can be > converted to well-formed and equivalent C++ with that effort or less > (including those that are already well-formed C++ and so take no > effort) is a vanishingly small fraction of the total, again in the > mathematically precise sense that the limit of the density goes to > zero. > > So if we are going to make a statement about "almost all" C > programs, almost all C programs take more than a small effort to be > transformed into well-formed and equivalent C++, for any value of > "small effort" one might choose. Perhaps it was not mathematical claim but from practice. Typical practical issue I have seen was that some C99 or C11 code did not compile on Microsoft C compiler. Getting it to work with it felt about same effort as getting it to work on Microsoft C++ compiler instead. > > > > There are *some* programs that are legal C and legal C++ with > > different behavior. I don't think I've ever seen such a program > > that wasn't contrived for the purpose of making that point. > > Probably you have but just didn't realize it. Do you think you can > list all the ways that C programs can have a different meaning when > compiled as C++, even considering only those C programs that are > also well-formed C++? Try it, you might be surprised by the > results. I can try to list from top of my head. * const variables implicitly static/extern * C++ typedefs structs, unions and enums implicitly C does not * inline functions different * size difference of character literals * size difference of results of logical operators * size difference of true and false * size difference of enums Possibly I missed surprising ones. What I remembered can be found with simple script. It very rarely matters and then it tends to look odd, made on purpose to matter and simple to fix.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-06-21 08:08 -0400 |
| Message-ID | <u5IHG.46745$PN2.6501@fx48.iad> |
| In reply to | #152857 |
On 6/21/20 3:53 AM, Tim Rentsch wrote: > If we consider the set of finite and well-formed C programs (meaning > having no constraint violations or other compile-time errors), only > a vanishingly small fraction of those are also well-formed C++ > programs. This statement is mathematically precise in the sense > that the limit of the density goes to zero. One thing to watch out with these arguments, the sets of well-formed C programs, and well-formed C programs that are also well-formed C++ programs are infinite, so comparisons on number are hard to do right. All Integral Numbers are Rational Numbers, the density of Integral numbers among the Rationals goes to zero, but there are one-to-one relationships that can be established between the Rationals and the Integers, so they are the same size.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-06-28 04:59 -0700 |
| Message-ID | <86d05jiep1.fsf@linuxsc.com> |
| In reply to | #152861 |
Richard Damon <Richard@Damon-Family.org> writes: > On 6/21/20 3:53 AM, Tim Rentsch wrote: > >> If we consider the set of finite and well-formed C programs (meaning >> having no constraint violations or other compile-time errors), only >> a vanishingly small fraction of those are also well-formed C++ >> programs. This statement is mathematically precise in the sense >> that the limit of the density goes to zero. > > One thing to watch out with these arguments, the sets of well-formed C > programs, and well-formed C programs that are also well-formed C++ > programs are infinite, so comparisons on number are hard to do right. > > All Integral Numbers are Rational Numbers, the density of Integral > numbers among the Rationals goes to zero, but there are one-to-one > relationships that can be established between the Rationals and the > Integers, so they are the same size. I am well versed in dealing with the mathematical properties of different kinds of infinities. Avoiding such difficulties is one reason I chose to consider the question from the perspective of the limit of the density, where all the quantities involved are always finite.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-06-21 10:59 -0700 |
| Message-ID | <38c7640f-c674-4952-9af5-ce68f66b245co@googlegroups.com> |
| In reply to | #152857 |
On Sunday, June 21, 2020 at 3:53:49 AM UTC-4, Tim Rentsch wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > > > John Bode <jfbode1029@gmail.com> writes: ... > >> There are an infinite number of programs that are legal C but not > >> legal C++. There are an infinite number of programs that are legal > >> in both languages but exhibit different behavior. > > > > There are also an infinite number of programs that are legal C and > > legal C++ with the same behavior. > > > > All these statements are true, but none are particularly relevant. > > You can construct an infinite number of valid C or C++ programs by > > playing games with the grammar. There are an infinite number of > > legal C programs that use conditional operators nested 10,000 levels > > deep, but I doubt that any such programs exist in the wild (except > > *maybe* as compiler capacity tests). I think it's more useful to > > look at actual code rather than contrived infinite sets of programs. > > > > There are *some* programs that are legal C but not legal C++. The > > most common causes of this are probably C++'s tighter restrictions on > > implicit conversions involving void*, C code that uses C++ keywords > > as identifiers, and C features that haven't been incorporated into > > C++, such as VLAs, _Generic, and compound literals. But almost all > > programs that are legal C but not legal C++ can be made into legal > > C++ with a small effort. > > This claim sounds like an article of faith, being offered without > either proof or evidence. If meant as just an empirical statement > then of course there is no way anyone can know that. It neither an article of faith, nor an empirical statement. It's a conclusion easily reached by anyone who knows both languages well enough to be aware of what needs to be done to make the conversion. Knowing enough to reach that conclusion is made easier by the fact that Annex C of the C++ standard provides what's supposed to be a comprehensive list of the relevant issues. If you don't think that it is comprehensive, it would be helpful to identify what's missing, incomplete, or incorrect in Annex C. > So if we are going to make a statement about "almost all" C > programs, almost all C programs take more than a small effort to be > transformed into well-formed and equivalent C++, for any value of > "small effort" one might choose. Here's where we move from theory into empirical arguments. As a practical matter, I've done the relevant conversions many times, and it's trivial in most cases. Your belief that it's usually quite difficult is something that I find quite mystifying. What do you think are the most serious and commonplace obstacles for such conversions? > > There are *some* programs that are legal C and legal C++ with > > different behavior. I don't think I've ever seen such a program > > that wasn't contrived for the purpose of making that point. > > Probably you have but just didn't realize it. Do you think you can > list all the ways that C programs can have a different meaning when > compiled as C++, even considering only those C programs that are > also well-formed C++? Try it, you might be surprised by the > results. Annex C of the C++ standard contains such a list, and quick review of Annex C showed I have roughly 95% of the items already committed to memory. I couldn't list them from memory, but I'm fully aware of the fact each of the is a difference between the two languages. It does help that I once, just for fun spent a couple of years working on and off (mostly off) on a program intended to demonstrate those differences in a program that was as compact as possible.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-09-04 05:21 -0700 |
| Message-ID | <86o8ml7mxa.fsf@linuxsc.com> |
| In reply to | #152865 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On Sunday, June 21, 2020 at 3:53:49 AM UTC-4, Tim Rentsch wrote: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >>> John Bode <jfbode1029@gmail.com> writes: > > ... > >>>> There are an infinite number of programs that are legal C but not >>>> legal C++. There are an infinite number of programs that are legal >>>> in both languages but exhibit different behavior. >>> >>> There are also an infinite number of programs that are legal C and >>> legal C++ with the same behavior. >>> >>> All these statements are true, but none are particularly relevant. >>> You can construct an infinite number of valid C or C++ programs by >>> playing games with the grammar. There are an infinite number of >>> legal C programs that use conditional operators nested 10,000 levels >>> deep, but I doubt that any such programs exist in the wild (except >>> *maybe* as compiler capacity tests). I think it's more useful to >>> look at actual code rather than contrived infinite sets of programs. >>> >>> There are *some* programs that are legal C but not legal C++. The >>> most common causes of this are probably C++'s tighter restrictions on >>> implicit conversions involving void*, C code that uses C++ keywords >>> as identifiers, and C features that haven't been incorporated into >>> C++, such as VLAs, _Generic, and compound literals. But almost all >>> programs that are legal C but not legal C++ can be made into legal >>> C++ with a small effort. >> >> This claim sounds like an article of faith, being offered without >> either proof or evidence. If meant as just an empirical statement >> then of course there is no way anyone can know that. > > It neither an article of faith, You cannot know that, since you don't know what Keith is thinking. > nor an empirical statement. It's a conclusion easily reached by > anyone who knows both languages well enough to be aware of what > needs to be done to make the conversion. I still don't see any evidence being offered to support that assertion. > Knowing enough to reach > that conclusion is made easier by the fact that Annex C of the C++ > standard provides what's supposed to be a comprehensive list of the > relevant issues. If you think that list is even close to being complete then you really haven't been paying attention. > If you don't think that it is comprehensive, it > would be helpful to identify what's missing, incomplete, or > incorrect in Annex C. Have you even tried looking for other cases? Whether you have or not, it's not my problem. The world does not revolve around you. >> So if we are going to make a statement about "almost all" C >> programs, almost all C programs take more than a small effort to be >> transformed into well-formed and equivalent C++, for any value of >> "small effort" one might choose. > > Here's where we move from theory into empirical arguments. As a > practical matter, I've done the relevant conversions many times, and > it's trivial in most cases. Considering what you said above, whether you have done so even once is subject to doubt. If you don't know whether the end result has the same semantics in C++ as in C, then you don't know if the conversion has been accomplished. > Your belief that it's usually quite > difficult is something that I find quite mystifying. It's not a statement of belief, it's a deduction. The deduction is based on an understanding of the structure of language and an understanding of the necessary mathematics (which actually isn't all that much, but it is greater than zero). Did you make any effort at all to follow the sketch I gave of the reasoning underlying the deduction? If you did then was there something about it that you didn't understand? Or, if you didn't, then it isn't really surprising that you would be mystified by an explanation you chose to ignore.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-09-05 13:02 -0700 |
| Message-ID | <8ec0c910-614d-44bf-824c-c86f688f6899n@googlegroups.com> |
| In reply to | #154483 |
On Friday, September 4, 2020 at 8:21:23 AM UTC-4, Tim Rentsch wrote: > James Kuyper <james...@alumni.caltech.edu> writes: > > > On Sunday, June 21, 2020 at 3:53:49 AM UTC-4, Tim Rentsch wrote: > > > >> Keith Thompson <Keith.S.T...@gmail.com> writes: ... > >>> You can construct an infinite number of valid C or C++ programs by > >>> playing games with the grammar. There are an infinite number of > >>> legal C programs that use conditional operators nested 10,000 levels > >>> deep, but I doubt that any such programs exist in the wild (except > >>> *maybe* as compiler capacity tests). I think it's more useful to > >>> look at actual code rather than contrived infinite sets of programs. > >>> > >>> There are *some* programs that are legal C but not legal C++. The > >>> most common causes of this are probably C++'s tighter restrictions on > >>> implicit conversions involving void*, C code that uses C++ keywords > >>> as identifiers, and C features that haven't been incorporated into > >>> C++, such as VLAs, _Generic, and compound literals. But almost all > >>> programs that are legal C but not legal C++ can be made into legal > >>> C++ with a small effort. > >> > >> This claim sounds like an article of faith, being offered without > >> either proof or evidence. If meant as just an empirical statement > >> then of course there is no way anyone can know that. > > > > It neither an article of faith, > You cannot know that, since you don't know what Keith is > thinking. In principle, you're correct - it's impossible to have justified certainty about the truth of any statement about reality, statements about what someone else is thinking are just a special case of that general principle. The best you can do is have enough evidence to justify a level of certainty that is less than absolute, but high enough to be actionable - which I do have. I am a fluent native speaker of English, and in particular of the specialized form of that language that includes the jargon appropriate for describing the C standard. Keith has clearly expressed himself in that language, and I had no trouble understanding what he was saying. This is, in part, because I have a lot of familiarity with how he thinks as a result of several decades spent monitoring newsgroups in which he has also participated. He's one of the people I've met on usenet that I'm most frequently in agreement with. I would not have used precisely the same wording he did, but I could easily have expressed essentially the same idea in slightly different words, and I know precisely what I would have meant if I had written something like that, so I was quite confident that he meant essentially the same thing. Most importantly, it's been 11 weeks since I wrote that message, and I know Keith well enough to be quite certain that he would have responded promptly, politely, and with adequate explanation if I had said something significantly inconsistent with what he actually meant. The fact that he has failed to do so has increased my confidence in my guess as to what he was thinking. > > nor an empirical statement. It's a conclusion easily reached by > > anyone who knows both languages well enough to be aware of what > > needs to be done to make the conversion. > I still don't see any evidence being offered to support that > assertion. > > Knowing enough to reach > > that conclusion is made easier by the fact that Annex C of the C++ > > standard provides what's supposed to be a comprehensive list of the > > relevant issues. > If you think that list is even close to being complete then you > really haven't been paying attention. I wouldn't be the least bit surprised to find that this section was incomplete - it's a large and frequently updated standard, what would be more surprising would be a complete absence of errors in a section that large. That is why I offered you the opportunity to identify ways in which it is incomplete. I would be surprised if those ways were sufficiently numerous and sufficiently significant to justify your pretense that they're completely different languages. However, the universe frequently surprises me, so I'm open to enlightenment on this issue. Please surprise me by providing the support for that that claim (your willingness to provide that support would surprise me more than it's contents). > > If you don't think that it is comprehensive, it > > would be helpful to identify what's missing, incomplete, or > > incorrect in Annex C. > Have you even tried looking for other cases? Whether you have or > not, it's not my problem. The world does not revolve around you. I've looked, and didn't notice anything - but as I've ruefully admitted many times before, my judgement is far more reliable when I say "I've identified a problem" than it is when I say "I didn't notice any problems". That's why I'm quite interested in seeing any examples you might be willing to provide of things that the Committee forgot to include and that I missed. > >> So if we are going to make a statement about "almost all" C > >> programs, almost all C programs take more than a small effort to be > >> transformed into well-formed and equivalent C++, for any value of > >> "small effort" one might choose. > > > > Here's where we move from theory into empirical arguments. As a > > practical matter, I've done the relevant conversions many times, and > > it's trivial in most cases. > Considering what you said above, whether you have done so even > once is subject to doubt. If you don't know whether the end > result has the same semantics in C++ as in C, then you don't > know if the conversion has been accomplished. I can't know any such thing with certainty, as referenced above. But I do have a fair amount of confidence in the conversions I've performed. > > Your belief that it's usually quite > > difficult is something that I find quite mystifying. > It's not a statement of belief, it's a deduction. The deduction > is based on an understanding of the structure of language and > an understanding of the necessary mathematics (which actually > isn't all that much, but it is greater than zero). Did you make > any effort at all to follow the sketch I gave of the reasoning > underlying the deduction? The sketch you provided was merely a sequence of unsupported assertions that did not depend in any way upon the actual nature of the differences between C and C++. It could have been asserted, with equal (in)validity, about the differences between C2011 and C2017, which were extremely minor. In my experience, the biggest problem with converting a strictly conforming C program into a program that is both strictly conforming C and well-formed C++, with the same required observable behavior in either language that the original program had in C, is the absence of casts on the value returned by malloc(), which is a quite minor issue. If you can identify even a single issue that is significantly more troublesome than that one, your objections would seem significantly better motivated than they currently seem. It would still take a large number of such differences, each of them much more problematic than casting malloc(), to justify claiming that they're really two distinct languages, but a single example would at least be a start on making that case.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-09-10 06:36 -0700 |
| Message-ID | <868sdh69er.fsf@linuxsc.com> |
| In reply to | #154579 |
Please post a followup response through other than google groups. Thank you.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-09-10 12:03 -0700 |
| Message-ID | <87sgbpihe9.fsf@nosuchdomain.example.com> |
| In reply to | #154802 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Please post a followup response through other than google groups.
> Thank you.
I don't post through Google Groups. If I did, I would probably
ignore your rather odd request unless you offered a good reason
for it.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-09-12 21:55 -0700 |
| Message-ID | <86y2le2s38.fsf@linuxsc.com> |
| In reply to | #154824 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> Please post a followup response through other than google groups. > > I don't post through Google Groups. If I did, I would probably > ignore your rather odd request unless you offered a good reason > for it. If you did post through Google Groups, I probably wouldn't make such a request, whether you offered a reason for it or not.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-06-21 11:40 -0700 |
| Message-ID | <87tuz4gt4c.fsf@nosuchdomain.example.com> |
| In reply to | #152857 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> All these statements are true, but none are particularly relevant.
>> You can construct an infinite number of valid C or C++ programs by
>> playing games with the grammar. There are an infinite number of
>> legal C programs that use conditional operators nested 10,000 levels
>> deep, but I doubt that any such programs exist in the wild (except
>> *maybe* as compiler capacity tests). I think it's more useful to
>> look at actual code rather than contrived infinite sets of programs.
>>
>> There are *some* programs that are legal C but not legal C++. The
>> most common causes of this are probably C++'s tighter restrictions on
>> implicit conversions involving void*, C code that uses C++ keywords
>> as identifiers, and C features that haven't been incorporated into
>> C++, such as VLAs, _Generic, and compound literals. But almost all
>> programs that are legal C but not legal C++ can be made into legal
>> C++ with a small effort.
>
> This claim sounds like an article of faith, being offered without
> either proof or evidence. If meant as just an empirical statement
> then of course there is no way anyone can know that.
When I wrote "almost all programs that are legal C but not legal
C++", I was referring to real-world programs, not the infinite set
of all possible programs. I probably could have made that clearer.
My statement was not an "article of faith". It was somewhat
speculative. I think it was correct, but it's not worth the effort
to perform a major research project to verify it.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web