[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: C/C++ interoperability
- From: Philipp Janda <siffiejoe@...>
- Date: Thu, 22 Oct 2015 01:09:24 +0200
Am 21.10.2015 um 19:13 schröbte Viacheslav Usov:
On Wed, Oct 21, 2015 at 6:46 PM, Philipp Janda <firstname.lastname@example.org> wrote:
"Real C" for the scope of this thread is defined (by me) as code compiled
by a C compiler in contrast to an `extern "C"` function that is compiled by
a C++ compiler. E.g. gcc by default does "The Right Thing" (`-fexceptions`)
for C++ code, but not for C code. That's why I made the distinction. In
theory it isn't needed, because the behavior is undefined by the C++ and C
standards in both cases.
That is again not true. "Undefined behaviour" has a very specific meaning
in the current C++ standard (clause 1.3.24) and the passage quoted earlier
does not use that term.
Clause 1.3.24 says:
behavior for which this International Standard imposes no requirements
[ Note: Undefined behavior may be expected when this International
Standard omits any explicit definition of behavior or when a program
uses an erroneous construct or erroneous data. [...] ]
but I only have the draft standard, maybe they changed it for the final
Your definition of "Real C" misses the point,
because this area, as stated earlier, is implementation specific.
And I gave one popular specific implementation where that definition of
"Real C" is relevant.
sufficient for me that my implementation specifies a behaviour that is
suitable for my use. Whatever behaviour observed with your implementation
is immaterial to me.
You suggested "that this be incorporated into Lua's official source." So
this concerns more than just your implementation. That's the main reason
why I replied in the first place.