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

Groups > comp.lang.c > #154924

Re: Two different Results between C and C++

Show all headers | View raw

Tiib <ootiib@hot.ee> writes:

> On Tuesday, 8 September 2020 17:34:58 UTC+3, Tim Rentsch  wrote:
>
>> Tiib <ootiib@hot.ee> writes:
>>
>>> On Friday, 4 September 2020 16:45:16 UTC+3, Tim Rentsch  wrote:
>>>
>>>> Tiib <ootiib@hot.ee> writes:
>>>>
>>>>> On Thursday, 3 September 2020 09:00:54 UTC+3, Tim Rentsch  wrote:
>>>>>
>>>>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>>>>
>>>>>>> On 6/21/20 2:40 PM, Keith Thompson wrote:
>>>>>>>
>>>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>>>>
>>>>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [..snipped for brevity.. blank lines may indicate snipping..]
>>
>>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> When I wrote "almost all programs that are legal C but not
>>>>>>>> legal C++", I was referring to real-world programs, not the
>>>>>>>> infinite set of all possible programs.  I probably could have
>>>>>>>> made that clearer.
>>>>>>>
>>>>>>> My experiance would be a bit different, most C programs from the
>>>>>>> 'wild' would likely fail as C++ precisely because of the
>>>>>>> implicit conversion from void* that does not happen in C++.
>>>>>>> These programs can trivially be converted to programs which are
>>>>>>> valid in both C and C++ by adding the explicit cast.  [...]
>>>>>>
>>>>>> Lots of C programs fail as C++ because of constraint violations
>>>>>> or syntax errors.  The problems are (obviously) easy to find,
>>>>>> and mostly I think easy to fix.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Clearly if someone doesn't know
>>>>>> what all the potential discrepancies are there is no way they
>>>>>> could find and fix them.
>>>>>
>>>>> In practice even developer who has never read neither standards
>>>>> nor that [diff.iso] can do it.  There always are at least some
>>>>> tests.  If test fails there is capability to figure it out why
>>>>> it fails.  Once that capability has been applied to fix an issue
>>>>> also knowledge is obtained how to search for similar from
>>>>> untested parts of code.
>>>>
>>>> Testing can be used to show the presence of errors, but
>>>> never their absence.  The code may seem to work even
>>>> when bugs are still lurking.
>>>>
>>>> Also, if a test fails, there is no guarantee we can track
>>>> down what caused the failure in any reasonably limited
>>>> amount of time.  This is especially true when we don't
>>>> know what it is we're looking for.
>>>
>>> Yes, but so what?  Writing code that can be compiled to produce
>>> close enough to be useful result on both C and C++ compilers is
>>> in practice about as difficult as to write code that produces
>>> close enough to be useful result on both clang and msvc.
>>>
>>> All programmers are usual humans and therefore fallible and so
>>> absence of errors in programs (including said compilers)
>>> is about as expensive (and about as unneeded) to achieve as
>>> collecting all berries of certain type from forest.
>>>
>>> It is just fact ... and that fact is easy to verify by looking at
>>> issue management systems of every large open source project that
>>> is happily used by millions of people.  Lot of defects manifest as
>>> errors long time after these were introduced into code since these
>>> affect only tiny subset of users and even them very rarely.
>>>
>>> The idea of software development is to produce programs that
>>> are useful and help some people in something, not defect-free
>>> programs.  That is also written so in license agreement of
>>> majority of software.
>>
>> The claim under discussion is two-fold (my wording, but I am
>> trying to be consistent with what Keith Thompson said above):
>>
>>   (1) Any well-formed C program can be transformed into an
>>       equivalent well-formed C program that is also a
>>       well-formed, and equivalent, C++ program;  and
>>
>>   (2) For almost all "real-world" programs, to use Keith's
>>       phrasing, such transformations can be effected with
>>       a small effort.
>>
>> AFAICT your comments don't speak to either of these criteria.
>
> That depends on interpretation of these words.  It is possible
> that I misinterpreted something there.
>
>> You seem to be arguing that it is possible, with some unspecified
>> amount of effort, to produce useful (even if not necessarily
>> equivalent) programs.  What I'm talking about is only the
>> question of producing equivalent programs, and whether they can
>> be produced with a small effort.  Do you see the difference
>> between that question and your comments above?
>
> You seem to ignore fact that very close to all "real world" programs
> are defective and so the equivalence isn't (and can't be) mathematical.

Of course it can be.  There are lots of ways to transform a
program into a different program that has identical semantics,
whether or not the original program has defects.  The transformed
program will then have exactly the same defects as the original.
Example:  this declaration

    int x = 1;

has exactly the same semantics as the transformed declaration

    int x = (int) 1;

assuming of course there is no preprocessor funny business.


> Instead "equivalent" means "as useful for its usages".

I am using "equivalent" to mean "having exactly the same
semantics", which is also what I think Keith Thompson meant.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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

csiph-web