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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-09-08 22:14 -0400 |
| Message-ID | <rj9e2g$jk9$1@dont-email.me> |
| In reply to | #154749 |
On 9/8/20 9:28 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On Tuesday, September 8, 2020 at 11:27:37 AM UTC-4, Tim Rentsch wrote: >> ... >>> use Keith Thompson's phrase, and there is a tacit assumption >>> that the programs are well-formed (meaning no syntax errors or >>> constraint violations). >> >> I should have commented on this before. You have frequently applied the >> term "well-formed" to C code, but as far as I can tell, Keith has never >> used the phrase "well-formed" at all in this discussion. > > James, the way you snipped Tim's text could imply that he said I had > used the phrase "well-formed". > > Restoring some context, Tim wrote: > > I'm not sure you understand the question being discussed. The > set of programs under discussion is real-world C programs, to > use Keith Thompson's phrase, and there is a tacit assumption > that the programs are well-formed (meaning no syntax errors or > constraint violations). > > The phrase of mine that Tim was referring to was "real-world C > programs", not "well-formed". I just wanted to be clear on that > (trivial) point. You're right - I snipped the text in a way that reflected my misunderstood about which phrase he was referring to. I see now that he did not actually misattribute "well-formed" to you. My main point was that it's a bad idea, when comparing C and C++, to use a term that is defined by one of the relevant standards with a meaning substantially different from the one he's using, and is not used in the other standard at all. I should have pointed that out a lot earlier in this thread, though I doubt it would have made much difference.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-09-10 06:35 -0700 |
| Message-ID | <86d02t69g4.fsf@linuxsc.com> |
| In reply to | #154746 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On Tuesday, September 8, 2020 at 11:27:37 AM UTC-4, Tim Rentsch wrote: > ... > >> use Keith Thompson's phrase, and there is a tacit assumption >> that the programs are well-formed (meaning no syntax errors or >> constraint violations). > > I should have commented on this before. You have frequently > applied the term "well-formed" to C code, but as far as I can > tell, Keith has never used the phrase "well-formed" at all in this > discussion. > > I have used "well-formed", but only to describe C++ code. There's > a good reason for that. The C++ standard defines the term > "well-formed": "C++ program constructed according to the syntax > rules, diagnosable semantic rules, and the one-definition rule > (6.2)." (C++ 3.29). C++ doesn't use formal "Constraints" > sections the same way that C does, and code which obeys all of > C++'s "diagnosable semantic rules" is (debatably) considerably > more restricted than code which violates none of C's constraints. > > The concept of "Well-formed" code is not used in the C standard; > the closest equivalent is "strictly conforming" (which, in a neat > bit of symmetry, is not used in the C++ standard). "strictly > conforming" is considerably more restricted than "well-formed" > (whether referring to your definition or the C++ standard's > definition), since it doesn't allow for unspecified behavior. > > I wonder if this has had something to do with our point of > disagreement. The arguments I've made depend heavily upon the > fact that strictly conforming code cannot produce output that > depends upon unspecified behavior. Let me offer some advice. If you want to carry on a useful conversation with someone, it is important first to understand what they think they mean by what they say. It doesn't help to explain what you think their words should mean, and usually just the opposite, because that will slow down the process of understanding what it is they actually do mean. So the question now is what do you think I meant, which is to say what I thought I meant, by my various comments in responses to Keith's postings? Hint: my use of "well-formed" had nothing to do with how the C++ standard may define that term. If on the other hand you don't want to carry on a useful conversation then the above advice may not apply.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-09-04 11:46 -0700 |
| Message-ID | <87a6y5z8ge.fsf@nosuchdomain.example.com> |
| In reply to | #154480 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> 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.
>
> So you meant to consider only those C programs that have actually
> been written, rather than making a statement that would apply to
> any well-formed C program? So the statement was meant in the
> sense of "almost all existing programs" that are well-formed C?
>
>> My statement was not an "article of faith". It was somewhat
>> speculative.
>
> I am not offering any judgment on whether your statement actually
> is an article of faith for you; nor would I, since I cannot know
> what you are thinking. However, since you did not offer, and still
> have not offered, any sort of evidence or reasoning that supports
> the assertion, it does come across that way. You saying that the
> statement was somewhat speculative, without saying anything more
> specific, doesn't lessen that impression.
>
> Incidentally, I don't know why you put the phrase article of faith
> in scare quotes. It's an established phrase in regular English,
> dating back at least 500 years. A typical definition is "a
> deeply held belief".
Those were not scare quotes. You introduced the phrase "article of
faith" into this discussion. I was directly quoting you.
>> I think it was correct, but it's not worth the effort to
>> perform a major research project to verify it.
>
> Let's think about what you're saying. How many C programs have
> actually been written? A hundred thousand? A million? Of those,
> how many have you actually looked at? Probably a few hundred, but
> let's guess a thousand. Of the C programs you've seen, how many
> have you actually tried to convert to C++? Five? Ten? Twenty?
> Assuming the number is 20 and that 200,000 C programs have been
> written, that is 0.01%. Furthermore getting a C program to the
> point where it will compile as C++ is not the same as it being the
> same program. Even if we know the semantics of the C program was
> not changed by modifying it, there remains the question of whether
> the program has the same semantics in C++. Do you think you know
> all the ways that well-formed C code can have different semantics
> when compiled as C++? If you don't, then we shouldn't have much
> confidence in your estimate of the effort required to accomplish
> the modification, since we don't know whether the goal was actually
> reached. Is this what you mean when you say your claim is somewhat
> speculative? If it is then the word "somewhat" seems vastly
> understated.
Not every idle statement requires a research program to verify it.
Given my experience with C and C++, my *general impression* is that
most C programs can be made into valid C++ programs with the same
semantics without great effort by someone knowledgeable in both
languages. I speculate that the level of effort would be similar
to that for porting a program from one version of C to a later one,
or from one version of C++ to a later one.
I don't know off the top of my head all the ways that valid C
code can be valid C++ code with different semantics, but I believe
there's an annex in the C++ standard that provides that information.
I didn't expect that statement to be controversial, and I *DO NOT
CARE* enough about this to spend the time it would take to establish
it more firmly.
I note that you haven't said you disagree with my statement; rather
you seem to be criticizing the way I said it. I can't even tell
whether you agree or not. If you disagreed, I would ask you to
offer evidence.
--
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 | Kaz Kylheku <793-849-0957@kylheku.com> |
|---|---|
| Date | 2020-09-04 19:07 +0000 |
| Message-ID | <20200904120612.832@kylheku.com> |
| In reply to | #154515 |
On 2020-09-04, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Not every idle statement requires a research program to verify it. However, every incorrect statement about ISO C in comp.lang.c requires a holy war. "The product of two ints is of type long: the standard says so!" (*Siren sounds*. Everyone into the bomb shelter!) -- TXR Programming Lanuage: http://nongnu.org/txr Music DIY Mailing List: http://www.kylheku.com/diy ADA MP-1 Mailing List: http://www.kylheku.com/mp1
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-09-10 04:15 -0700 |
| Message-ID | <86lfhh6fye.fsf@linuxsc.com> |
| In reply to | #154515 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[edited to remove some extraneous or repeated material]
>>>>> [A]lmost 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.
>>
>> So you meant to consider only those C programs that have actually
>> been written, rather than making a statement that would apply to
>> any well-formed C program? So the statement was meant in the
>> sense of "almost all existing programs" that are well-formed C?
>>
>>> My statement was not an "article of faith". It was somewhat
>>> speculative.
[...]
>> Incidentally, I don't know why you put the phrase article of
>> faith in scare quotes. It's an established phrase in regular
>> English, dating back at least 500 years. A typical definition
>> is "a deeply held belief".
>
> Those were not scare quotes. You introduced the phrase "article
> of faith" into this discussion. I was directly quoting you.
The phrase is used with its ordinary English meaning, so there is
no particular reason to quote it. The quotes therefore come
across as scare quotes whether they were meant that way or not.
>>> I think it was correct, but it's not worth the effort to
>>> perform a major research project to verify it.
>>
>> Let's think about what you're saying. How many C programs have
>> actually been written? A hundred thousand? A million? Of those,
>> how many have you actually looked at? Probably a few hundred, but
>> let's guess a thousand. Of the C programs you've seen, how many
>> have you actually tried to convert to C++? Five? Ten? Twenty?
>> Assuming the number is 20 and that 200,000 C programs have been
>> written, that is 0.01%. Furthermore getting a C program to the
>> point where it will compile as C++ is not the same as it being the
>> same program. Even if we know the semantics of the C program was
>> not changed by modifying it, there remains the question of whether
>> the program has the same semantics in C++. Do you think you know
>> all the ways that well-formed C code can have different semantics
>> when compiled as C++? If you don't, then we shouldn't have much
>> confidence in your estimate of the effort required to accomplish
>> the modification, since we don't know whether the goal was actually
>> reached. Is this what you mean when you say your claim is somewhat
>> speculative? If it is then the word "somewhat" seems vastly
>> understated.
>
> Not every idle statement requires a research program to verify it.
>
> Given my experience with C and C++, my *general impression* is
> that most C programs can be made into valid C++ programs with the
> same semantics without great effort by someone knowledgeable in
> both languages. I speculate that the level of effort would be
> similar to that for porting a program from one version of C to a
> later one, or from one version of C++ to a later one.
>
> I don't know off the top of my head all the ways that valid C
> code can be valid C++ code with different semantics, but I
> believe there's an annex in the C++ standard that provides that
> information.
>
> I didn't expect that statement to be controversial, and I *DO
> NOT CARE* enough about this to spend the time it would take to
> establish it more firmly.
>
> I note that you haven't said you disagree with my statement;
> rather you seem to be criticizing the way I said it. I can't
> even tell whether you agree or not. If you disagreed, I would
> ask you to offer evidence.
I'm not asking you to conduct a research program or verify
anything. I'm just trying to determine the basis for your
statement.
At this point my summary might be something like this: based on
your experience you think most C programs should be convertible
to C++ without too much effort, but you aren't offering any
reasons why anyone else should think so. Is that a fair
(partial) summary of your comments?
Note on C.1 (in n4659). Annex C.1 paragraph 1 says
This subclause lists the differences between C++ and ISO C,
by the chapters of this document.
Despite that statement, the list is incomplete. For starters it
is based on C90, and has AFAICT not been updated for C99 or C11.
There are other problems but I don't know (and haven't made any
particular effort to discover) what they all are.
As to my own reaction, before I agree or disagree I think it is
important to understand, first, exactly what it is you are
asserting or positing, and second, what leads you to think so.
(One reason for the second part is understanding the second
part may inform some aspects of the first part.) My sense of
what you are saying has changed at least twice during the
conversation, so I would like to wait until that converges
before giving any further reaction to it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-09-10 12:46 -0700 |
| Message-ID | <87o8mdifdp.fsf@nosuchdomain.example.com> |
| In reply to | #154794 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> Not every idle statement requires a research program to verify it.
>>
>> Given my experience with C and C++, my *general impression* is
>> that most C programs can be made into valid C++ programs with the
>> same semantics without great effort by someone knowledgeable in
>> both languages. I speculate that the level of effort would be
>> similar to that for porting a program from one version of C to a
>> later one, or from one version of C++ to a later one.
>>
>> I don't know off the top of my head all the ways that valid C
>> code can be valid C++ code with different semantics, but I
>> believe there's an annex in the C++ standard that provides that
>> information.
>>
>> I didn't expect that statement to be controversial, and I *DO
>> NOT CARE* enough about this to spend the time it would take to
>> establish it more firmly.
>>
>> I note that you haven't said you disagree with my statement;
>> rather you seem to be criticizing the way I said it. I can't
>> even tell whether you agree or not. If you disagreed, I would
>> ask you to offer evidence.
>
> I'm not asking you to conduct a research program or verify
> anything. I'm just trying to determine the basis for your
> statement.
The basis for my statement was that it seems obviously true given
what I know of the relationship between the two languages. The fact
that nobody here has offered a refutation reinforces that opinion.
> At this point my summary might be something like this: based on
> your experience you think most C programs should be convertible
> to C++ without too much effort, but you aren't offering any
> reasons why anyone else should think so. Is that a fair
> (partial) summary of your comments?
I suppose so. If someone offered an actual counterargument,
or even a contrary opionion, I might be motivated to support my
statement further.
> Note on C.1 (in n4659). Annex C.1 paragraph 1 says
>
> This subclause lists the differences between C++ and ISO C,
> by the chapters of this document.
>
> Despite that statement, the list is incomplete. For starters it
> is based on C90, and has AFAICT not been updated for C99 or C11.
> There are other problems but I don't know (and haven't made any
> particular effort to discover) what they all are.
You've had ample opportunities to demonstrate that it's incomplete
by showing a difference that isn't listed.
As for whether it's been updated for C99 or C11, you seem to
be correct. C.1.3 [diff.expr] paragraph 2 is "Change: Implicit
declaration of functions is not allowed", which is inapplicable
starting with C99, and paragraph 5 is "Change: Banning implicit int".
I'm mildly surprised that this hasn't been updated, even in the
latest draft I have.
A C program that uses _Generic or compound literals would be slightly
more difficult to convert to valid C++.
> As to my own reaction, before I agree or disagree I think it is
> important to understand, first, exactly what it is you are
> asserting or positing, and second, what leads you to think so.
> (One reason for the second part is understanding the second
> part may inform some aspects of the first part.) My sense of
> what you are saying has changed at least twice during the
> conversation, so I would like to wait until that converges
> before giving any further reaction to it.
It seems that it would take a great deal of effort on my part for you
to be comfortable expressing an opinion on the original statement.
I have no plans to expend that effort. I've probably spent too much
time on this already.
--
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-12-06 16:49 -0800 |
| Message-ID | <868saajv90.fsf@linuxsc.com> |
| In reply to | #154830 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > [...] I have been wanting to post a followup to this, but unfortunately it got buried rather deep in my stack, and it didn't ever manage to make it into to the active queue. Sorry for not following up sooner.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-06-02 15:51 -0400 |
| Message-ID | <rb6ajh$33k$1@dont-email.me> |
| In reply to | #152604 |
On 6/2/20 2:39 PM, John Bode wrote: > 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. >> >> Annex C of the C++ standard details the differences between the two >> languages, excluding the differences that take the form of adding >> completely new features to C++. It only takes 24 of the 1600+ pages of >> the C++ standard, which is an indication of how few those differences >> really are. Keep in mind that much of the C standard (mostly the part >> describing the C standard library) is incorporated into the C++ standard >> by reference. If those cross-references were replaced by the text they >> cross-reference, it would add nearly 300 pages to the document, so it >> should more accurately be described as 24 pages out of roughly 1900. >> >> C++ was originally intended to be a set of features that would be added >> to C, rather than a brand new language, and the initial design of C++ >> reflected that fact. Even after Stroustrup realized that it would have >> to become a distinct language, backwards compatibility with C remained >> one of his key design goals. When they started standardizing C++, the >> C++ committee worked out an agreement with the C committee to prohibit >> the invention of gratuitous new differences between the languages. >> Differences are allowed, and have been created, but only if, in the >> opinion of the two committees, those differences are adequately motivated. > > 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. The two languages continue to diverge as > time goes on. That's true, modulo providing a definition of "legal" (neither standard uses that term). In order to make this more meaningful, I'm going to talk about compatible implementations of C and C++, a term that I need to define. An implementation of C and an implementation of C++ are compatible if, for any given construct, if the meaning or behavior permitted by the C standard for that construct has any overlap with the meaning or behavior permitted by the C++ standard for that same construct, both implementations will give that construct the same meaning or behavior. The fact that both sets are infinite obscures an important point. Rather than looking at infinite sets, lets look at finite ones. Consider sequences of no more than N characters from the basic source character set. A sub-set C(N) of those sequences qualify as having no syntax errors, constraint violations or undefined behavior according to the C standard. This sub-set can be further sub-divided into equivalence classes, every member of which has the same observable behavior under a given implementation of C for all possible inputs. A subset CPP(N) of all sequences of length N or less qualifies as well-formed code having no syntax errors or undefined behavior according to the C++ standard. Note that, in both subsets, I'm including programs with unspecified behavior. I believe that, for the overwhelming majority of the equivalence classes of C(N), there's at least one member of that class that is also in CPP(N), and which has the same observable behavior if compiled using a compatible implementation of C++. Those members might qualify as poorly-written in either language, but they don't have any problems as far as the C standard is concerned. That assertion is incompatible with the claim that they're completely different languages. ... > 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. That's fine, so long as you don't go around denying that they have a lot in common. "completely different" denies the existence of that common ground.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-06-21 01:25 -0700 |
| Message-ID | <868sggkepa.fsf@linuxsc.com> |
| In reply to | #152614 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On 6/2/20 2:39 PM, John Bode wrote: > >> 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. >>> >>> Annex C of the C++ standard details the differences between the >>> two languages, excluding the differences that take the form of >>> adding completely new features to C++. It only takes 24 of the >>> 1600+ pages of the C++ standard, which is an indication of how few >>> those differences really are. Keep in mind that much of the C >>> standard (mostly the part describing the C standard library) is >>> incorporated into the C++ standard by reference. If those >>> cross-references were replaced by the text they cross-reference, >>> it would add nearly 300 pages to the document, so it should more >>> accurately be described as 24 pages out of roughly 1900. >>> >>> C++ was originally intended to be a set of features that would be >>> added to C, rather than a brand new language, and the initial >>> design of C++ reflected that fact. Even after Stroustrup realized >>> that it would have to become a distinct language, backwards >>> compatibility with C remained one of his key design goals. When >>> they started standardizing C++, the C++ committee worked out an >>> agreement with the C committee to prohibit the invention of >>> gratuitous new differences between the languages. Differences are >>> allowed, and have been created, but only if, in the opinion of the >>> two committees, those differences are adequately motivated. >> >> 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. The two >> languages continue to diverge as time goes on. > > That's true, modulo providing a definition of "legal" (neither > standard uses that term). > > In order to make this more meaningful, I'm going to talk about > compatible implementations of C and C++, a term that I need to > define. An implementation of C and an implementation of C++ are > compatible if, for any given construct, if the meaning or behavior > permitted by the C standard for that construct has any overlap > with the meaning or behavior permitted by the C++ standard for > that same construct, both implementations will give that construct > the same meaning or behavior. > > The fact that both sets are infinite obscures an important point. > Rather than looking at infinite sets, lets look at finite ones. > Consider sequences of no more than N characters from the basic > source character set. > > A sub-set C(N) of those sequences qualify as having no syntax > errors, constraint violations or undefined behavior according to > the C standard. This sub-set can be further sub-divided into > equivalence classes, every member of which has the same observable > behavior under a given implementation of C for all possible > inputs. > > A subset CPP(N) of all sequences of length N or less qualifies as > well-formed code having no syntax errors or undefined behavior > according to the C++ standard. > > Note that, in both subsets, I'm including programs with unspecified > behavior. > > I believe that, for the overwhelming majority of the equivalence > classes of C(N), there's at least one member of that class that is > also in CPP(N), and which has the same observable behavior if > compiled using a compatible implementation of C++. Those members > might qualify as poorly-written in either language, but they don't > have any problems as far as the C standard is concerned. There are several problems with this argument. One, there is no evidence at all offered to say the statement of belief is true. Two, looking at any given C program, there is no way to know with certainty that a corresponding equivalent C-and-C++ program exists (in the sense of also satisfying the C(N) and CPP(N) conditions). Three, when looking at a particular C program and a proposed candidate C-and-C++ program, there is no way to know with certainty that the two programs are equivalent, because testing for equivalence is undecidable. So the hypothesis is probably impossible to verify. Four, the test suggested bears no obvious relationship to any of the usual ways that programs are evaluated. More briefly, the test looks artificial. Because of that it seems to have little conceptual value. Five, the test doesn't tell us very much because the criterion is so weak. Turing equivalence is a very coarse filter. For example, many Fortran programs can be transformed into an equivalent Fortran program, of the same length, that is also a well-formed and equivalent C program. That doesn't mean C and Fortran should be considered to be closely related languages.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-06-21 10:34 -0700 |
| Message-ID | <502cecf4-e3eb-4b2d-a1bc-ee8c9965af65o@googlegroups.com> |
| In reply to | #152859 |
On Sunday, June 21, 2020 at 4:26:05 AM UTC-4, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > > On 6/2/20 2:39 PM, John Bode wrote: ... > >> 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. The two > >> languages continue to diverge as time goes on. > > > > That's true, modulo providing a definition of "legal" (neither > > standard uses that term). > > > > In order to make this more meaningful, I'm going to talk about > > compatible implementations of C and C++, a term that I need to > > define. An implementation of C and an implementation of C++ are > > compatible if, for any given construct, if the meaning or behavior > > permitted by the C standard for that construct has any overlap > > with the meaning or behavior permitted by the C++ standard for > > that same construct, both implementations will give that construct > > the same meaning or behavior. > > > > The fact that both sets are infinite obscures an important point. > > Rather than looking at infinite sets, lets look at finite ones. > > Consider sequences of no more than N characters from the basic > > source character set. > > > > A sub-set C(N) of those sequences qualify as having no syntax > > errors, constraint violations or undefined behavior according to > > the C standard. This sub-set can be further sub-divided into > > equivalence classes, every member of which has the same observable > > behavior under a given implementation of C for all possible > > inputs. > > > > A subset CPP(N) of all sequences of length N or less qualifies as > > well-formed code having no syntax errors or undefined behavior > > according to the C++ standard. > > > > Note that, in both subsets, I'm including programs with unspecified > > behavior. > > > > I believe that, for the overwhelming majority of the equivalence > > classes of C(N), there's at least one member of that class that is > > also in CPP(N), and which has the same observable behavior if > > compiled using a compatible implementation of C++. Those members > > might qualify as poorly-written in either language, but they don't > > have any problems as far as the C standard is concerned. > > There are several problems with this argument. > > One, there is no evidence at all offered to say the statement of > belief is true. Evidence isn't really relevant. My statement was about abstractions, not the real world. What's needed for such a statement is arguments and citations of relevant text from the relevant standards. I didn't really think it was necessary to provide more or better arguments than I did. I would expect that any person capable of fully understanding Annex C of the C++ standard would be able to fill in the details themselves and see the truth of my claims as obvious. Apparently that's not true for you. If you wish to continue discussing this, it would help if you could identify what you consider least obvious about my argument. > Two, looking at any given C program, there is no way to know with > certainty that a corresponding equivalent C-and-C++ program > exists (in the sense of also satisfying the C(N) and CPP(N) > conditions). I didn't claim it was a certainty, and my argument did not depend upon it being a certainty, which is good, because it's not. However, that's only because of the N. The overwhelming majority of equivalence classes in C(N) have many members that are much smaller than N: remove all unnecessary white space, and systematically rename identifiers to be as small as possible, with the most frequently used identifiers given the shortest names, and you will generally make the program much smaller without changing it's required observable behavior. However, a small fraction of all equivalence classes in C(N) don't have any members that are significantly smaller than N. Some of the transformations that convert an arbitrary C program into one with the same required observable behavior in both C and in a compatible C++ compiler might make the program somewhat larger. As a result, the smallest such program might have a size greater than N. But this will be true in only a small fraction of the equivalence classes. Since such equivalence classes will tend to have a disproportionately small number of members, it affects an even smaller fraction of the actual programs. > Three, when looking at a particular C program and a proposed > candidate C-and-C++ program, there is no way to know with > certainty that the two programs are equivalent, because testing > for equivalence is undecidable. So the hypothesis is probably > impossible to verify. You're looking at it wrong. It might be difficult, even impossible, to confirm that two arbitrary programs have the same required observable behavior. However, my argument doesn't require that determination to be made for arbitrary programs. It's trivial to come up with transformations that take one program and convert it into another program with the same required observable behavior, and that's all I need to support my claim. It can also be impossible to determine whether any given program has defined behavior - but I don't need to determine that to support my claim, either. It's sufficient for what I'm saying that if I take a program that has defined behavior, there are transformations that can convert it into another program that has the same defined behavior. The key point is that there's only a relatively small set of issues that need to be addressed: Annex C of the C++ standard is only 24 pages long. For each item in Annex C, there's generally a relatively straightforward transformation to the code that will address the item. If you feel otherwise about any particular issue, you should identify it. > Four, the test suggested bears no obvious relationship to any of > the usual ways that programs are evaluated. More briefly, the > test looks artificial. Because of that it seems to have little > conceptual value. There's something that comes up frequently when I discuss this issue, and it feels extremely strange to me that I have to say this, but I have learned that not only do I need to say it, I need to periodically repeat it: I'm not claiming that it's a good idea to convert a C program into a program that has the same required observable behavior in C and C++. I'm not saying such a transformation would improve the program in any way. I'm merely pointing out that it is feasible, and I'm pointing it out solely for the purpose of refuting the ridiculous claim that C and C++ are two entirely different languages. If that claim were true, such a conversion would almost never be possible, whereas in reality, it's almost always possible. Any objection you have to the way I've constructed my argument should support that ridiculous claim - if it doesn't, you've missed the point of my argument. I restricted my comments in this sub-thread to programs with a length less than N, just to deal with objections based upon the fact that the relevant sets are infinite, making it tricky to make comparisons of the sizes of those sets. But as far as I know, there isn't any C program with defined behavior that can't be converted to a program that can be compiled as either C or C++ code, with the same required observable behavior as the original. I wouldn't be surprised to hear of a few minor exceptions, but I would be very surprised to learn of any large number of exceptions. There's a tricky issue which I haven't addressed properly. I want to word my argument so that it applies not only to strictly conforming programs, but also for the much larger set of program which fail to be strictly conforming only because they have output that depends upon unspecified behavior. The problem is that if the output depends upon unspecified behavior, then there may be two or more possible observable behaviors. When I talked about "observable behavior", in most cases I'm actually referring a set of different behaviors, all of which are allowed by the relevant standard. That set is often very large, possibly literally infinite, but there's also generally a very large set of observable behaviors that are not allowed. However, when I said that the code must have the "same observable behavior" when compiled by a C compiler and a compatible C++ compiler, that is precisely what I meant. While a large set of different behaviors may be allowed by the relevant standard, my definition of "compatible compilers" was intended to require that both compilers make exactly the same choice from that set. Proving two compilers to be compatible is probably impossible, but that's irrelevant to my argument. It's sufficient to prove that if a C compiler and a C++ compiler are compatible, they can each be conforming to the relevant standards, and that's easy to prove from the definition I provided. Proving that it's possible for a C compiler and a C++ compiler to be compatible in this sense is difficult, for precisely the same reason it's difficult to prove that it's possible for a compiler to conform to either standard separately. I make no attempt to provide such a proof. In such a context, the burden of proof is properly on the person who claims it's not possible - if you know of any reason why it's not possible, you should explain that reason. > Five, the test doesn't tell us very much because the criterion is > so weak. Turing equivalence is a very coarse filter. For > example, many Fortran programs can be transformed into an > equivalent Fortran program, of the same length, that is also a > well-formed and equivalent C program. That doesn't mean C and > Fortran should be considered to be closely related languages. Actually, I can't imagine a better reason for arguing that they are related languages. You certainly couldn't do that with, for instance, a typical APL program. The key word is "closely". The fraction of all Fortran programs where you could do that is much smaller than the number of C programs that can be to the common subset of C and C++, and that is precisely the sense in which C is far more closely related to C++ than it is to Fortran.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-09-04 06:38 -0700 |
| Message-ID | <86k0x97jd1.fsf@linuxsc.com> |
| In reply to | #152864 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On Sunday, June 21, 2020 at 4:26:05 AM UTC-4, Tim Rentsch wrote: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> >>> On 6/2/20 2:39 PM, John Bode wrote: > > ... > >>>> 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. The two >>>> languages continue to diverge as time goes on. >>> >>> That's true, modulo providing a definition of "legal" (neither >>> standard uses that term). >>> >>> In order to make this more meaningful, I'm going to talk about >>> compatible implementations of C and C++, a term that I need to >>> define. An implementation of C and an implementation of C++ are >>> compatible if, for any given construct, if the meaning or behavior >>> permitted by the C standard for that construct has any overlap >>> with the meaning or behavior permitted by the C++ standard for >>> that same construct, both implementations will give that construct >>> the same meaning or behavior. >>> >>> The fact that both sets are infinite obscures an important point. >>> Rather than looking at infinite sets, lets look at finite ones. >>> Consider sequences of no more than N characters from the basic >>> source character set. >>> >>> A sub-set C(N) of those sequences qualify as having no syntax >>> errors, constraint violations or undefined behavior according to >>> the C standard. This sub-set can be further sub-divided into >>> equivalence classes, every member of which has the same observable >>> behavior under a given implementation of C for all possible >>> inputs. >>> >>> A subset CPP(N) of all sequences of length N or less qualifies as >>> well-formed code having no syntax errors or undefined behavior >>> according to the C++ standard. >>> >>> Note that, in both subsets, I'm including programs with unspecified >>> behavior. >>> >>> I believe that, for the overwhelming majority of the equivalence >>> classes of C(N), there's at least one member of that class that is >>> also in CPP(N), and which has the same observable behavior if >>> compiled using a compatible implementation of C++. Those members >>> might qualify as poorly-written in either language, but they don't >>> have any problems as far as the C standard is concerned. >> >> There are several problems with this argument. >> >> One, there is no evidence at all offered to say the statement of >> belief is true. > > Evidence isn't really relevant. [...] You didn't offer any reasoning either. You simply gave a statement of belief. >> Two, looking at any given C program, there is no way to know with >> certainty that a corresponding equivalent C-and-C++ program >> exists (in the sense of also satisfying the C(N) and CPP(N) >> conditions). > > [...] The overwhelming majority of equivalence classes > in C(N) have many members that are much smaller than N: [...] Certainly that is true of many programs but you haven't given a convincing argument that it is true for an overwhelming majority of programs. Furthermore you haven't said anything about how long a corresponding C++ program would be. >> Three, when looking at a particular C program and a proposed >> candidate C-and-C++ program, there is no way to know with >> certainty that the two programs are equivalent, because testing >> for equivalence is undecidable. So the hypothesis is probably >> impossible to verify. > > You're looking at it wrong. It might be difficult, even impossible, to > confirm that two arbitrary programs have the same required observable > behavior. However, my argument doesn't require that determination to be > made for arbitrary programs. It's trivial to come up with > transformations that take one program and convert it into another > program with the same required observable behavior, and that's all I > need to support my claim. You're wrong that it is trivial. I'm not sure it is even decidable. > It can also be impossible to determine whether any given program has > defined behavior - but I don't need to determine that to support my > claim, either. It's sufficient for what I'm saying that if I take a > program that has defined behavior, there are transformations that can > convert it into another program that has the same defined behavior. You haven't given any reasoning to say such tranformations exist, or that we can find or identify them if they do. > The key point is that there's only a relatively small set of issues that > need to be addressed: Annex C of the C++ standard is only 24 pages long. > For each item in Annex C, there's generally a relatively straightforward > transformation to the code that will address the item. If you feel > otherwise about any particular issue, you should identify it. You seem to think the list in Annex C is complete. You also seem to think that I bear some burden to convince you of some sort of error in your reasoning. That's backwards. You are the one making the claim, and so the burden is on you to provide convincing evidence or reasoning, or both, that your claim is correct. You are in effect offering a proof by assertion. >> Four, the test suggested bears no obvious relationship to any of >> the usual ways that programs are evaluated. More briefly, the >> test looks artificial. Because of that it seems to have little >> conceptual value. > > [...] I'm not claiming that it's a good idea to convert a C > program into [an equivalent C++ program]. [...] > I'm merely pointing out that it is feasible, [...] Your argument is then missing an essential step. Just because it may be possible to transform a C program into an equivalent C program that is also well-formed and equivalent C++ (which has so far not been established), that doesn't mean that C and C++ are necessarily "close" languages. In practice C programs and C++ programs don't look like each other. There are (relatively speaking) very few existing C programs that are also well-formed C++ programs. Furthermore, if an existing C program were to be transformed in a way like you suggest, whoever originally wrote the C program would very likely not continue working on it in the modified form, because "it doesn't look like C". I don't know of even a single counter-example to this rule, and certainly exceptions would be rare if they even exist at all. The metric you propose, even if it does happen to be satisfied, doesn't tell us anything about whether the two languages are closely related in the usual sense of the word. It's an artificial definition, used to support vacuous result.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-09-06 05:52 -0700 |
| Message-ID | <60438410-39e9-45f1-9858-94efe6f251ddn@googlegroups.com> |
| In reply to | #154485 |
On Friday, September 4, 2020 at 9:38:25 AM UTC-4, Tim Rentsch wrote: > James Kuyper <james...@alumni.caltech.edu> writes: > > > On Sunday, June 21, 2020 at 4:26:05 AM UTC-4, Tim Rentsch wrote: ... > >> Two, looking at any given C program, there is no way to know with > >> certainty that a corresponding equivalent C-and-C++ program > >> exists (in the sense of also satisfying the C(N) and CPP(N) > >> conditions). > > > > [...] The overwhelming majority of equivalence classes > > in C(N) have many members that are much smaller than N: [...] > > Certainly that is true of many programs but you haven't given > a convincing argument that it is true for an overwhelming > majority of programs. ... For any given equivalence class, the overwhelming majority of programs that are of length N or less can be trivially compressed by removing unnecessary white space, by renaming identifiers to be as short as possible (with the most frequently used identifiers being given the shortest names, and taking maximum advantage of the fact that declarations of identifiers in inner scopes hide identifiers in outer scopes to avoid being required to use longer names). Most importantly, since we're talking about all strictly conforming programs of length N or less with equivalent observable behavior, most of them are very badly designed, containing lines like "a = b; a = c;" which can simplified to "a=c;". Keep in mind that I'm merely interested in showing the feasibility of converting the code. I'm not claiming that the conversion is desirable, merely pointing out that the fact that it's possible renders ridiculous the claim that the two languages are completely distinct. Finally, the only reason I'm focusing on equivalence classes of programs of length <= N is because you insisted on pointlessly worrying about he fact that the original claim nominally covered programs of arbitrarily great length. I'm pointing out that the smallest member of most equivalence class is much smaller than N (no matter how big N is, there will always be a very large number (but a very small fraction) of all equivalence classes where the smallest member is NOT much smaller than N; for most values of N, there will be many equivalence classes where it's exactly N), solely for the purpose of ensuring that there's enough room for there to be a reasonable chance that at least one of those programs would have the same required behavior if interpreted as C++ code. That's something I need to do only because of your silly worry about the nominally unbounded size of the programs allowed by the original version of this claim. > ... Furthermore you haven't said anything > about how long a corresponding C++ program would be. From a careful reading of Annex C.1 of the C++ standard, and my own past experience with such conversions, the conversion may sometimes require a minor increase in the program size, which is the only reason I bothered pointing out that the smallest member of each equivalence class is usually significantly smaller than N. However, I don't see any plausible way the conversion would frequently increase the size significantly. I'm sure that a carefully constructed example might require a substantial increase in the size, but that would not at all be the normal case. For example, a cast needs to be added to malloc() calls, which adds only a small amount to the code size of most programs. There are some important differences in how scopes are handled in C and C++, and how name spaces (not namespaces, which are something different) are handled. The net result is that an inner scope identifier can hide an outer scope identifier according to C rules, but not according to C++ rules, or vice versa - a problem that can be solved by simply changing one of the identifiers so that hiding is no longer an issue. You seem to believe that the conversion would often require a major restructuring of the program. My own understanding of these issues, and my own experience with performing such conversions, suggests that this is not the case. It would help greatly to make your case if you would identify a specific difference between C and C++ that would require such a major restructuring. ... > > You're looking at it wrong. It might be difficult, even impossible, to > > confirm that two arbitrary programs have the same required observable > > behavior. However, my argument doesn't require that determination to be > > made for arbitrary programs. It's trivial to come up with > > transformations that take one program and convert it into another > > program with the same required observable behavior, and that's all I > > need to support my claim. > You're wrong that it is trivial. I'm not sure it is even > decidable. Can you give even a single example of a situation where it would be hard to do? The hardest part, in my opinion, is due to the fact that the languages differ slightly with respect to the rules which determine which identifier declarations hide the declaration of other identifiers. However, pragmatically that's not a major problem, for a couple of reasons. First of all, intelligent programmers tend to avoid creating code where that matters, because using the same identifier for two different purposes can make things confusing. Secondly, the side effects of such a difference almost always result in code for which a diagnostic is mandatory - when I wrote my example program demonstrating that problem, I had to work very hard to come up with an example for which a diagnostic wasn't mandatory. As a practical matter, if you compile the program with C++, and fix the cases that generate diagnostics, you're most of the way there. If you test the resulting program properly, you should find the overwhelming majority of the remaining problems. Sure, it can be difficult to be certain that the resulting program has the same required behavior in both languages. However, because the overlap between the languages contains the overwhelming majority of the features of C, it's not substantially more difficult than confirming that the original program had required behavior according to C that matches it's requirements - which is itself a very difficult task. > > It can also be impossible to determine whether any given program has > > defined behavior - but I don't need to determine that to support my > > claim, either. It's sufficient for what I'm saying that if I take a > > program that has defined behavior, there are transformations that can > > convert it into another program that has the same defined behavior. > You haven't given any reasoning to say such tranformations exist, > or that we can find or identify them if they do. That's because the required transformations are explained, or at least implied, by the contents of Annex C.1 of the C++ standard. Each item listed there has an part titled (IIRC - I don't have access to a copy of the standard right now) "Ease of conversion". I'm not going to copy 9 pages of the C++ standard into a usenet newsgroup just to satisfy you that such conversions are possible. Identify a single significant problem that you believe is either inappropriately minimized or even completely ignored by Annex C.1, and then we can discuss it. > The key point is that there's only a relatively small set of issues that > > need to be addressed: Annex C of the C++ standard is only 24 pages long. > > For each item in Annex C, there's generally a relatively straightforward > > transformation to the code that will address the item. If you feel > > otherwise about any particular issue, you should identify it. > You seem to think the list in Annex C is complete. The C++ standard claims that it is, and I'm not aware of any significant failure of it to be complete. > You also seem > to think that I bear some burden to convince you of some sort of > error in your reasoning. That's backwards. You are the one making > the claim, and so the burden is on you to provide convincing > evidence or reasoning, or both, that your claim is correct. You > are in effect offering a proof by assertion. No, I'm asserting that it is something so obviously true based upon my own experience with the matter that the truth should be clear to anyone who knows both languages well and examines Annex C.1 of the C++ standard. Your claim that it's incomplete conflicts with the description of that section in the standard, and you are therefore the one who needs to justify that claim. A single significant difference that should be in that section, but isn't, would be a step toward justifying your objections. I suspect, from the vehemence of your objections, that you're thinking of some issue that doesn't actually belong in that section and isn't actually relevant to my argument. > >> Four, the test suggested bears no obvious relationship to any of > >> the usual ways that programs are evaluated. More briefly, the > >> test looks artificial. Because of that it seems to have little > >> conceptual value. > > > > [...] I'm not claiming that it's a good idea to convert a C > > program into [an equivalent C++ program]. [...] > > I'm merely pointing out that it is feasible, [...] > > Your argument is then missing an essential step. Just because it > may be possible to transform a C program into an equivalent C > program that is also well-formed and equivalent C++ (which has so > far not been established), that doesn't mean that C and C++ are > necessarily "close" languages. I have to disagree - if every strictly conforming C program can be converted into a program that is both strictly conforming C and well-formed C++, with the same required observable behavior in both languages as the original program, then I don't see how you could justify saying that they aren't close. You are manifestly saying it - but doing so makes you look insane to me. > ... In practice C programs and C++ > programs don't look like each other. A fact that is irrelevant to my point. C++ may have a great many features that go beyond C, and use of those features may be such a good idea that most C++ programs make heavy use of them - but as long as it continues to allow programs written without those features to behave the same way that they would if compiled as C code, the two languages will continue to be closely related. For any two languages that are truly distinct, like FORTRAN and Haskell, you couldn't even come close to making such a claim. Even if I can't get you to admit that C and C++ are closely related in any absolute sense, can I at least get you to admit that they're VERY much more closely related than FORTRAN and Haskell are? > ... There are (relatively > speaking) very few existing C programs that are also well-formed > C++ programs. Furthermore, if an existing C program were to be > transformed in a way like you suggest, whoever originally wrote > the C program would very likely not continue working on it in > the modified form, because "it doesn't look like C". The resulting program, in my experience, is only subtly different from the original. It looks very much like C, and contains few, if any, features that a C programmer would object to. In fact, the biggest change usually required, addition of casts to malloc() calls, is one that many C programmers actually insist on.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-09-10 06:37 -0700 |
| Message-ID | <864ko569dv.fsf@linuxsc.com> |
| In reply to | #154615 |
Please post a followup response through other than google groups. Thank you.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-09-08 16:54 +0200 |
| Message-ID | <rj85ud$npm$2@dont-email.me> |
| In reply to | #152604 |
OMG, what an idiot.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-09-08 16:52 +0200 |
| Message-ID | <rj85ru$npm$1@dont-email.me> |
| In reply to | #152596 |
> C and C++ are completely different languages, so this shouldn't be surprising. That's a nerd-statement. The truth is that by far the largest part of C is also part of C++.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2020-06-02 18:45 +0000 |
| Message-ID | <rb66nd$kc0$1@gioia.aioe.org> |
| In reply to | #152592 |
In comp.lang.c++ Real Troll <real.troll@trolls.com> wrote: > Just noticed that these two program give two different results. One is a > C program and other is a C++ program. The type of 'a' in C is int, while in C++ it's char. I'm not exactly sure why its type is int in C (given that C has always had char as a type, and it has, too, mostly been designed from the ground up with the philosophy of "you don't pay for what you don't use"). Maybe it has something to do with C, at least originally, supporting multi-character constants like 'ab'. I'm also not completely certain why this is one thing which C++ decided to change. (I suppose it's good that it changed it, but I'm not really sure why this.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-06-02 19:55 +0100 |
| Message-ID | <0hxBG.358078$ED6.123222@fx03.am4> |
| In reply to | #152605 |
On 02/06/2020 19:45, Juha Nieminen wrote: > In comp.lang.c++ Real Troll <real.troll@trolls.com> wrote: >> Just noticed that these two program give two different results. One is a >> C program and other is a C++ program. > > The type of 'a' in C is int, while in C++ it's char. I'm not exactly > sure why its type is int in C (given that C has always had char as a > type, and it has, too, mostly been designed from the ground up with > the philosophy of "you don't pay for what you don't use"). Maybe > it has something to do with C, at least originally, supporting > multi-character constants like 'ab'. Maybe because the type of 97 is int too. Then 'a' is just another way of writing 97.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2020-06-02 15:11 -0400 |
| Message-ID | <rb688o$e9f$4@dont-email.me> |
| In reply to | #152607 |
On June 2, 2020 14:55, Bart wrote: > On 02/06/2020 19:45, Juha Nieminen wrote: >> In comp.lang.c++ Real Troll <real.troll@trolls.com> wrote: >>> Just noticed that these two program give two different results. One is a >>> C program and other is a C++ program. >> >> The type of 'a' in C is int, while in C++ it's char. I'm not exactly >> sure why its type is int in C (given that C has always had char as a >> type, and it has, too, mostly been designed from the ground up with >> the philosophy of "you don't pay for what you don't use"). Maybe >> it has something to do with C, at least originally, supporting >> multi-character constants like 'ab'. > > Maybe because the type of 97 is int too. Then 'a' is just another way of > writing 97. Perhaps you are joking? Everyone knows that the C character constant 'a' has a value of 129 (in EBCDIC-US, of course). -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2020-06-02 20:14 +0000 |
| Message-ID | <sqyBG.446135$zk6.417866@fx14.am4> |
| In reply to | #152611 |
On 2020-06-02, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: > On June 2, 2020 14:55, Bart wrote: > >> On 02/06/2020 19:45, Juha Nieminen wrote: >>> In comp.lang.c++ Real Troll <real.troll@trolls.com> wrote: >>>> Just noticed that these two program give two different results. One is a >>>> C program and other is a C++ program. >>> >>> The type of 'a' in C is int, while in C++ it's char. I'm not exactly >>> sure why its type is int in C (given that C has always had char as a >>> type, and it has, too, mostly been designed from the ground up with >>> the philosophy of "you don't pay for what you don't use"). Maybe >>> it has something to do with C, at least originally, supporting >>> multi-character constants like 'ab'. >> >> Maybe because the type of 97 is int too. Then 'a' is just another way of >> writing 97. > > Perhaps you are joking? > > Everyone knows that the C character constant 'a' has a value of 129 (in > EBCDIC-US, of course). I knew EBCDIC in 90es, now forgot... didn't had a chance to use it recently ;) > -- current job title: senior software engineer skills: c++,c,rust,go,nim,haskell... press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2020-06-02 16:19 -0400 |
| Message-ID | <rb6c7o$ck$1@dont-email.me> |
| In reply to | #152617 |
On June 2, 2020 16:14, Melzzzzz wrote: > On 2020-06-02, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: >> On June 2, 2020 14:55, Bart wrote: >> >>> On 02/06/2020 19:45, Juha Nieminen wrote: >>>> In comp.lang.c++ Real Troll <real.troll@trolls.com> wrote: >>>>> Just noticed that these two program give two different results. One is >>>>> a C program and other is a C++ program. >>>> >>>> The type of 'a' in C is int, while in C++ it's char. I'm not exactly >>>> sure why its type is int in C (given that C has always had char as a >>>> type, and it has, too, mostly been designed from the ground up with >>>> the philosophy of "you don't pay for what you don't use"). Maybe >>>> it has something to do with C, at least originally, supporting >>>> multi-character constants like 'ab'. >>> >>> Maybe because the type of 97 is int too. Then 'a' is just another way of >>> writing 97. >> >> Perhaps you are joking? >> >> Everyone knows that the C character constant 'a' has a value of 129 (in >> EBCDIC-US, of course). > > I knew EBCDIC in 90es, now forgot... didn't had a chance to use it > recently ;) I retired, from the IBM mainframe world, over a decade ago. I haven't had any recent use for EBCDIC (of any flavour), and am happier for it. But, in the day, ..... -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web