Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #152592 > unrolled thread

Two different Results between C and C++

Back to article view | Back to comp.lang.c

Contents

  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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#154800

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On Thursday, September 3, 2020 at 2:00:54 AM UTC-4, Tim Rentsch wrote:
> ...
>
>> The bigger problem is C code that is legal C++ but has different
>> semantics in C++ than in C.  There are more of these than most
>> C or C++ developers think there are.  I don't know anyone,
>> including myself, who can say with confidence that they know
>> all the different ways that source code can have a different
>> meaning in C++ compared to C. ...
>
> Those ways are listed in Annex C.1 of the C++ standard.  [...]

Some are.  Some are not.

[toc] | [prev] | [next] | [standalone]

#154806

On Thursday, September 10, 2020 at 9:20:36 AM UTC-4, Tim Rentsch wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> 
> > On Thursday, September 3, 2020 at 2:00:54 AM UTC-4, Tim Rentsch wrote:
> > ...
> >
> >> The bigger problem is C code that is legal C++ but has different
> >> semantics in C++ than in C.  There are more of these than most
> >> C or C++ developers think there are.  I don't know anyone,
> >> including myself, who can say with confidence that they know
> >> all the different ways that source code can have a different
> >> meaning in C++ compared to C. ...
> >
> > Those ways are listed in Annex C.1 of the C++ standard.  [...]
> 
> Some are.  Some are not.

So you've frequently claimed, but you've never identified even a single
such difference. If significant differences are sufficiently numerous to
justify objecting to C and C++ being characterized as closely related
languages, then it should be trivial to identify a single significant
difference that's not listed.

Proving that the list is complete is much harder; it's essentially
impossible, even if the list is complete. I could review every single
sentence in the C standard, and compare carefully with corresponding
sentences in the C++ standard, and spend a lot of time trying to figure
out whether each difference qualifies for Annex C.1 of the C++ standard
(that list is not supposed to include explicit use of features that are
unique to one language or the other, but only differences in the meaning
of code that is syntactically correct in both languages).

You would not want me to post to this newsgroup the results of such an
analysis - it would require a document much longer than the C standard
and the C++ standard combined to report on that analysis.

If, after having done all that, I came back and reported "I didn't find
any differences beyond the ones listed in Annex C.1", you could (and I'm
quite sure, would) simply respond with "are you sure you didn't miss
anything?", while failing to identify what it was you thought I'd
missed.

I shouldn't have to do this - the committee members have already
performed such a review - they have a much larger workforce than I do,
and a wide variety of different viewpoints to bring to the review. If
they did a less than perfect job (and I freely admit that they might
have) with their experience, expertise, and man-power, I'm not likely to
find their failures in a random search.

You, on the other hand, have not merely claimed that it might be
incomplete - you claimed to know that it is incomplete. This implies
that you already know of at least one significant difference that, in
your opinion, should have been listed in Annex C.1. All you have to do
to prove that point is deign to let us know what one of those
differences is.

While a single such difference would be sufficient to prove that the
list is incomplete, that wouldn't be sufficient to win this argument.
I've never denied that there might be a few missing differences.
However, there would have to be a large number of significant
differences to justify claiming that C and C++ are not closely related.
I can understand why you might be reluctant to provide examples that
won't be sufficient to justify your objections.

However, you shouldn't be doing this just to win points in a argument -
if there are such differences, they should be brought to the attention
of the C++ committee so they can correct Annex C.1 in the next version
of the standard.

[toc] | [prev] | [next] | [standalone]

#154807

On Thursday, September 10, 2020 at 9:36:44 AM UTC-4, Tim Rentsch wrote:
> Please post a followup response through other than google groups.
> Thank you.

Why? But, since it's trivial to do so, I will. I apologize to the rest
of the group for the double posting.

On Thursday, September 10, 2020 at 9:20:36 AM UTC-4, Tim Rentsch wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> 
> > On Thursday, September 3, 2020 at 2:00:54 AM UTC-4, Tim Rentsch wrote:
> > ...
> >
> >> The bigger problem is C code that is legal C++ but has different
> >> semantics in C++ than in C.  There are more of these than most
> >> C or C++ developers think there are.  I don't know anyone,
> >> including myself, who can say with confidence that they know
> >> all the different ways that source code can have a different
> >> meaning in C++ compared to C. ...
> >
> > Those ways are listed in Annex C.1 of the C++ standard.  [...]
> 
> Some are.  Some are not.

So you've frequently claimed, but you've never identified even a single
such difference. If significant differences are sufficiently numerous to
justify objecting to C and C++ being characterized as closely related
languages, then it should be trivial to identify a single significant
difference that's not listed.

Proving that the list is complete is much harder; it's essentially
impossible, even if the list is complete. I could review every single
sentence in the C standard, and compare carefully with corresponding
sentences in the C++ standard, and spend a lot of time trying to figure
out whether each difference qualifies for Annex C.1 of the C++ standard
(that list is not supposed to include explicit use of features that are
unique to one language or the other, but only differences in the meaning
of code that is syntactically correct in both languages).

You would not want me to post to this newsgroup the results of such an
analysis - it would require a document much longer than the C standard
and the C++ standard combined to report on that analysis.

If, after having done all that, I came back and reported "I didn't find
any differences beyond the ones listed in Annex C.1", you could (and I'm
quite sure, would) simply respond with "are you sure you didn't miss
anything?", while failing to identify what it was you thought I'd missed.

I shouldn't have to do this - the committee members have already
performed such a review - they have a much larger workforce than I do,
and a wide variety of different viewpoints to bring to the review. If
they did a less than perfect job (and I freely admit that they might
have) with their experience, expertise, and man-power, I'm not likely to
find their failures in a random search.

You, on the other hand, have not merely claimed that it might be
incomplete - you claimed to know that it is incomplete. This implies
that you already know of at least one significant difference that, in
your opinion, should have been listed in Annex C.1. All you have to do
to prove that point is deign to let us know what one of those
differences is.

While a single such difference would be sufficient to prove that the
list is incomplete, that wouldn't be sufficient to win this argument.
I've never denied that there might be a few missing differences.
However, there would have to be a large number of significant
differences to justify claiming that C and C++ are not closely related.
I can understand why you might be reluctant to provide examples that
won't be sufficient to justify your objections.

However, you shouldn't be doing this just to win points in a argument -
if there are such differences, they should be brought to the attention
of the C++ committee so they can correct Annex C.1 in the next version
of the standard.

[toc] | [prev] | [next] | [standalone]

#152984

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [...]
> >> 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.

You're even more wrong, then, because almost all real-world C programs
are written without pandering to C++'s neuroses. I'll grant you that
most of them might be munged into legal C++ programs by expending the
small but ridiculous effort of hauling them through Bjarne Mungler
Automatic 2000, but at that point they won't be C programs worth the
name any more. Much like you can take Arthur Conan Doyle, run him
through Hollywood, and get Elementary; which shits on Doyle's legacy.
It's small effort, yes. But the result is not what you started out with.

Richard

[toc] | [prev] | [next] | [standalone]

#152992

raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>> >> 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.
>
> You're even more wrong, then, because almost all real-world C programs
> are written without pandering to C++'s neuroses. I'll grant you that
> most of them might be munged into legal C++ programs by expending the
> small but ridiculous effort of hauling them through Bjarne Mungler
> Automatic 2000, but at that point they won't be C programs worth the
> name any more. Much like you can take Arthur Conan Doyle, run him
> through Hollywood, and get Elementary; which shits on Doyle's legacy.
> It's small effort, yes. But the result is not what you started out with.

You agree that it's a small effort.  Doesn't that mean you agree with my
original statement?  Here it is again:

    But almost all programs that are legal C but not legal C++ can be
    made into legal C++ with a small effort.

At no time did I suggest it would be a good idea.  (And I'm profoundly
uninterested in debating the merits of C++ here.)

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

#153000

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

> raltbos@xs4all.nl (Richard Bos) writes:

> > You're even more wrong, then, because almost all real-world C programs
> > are written without pandering to C++'s neuroses. I'll grant you that
> > most of them might be munged into legal C++ programs by expending the
> > small but ridiculous effort of hauling them through Bjarne Mungler
> > Automatic 2000, but at that point they won't be C programs worth the
> > name any more. Much like you can take Arthur Conan Doyle, run him
> > through Hollywood, and get Elementary; which shits on Doyle's legacy.
> > It's small effort, yes. But the result is not what you started out with.
> 
> You agree that it's a small effort.  Doesn't that mean you agree with my
> original statement?  Here it is again:
> 
>     But almost all programs that are legal C but not legal C++ can be
>     made into legal C++ with a small effort.
> 
> At no time did I suggest it would be a good idea.

If you had added _that_, I would not have disagreed. It is the crucial
point.

Yes, there is a considerable overlap between C and C++. All second-year
programmers know that. It takes a professional to learn that very little
in that overlap is useful or interesting, and we should not encourage
beginning programmers to believe that casting malloc() or relying on the
sizes of character constants is a good idea.

Richard

[toc] | [prev] | [next] | [standalone]

#153005

raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> raltbos@xs4all.nl (Richard Bos) writes:
>> > You're even more wrong, then, because almost all real-world C programs
>> > are written without pandering to C++'s neuroses. I'll grant you that
>> > most of them might be munged into legal C++ programs by expending the
>> > small but ridiculous effort of hauling them through Bjarne Mungler
>> > Automatic 2000, but at that point they won't be C programs worth the
>> > name any more. Much like you can take Arthur Conan Doyle, run him
>> > through Hollywood, and get Elementary; which shits on Doyle's legacy.
>> > It's small effort, yes. But the result is not what you started out with.
>> 
>> You agree that it's a small effort.  Doesn't that mean you agree with my
>> original statement?  Here it is again:
>> 
>>     But almost all programs that are legal C but not legal C++ can be
>>     made into legal C++ with a small effort.
>> 
>> At no time did I suggest it would be a good idea.
>
> If you had added _that_, I would not have disagreed. It is the crucial
> point.

It may be crucial to the point you want to make.  It was not relevant to
the statement I made.

> Yes, there is a considerable overlap between C and C++. All second-year
> programmers know that. It takes a professional to learn that very little
> in that overlap is useful or interesting, and we should not encourage
> beginning programmers to believe that casting malloc() or relying on the
> sizes of character constants is a good idea.

Agreed, but it's not what I was talking about.  I made a correct
statement.  You disagreed with it.  But now that we're in agreement
on the facts (if not about who said what), I suggest we can drop
this.

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

#153006

On 6/29/20 5:46 PM, Richard Bos wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 
...
>>     But almost all programs that are legal C but not legal C++ can be
>>     made into legal C++ with a small effort.
>>
>> At no time did I suggest it would be a good idea.
> 
> If you had added _that_, I would not have disagreed. It is the crucial
> point.

Why should he need to add that? Why wasn't a complete failure to make
any such suggestion sufficient?

> Yes, there is a considerable overlap between C and C++. All second-year
> programmers know that. It takes a professional to learn that very little
> in that overlap is useful or interesting, 

I find that knowing that the expression a+b specifies that the value of
a should be added to the value of b is very useful, and it is equally
true of both C and C++. Both languages add complications to that
description, but in the context of types that can be expressed in C,
those complications (such as the integer promotion rules and the usual
arithmetic conversions) are quite similar.

There's literally thousands of other similar features of C that are also
features of C++; in total, those features constitute an overwhelming
majority of the features that C possesses, and it's impossible to write
any significant amount of C++ code without making frequent use of those
features. So your description of that overlap as not being useful sounds
quite weird to me. I think that you're so familiar with those features
that they have become effectively invisible to you.

> ... and we should not encourage
> beginning programmers to believe that casting malloc() or relying on the
> sizes of character constants is a good idea.

No one has suggested anything of the kind, and I'm curious what gave you
the impression that anyone had.

[toc] | [prev] | [next] | [standalone]

#153008

On 30.06.20 0:53, James Kuyper wrote:
> On 6/29/20 5:46 PM, Richard Bos wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>
> ...
>>>      But almost all programs that are legal C but not legal C++ can be
>>>      made into legal C++ with a small effort.
>>>
>>> At no time did I suggest it would be a good idea.
>>
>> If you had added _that_, I would not have disagreed. It is the crucial
>> point.
>
> Why should he need to add that? Why wasn't a complete failure to make
> any such suggestion sufficient?
>
>> Yes, there is a considerable overlap between C and C++. All second-year
>> programmers know that. It takes a professional to learn that very little
>> in that overlap is useful or interesting,
>
> I find that knowing that the expression a+b specifies that the value of
> a should be added to the value of b is very useful, and it is equally
> true of both C and C++. Both languages add complications to that
> description, but in the context of types that can be expressed in C,
> those complications (such as the integer promotion rules and the usual
> arithmetic conversions) are quite similar.
>
> There's literally thousands of other similar features of C that are also
> features of C++; in total, those features constitute an overwhelming
> majority of the features that C possesses, and it's impossible to write
> any significant amount of C++ code without making frequent use of those
> features. So your description of that overlap as not being useful sounds
> quite weird to me. I think that you're so familiar with those features
> that they have become effectively invisible to you.
>
>> ... and we should not encourage
>> beginning programmers to believe that casting malloc() or relying on the
>> sizes of character constants is a good idea.
>
> No one has suggested anything of the kind, and I'm curious what gave you
> the impression that anyone had.
>
The meaning of  a+b in c++ can be completely redefined, like
linking string a and string b .
Anything you read in a c++ program might have been obfuscated.

[toc] | [prev] | [next] | [standalone]

#153010

Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> writes:
> On 30.06.20 0:53, James Kuyper wrote:
>> On 6/29/20 5:46 PM, Richard Bos wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> ...
>>>>      But almost all programs that are legal C but not legal C++ can be
>>>>      made into legal C++ with a small effort.
>>>>
>>>> At no time did I suggest it would be a good idea.
>>>
>>> If you had added _that_, I would not have disagreed. It is the crucial
>>> point.
>>
>> Why should he need to add that? Why wasn't a complete failure to make
>> any such suggestion sufficient?
>>
>>> Yes, there is a considerable overlap between C and C++. All second-year
>>> programmers know that. It takes a professional to learn that very little
>>> in that overlap is useful or interesting,
>>
>> I find that knowing that the expression a+b specifies that the value of
>> a should be added to the value of b is very useful, and it is equally
>> true of both C and C++. Both languages add complications to that
>> description, but in the context of types that can be expressed in C,
>> those complications (such as the integer promotion rules and the usual
>> arithmetic conversions) are quite similar.
>>
>> There's literally thousands of other similar features of C that are also
>> features of C++; in total, those features constitute an overwhelming
>> majority of the features that C possesses, and it's impossible to write
>> any significant amount of C++ code without making frequent use of those
>> features. So your description of that overlap as not being useful sounds
>> quite weird to me. I think that you're so familiar with those features
>> that they have become effectively invisible to you.
>>
>>> ... and we should not encourage
>>> beginning programmers to believe that casting malloc() or relying on the
>>> sizes of character constants is a good idea.
>>
>> No one has suggested anything of the kind, and I'm curious what gave you
>> the impression that anyone had.
>>
> The meaning of  a+b in c++ can be completely redefined, like
> linking string a and string b .
> Anything you read in a c++ program might have been obfuscated.

As James wrote:

    Both languages add complications to that description, but in the
    context of types that can be expressed in C, those complications
    (such as the integer promotion rules and the usual arithmetic
    conversions) are quite similar.

The meaning of a+b *when it's a valid C expression* cannot be redefined
in C++.

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

#153014

On 30/06/2020 01:40, Sjouke Burry wrote:

> The meaning of  a+b in c++ can be completely redefined, like
> linking string a and string b .
> Anything you read in a c++ program might have been obfuscated.

In C, "a" and "b" could be macros, making "a + b" far from obvious.  And
even without macros, the types could be anything from "char" to "complex
long double".  C++ offers more scope for obfuscation because it offers
features such as operator overloading - any feature of a programming
language that lets you write good code in more convenient or concise
ways will inevitably also let you write bad code in more concise ways.
But C++ does not have a monopoly on obfuscated code any more than C has
an monopoly on clear code.

[toc] | [prev] | [next] | [standalone]

#153026

On 6/29/20 7:40 PM, Sjouke Burry wrote:
> On 30.06.20 0:53, James Kuyper wrote:
>> On 6/29/20 5:46 PM, Richard Bos wrote:
...
>>> Yes, there is a considerable overlap between C and C++. All second-year
>>> programmers know that. It takes a professional to learn that very little
>>> in that overlap is useful or interesting,
>>
>> I find that knowing that the expression a+b specifies that the value of
>> a should be added to the value of b is very useful, and it is equally
>> true of both C and C++. Both languages add complications to that
>> description, but in the context of types that can be expressed in C,
>> those complications (such as the integer promotion rules and the usual
>> arithmetic conversions) are quite similar.
...
> The meaning of  a+b in c++ can be completely redefined, like
> linking string a and string b .

Yes, but the base meaning of a+b in C++ is essentially the same as in C,
and it's a rare C++ program that never makes use of the base meaning.
Knowing what that meaning is is therefore extremely useful when
programming in C++ - in conflict with the claim that "very little in
that overlap is useful".

[toc] | [prev] | [next] | [standalone]

#153009

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>There's literally thousands of other similar features of C that are also
>
>   There is or was a Web page that is IIRC somewhat difficult
>   to find with Web search engines. It listed dozens of little
>   differences in meaning between C and C++. It should be a
>   little bit aged by now, but I am still not aware of any
>   better page for this purpose.
>
> david.tribble.com/text/cdiffs.htm
> Incompatibilities Between ISO C and ISO C++
> by David R. Tribble

Dated 2001-08-05.  C++ has changed a lot since then.

>   Is this URI still valid? Well, intuitivly one might say, 
>   "It's valid if it points to a web object.", but it might 
>   be still be valid as a URI, even after the page is gone, 
>   well, whatever ...

Annex C of the C++ standard is probably a better source for that kind of
information.

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

#154480

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

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

[toc] | [prev] | [next] | [standalone]

#154514

On 2020-09-04, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> 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?

Most C programs I have ever looked at would likely present difficulties
simply being ported to a different compiler/environment.

A highly portable C program written in the C90 dialect is easy to
convert to C++, with overwhelming confidence that it's still the same
program. C++ has pretty much all features of C90, going as far back as
C++98 or even earlier to draft C++ dialects. A program using some later
C features, like mixed declarations and statements, // comments,
variables defined in for(;;) or inline functions might also still be
fairly easy to port to C++.

I'm not very confident on C99 or later code being easily convertible
to C++, compared to C90, what with all the designated initializers,
VLA's, type generic math and whatever not that can be used.
(Newer C++ revisions have probably picked up some newer C features; I
don't keep up with that.) In any case, code using C features that are
not in the target C++ dialect could require substantial refactoring.

Reagarding the "same program" topic: if we had to make changes for C++,
then of course it's not literally the same program as the one without
the changes; so first we have to convince ourselves that those changes
have not altered the program, when regarded as a C program. Then we
consider whether the C++ interpretation evokes the same meaning.

In that, we can have approximately the same confidence as that the
program is well-defined.

So that is to say, suppose we have edited the program so it builds as
C++, while remaining C at the same time. Having that program, suppose we
then face two activities: port the program to a different C compiler,
and port the program to a C++ compiler.

There is a concern that the program won't be "the same" when ported to
the C compiler, due to the risk that it has hidden nonportabilities that
do not affect its ability to be translated and executed. Now the concern
with regard to the C++ port is about of the same magnitude. The concerns
regarding C++ constructs behaving differently from C constructs are
dwarfed by the threat that the program contains hidden misuses of the
language. The program could have serious stability and security bugs
that are reproducible in the original port, not only ones that show up
under porting. If there is a reproducible buffer overflow in it
somewhere, then the C++ port will have it too, and so will the parallel
port to the new C compiler.

According to this reasoning, also, I would be more confident about a C
program that built and tested with GNU C program ported to GNU C++, than
about the same program ported to Intel C or what have you, because at
least the compiler back end is staying the same.  I would be more
confident, even if it requires no changes to build with the other C
compiler, while requiring some changes to become C++.

Porting to C++ can help uncover bugs in C (either during the initial
port, or later as the C++ port is maintained going forward). So at the
end of the exercise, we may end up with more certainties about the
behavior of the resulting C program than we had before.

In order to have absolutely no concern other that the C++ changes are
introducing bugs, what we need to start with is a maximally portable C
program that has been proven correct. The changes needed to make it C++
then give us, firstly, a C program which is no longer proven correct. We
must re-do the proof for that program as a C program to recover the
confidence that it's still the same program. Secondly, we don't have a
C++ program proven correct.  We must adjust our proof tools to recognize
C++ semantics of C features, and re-do the proof that way.

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

#154554

On 04/09/2020 20:44, Kaz Kylheku wrote:
> On 2020-09-04, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> 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?
> 
> Most C programs I have ever looked at would likely present difficulties
> simply being ported to a different compiler/environment.
> 
> A highly portable C program written in the C90 dialect is easy to
> convert to C++, with overwhelming confidence that it's still the same
> program. C++ has pretty much all features of C90, going as far back as
> C++98 or even earlier to draft C++ dialects. A program using some later
> C features, like mixed declarations and statements, // comments,
> variables defined in for(;;) or inline functions might also still be
> fairly easy to port to C++.
> 
> I'm not very confident on C99 or later code being easily convertible
> to C++, compared to C90, what with all the designated initializers,
> VLA's, type generic math and whatever not that can be used.
> (Newer C++ revisions have probably picked up some newer C features; I
> don't keep up with that.) In any case, code using C features that are
> not in the target C++ dialect could require substantial refactoring.
> 

A solid proportion of the C99 (vs. C90) features were based on copying
back from C++.  That applies in particular to heavily used features such
as ones you mentioned -  // comments, mixed declarations and statements,
defining a variable inside a "for" statement, etc.  It also includes
inline functions, and removing implicit int and implicit function
declaration.  There are a few lesser used points that are valid in C99
but not in C++, such as VLA's and designated initializers, but it would
usually not be difficult to re-write such code in a way that is valid
for both languages.  (Some arrays that would be VLA's in C99 are
actually constant-sized arrays in C++.)

The issue under discussion here is for /silent/ differences - things
that are valid in both languages but have different semantics.  Missing
features such as designated initialisers are easy to spot, because the
C++ compiler will complain about them (until C++20, IIRC, or a compiler
with extensions enabled).

[toc] | [prev] | [next] | [standalone]

#154705

Kaz Kylheku <793-849-0957@kylheku.com> writes:

> On 2020-09-04, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> 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?
>
> Most C programs I have ever looked at would likely present
> difficulties simply being ported to a different compiler/environment.
>
> A highly portable C program written in the C90 dialect is easy to
> convert to C++, with overwhelming confidence that it's still the
> same program.  C++ has pretty much all features of C90, going as
> far back as C++98 or even earlier to draft C++ dialects.  A
> program using some later C features, like mixed declarations and
> statements, // comments, variables defined in for(;;) or inline
> functions might also still be fairly easy to port to C++.
>
> I'm not very confident on C99 or later code being easily
> convertible to C++, compared to C90, what with all the designated
> initializers, VLA's, type generic math and whatever not that can
> be used.  (Newer C++ revisions have probably picked up some newer
> C features;  I don't keep up with that.)  In any case, code using
> C features that are not in the target C++ dialect could require
> substantial refactoring.
>
> Reagarding the "same program" topic:  if we had to make changes
> for C++, then of course it's not literally the same program as the
> one without the changes;  so first we have to convince ourselves
> that those changes have not altered the program, when regarded as
> a C program.  Then we consider whether the C++ interpretation
> evokes the same meaning.
>
> In that, we can have approximately the same confidence as that the
> program is well-defined.
>
> So that is to say, suppose we have edited the program so it builds
> as C++, while remaining C at the same time.  Having that program,
> suppose we then face two activities:  port the program to a
> different C compiler, and port the program to a C++ compiler.
>
> There is a concern that the program won't be "the same" when
> ported to the C compiler, due to the risk that it has hidden
> nonportabilities that do not affect its ability to be translated
> and executed.  Now the concern with regard to the C++ port is
> about of the same magnitude.  The concerns regarding C++
> constructs behaving differently from C constructs are dwarfed by
> the threat that the program contains hidden misuses of the
> language.  The program could have serious stability and security
> bugs that are reproducible in the original port, not only ones
> that show up under porting.  If there is a reproducible buffer
> overflow in it somewhere, then the C++ port will have it too, and
> so will the parallel port to the new C compiler.
>
> According to this reasoning, also, I would be more confident about
> a C program that built and tested with GNU C program ported to GNU
> C++, than about the same program ported to Intel C or what have
> you, because at least the compiler back end is staying the same.
> I would be more confident, even if it requires no changes to build
> with the other C compiler, while requiring some changes to become
> C++.
>
> Porting to C++ can help uncover bugs in C (either during the
> initial port, or later as the C++ port is maintained going
> forward).  So at the end of the exercise, we may end up with more
> certainties about the behavior of the resulting C program than we
> had before.
>
> In order to have absolutely no concern other that the C++ changes
> are introducing bugs, what we need to start with is a maximally
> portable C program that has been proven correct.  The changes
> needed to make it C++ then give us, firstly, a C program which is
> no longer proven correct.  We must re-do the proof for that
> program as a C program to recover the confidence that it's still
> the same program.  Secondly, we don't have a C++ program proven
> correct.  We must adjust our proof tools to recognize C++
> semantics of C features, and re-do the proof that way.

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).  They might or might not be either
highly portable or well defined (ie, they might have undefined
behavior under certain circumstances).  Porting the code to a
different C compiler is not a consideration:  there is a second
tacit assumption that the transformed code targets the same
implementation of C as the original.  Furthermore there is no
concern about the C++ implementation being "non-compatible":
there is a third tacit assumption that implementation-defined
behaviors in C++ such as size and representation of int, etc,
are chosen in the C++ implementation to match those of the
specified C implementation.

Given all that, we don't care if the transformed code is
"correct".  What we do care about is whether the transformed code
is equivalent to the original, in the sense that the resultant C
program, and also the (identical source) C++ program, has the
same semantics as the original program.  Assuming that condition
is met, the question is:  Can such transformations be effected,
with only a small effort in each case, for almost all real-world
C programs?

[toc] | [prev] | [next] | [standalone]

#154746

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.

[toc] | [prev] | [next] | [standalone]

#154748

On 9/8/20 8:50 PM, James Kuyper wrote:
...
> 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.

When a discussion has been going on for three months, like this one, I
sometimes lose track of what I've said before. Reviewing my older
messages on this thread, I see that I originally explicitly stated that
my arguments also applied to code with unspecified behavior. I also
restricted my argument to "compatible implementations" of C and C++, a
term that I defined as meaning that whenever a construct was
syntactically allowed by both languages, and there was any overlap
between the behavior allowed for that construct by the C standard and
the behavior allowed by the C++ standard, both implementations made the
same choice, which was by definition within that overlap.

That's a different way of addressing the same issue, and IMO a superior
one, now that I've reminded myself of that fact - it forces all the
details not specified by either language to be exactly the same.

[toc] | [prev] | [next] | [standalone]

#154749

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.

Getting back to the topic of this thread, Tim also wrote:

    Assuming that condition is met, the question is: Can such
    transformations be effected, with only a small effort in each case,
    for almost all real-world C programs?

(I've omitted some relevant context.  The phrase "such transformations"
refers to transforming a valid C program to a program that is valid C and
valid C++ and has equivalent semantics in both languages.  I may have
missed some nuance.)

I note that Tim has not, unless I've missed something, attempted
to answer that question himself.

In a similarly odd omission, I am not asking him to do so.

-- 
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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web