Tuesday, May 5, 2020

Digest for comp.lang.c++@googlegroups.com - 8 updates in 5 topics

Tim Rentsch <tr.17687@z991.linuxsc.com>: May 05 03:21PM -0700

> amount of code has been written that either accidentally or
> intentionally depends upon that fact. As a result, such a change
> would probably break a fair amount of existing code.
 
I'm skeptical of the hypothesis that there is a lot of code
inside 'extern "C" { ... }' blocks that relies on C++ semantics.
If the code is in a header that is #include'd by both C++
compilations and C compilations, either: one, the code has the
same meaning in both languages; two, the code compiles as C++
but does not compile as C; or, three, the code compiles both as
C and as C++, but has different semantics in the two languages,
in which case the code is broken anyway. (I am ruling out the
case where someone writes such code deliberately, knowing that
the meaning is different in the two languages, perhaps for a
putative "Obfuscated C/C++ Contest". There is no good reason
to support such abuses.) So either the code continues to work
as before or it was broken to begin with.
 
If the code is not in a header but in a file that is compiled
only by C++ compilers, there seems very little reason to have
large swaths of code inside 'extern "C" { ... }' brackets. But if
there are such cases, they are easy to identify, and simple to
adjust so they continue to work as desired. Moreover the result
is very likely better structured, following the principle that
semantic-changing contexts be kept as small as possible.
 
> semantics".
 
> If the C++ standard were modified as you describe, how could such
> code be re-written?
 
Come on James. Put on your thinking cap. It is quite straightforward
to write a function that is C callable but whose definition is written
under C++ rules. In fact I would be surprised if it weren't the most
common way of writing C++ callins. First we write a header that
declares the interface (disclaimer: not compiled):
 
// This file is "fantastic-functions.h"
 
#ifdef __cplusplus
extern "C" {

No comments: