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

Groups > comp.std.c++ > #87

Re: Improving C and C++ header compatibility

Show all headers | View raw

[Again, my first reply to this hasn't reached the newsgroup.]

On Mar 29, 8:07 pm, Ian Collins <ian-n...@hotmail.com> wrote:

> >   #if __cplusplus
> >   #define MYLIBRARY_BOOL bool
> >   #else
> >   #define MYLIBRARY_BOOL _Bool
> >   #endif
>
> Is there a compatibility guarantee between C's _Bool and C++'s bool?  I
> prefer to play save and use an int return from shared functions.

That's an interesting question.

So far as I can see, there's no guarantee that C's _Bool and C++'s
bool are the same.  But, so far as I can see, nor is there a guarantee
that C's short and C++'s short are the same.  For all the other built-
in types, there are standard C library functions that take those types
as arguments, and the guarantee that the C library is callable from C+
+ effectively guarantees that the types are compatible in C and C++.
At present, the C library does not contain any functions that use
_Bool or short so that implicit guarantee doesn't exist for those
types.  (The printf functions with, say, "%hd" pass the short down an
ellipsis which results in integer promotion so that doesn't count.)

That said, I'm really struggling to see why an implementation might
have incompatible boolean types for C and for C++.  For example, I'm
not aware of any requirements imposed by either language that might
require stronger alignment or padding guarantees in one language
compared to the other.

And it seems clear that the C standard committee intended them to be
compatible, otherwise C99 wouldn't have provided the macro called
'bool', when it could easily have called it something else, such as
'boolean'.  Likewise the C++ standard committee seems unlikely to have
adopted <cstdbool> in C++0x if it had intended there to be a
possibility of the types being incompatible.  Finally, if C1x is
published with a <stdatomic.h> containing an atomic_is_lock_free
generic function that returns _Bool (as the current draft does) which
is semantically identical to C++0x's <atomic> function template of the
same name, and if a future C++ standard (or TR) includes C1x's
<stdatomic.h> by reference into the C++ standard library, then that
will implicitly guarantee that the types are compatible.

So I think that for all practical purposes they can be assumed to be
compatible.

> 4)  In C, the restrict keyword (might) allow the compiler to make
>
> > better more assumptions about the two arguments and therefore optimise
> > it better; it also potentially allows for a compiler warning if the
> > same argument is supplied for both parameters.  So far as I'm
> > concerned, the jury's still out as to whether this really does make a
> > significant improvement, but it's reasonable to assume a library
> > author might want to add it to the function.  This means adding
> > another MYLIBRARY_RESTRICT macro as restrict is not permitted in C++.
>
> You shouldn't have to do this.  Your environment should take care of this
> for you.  Consider the system and C standard libraries which use restrict.

I'm not sure I understand what you're saying.  Consider the following
header:

   #ifndef FOO_INCLUDED
   #define FOO_INCLUDED
   void foo( char const* restrict, ... );
   #endif

This could be a C99 header which uses 'restrict' as a keyword, or a C+
+ (or C90) header which uses 'restrict' as a parameter name.  How does
the compiler know which is intended?  Off the top of my head, I'm not
aware of any compilers that support a mechanism (say a #pragma) that
tells the compiler what language (or dialect) the file is written in;
even if such a mechanism does exist in a particular compiler, it's
certainly not general practice to use it.  Nor does the the name of
the file give a clue as to the language, as it's fairly common
practice to use filenames like "foo.h" for both languages.  So, no, I
cannot see how this is can generally be taken care of by my
development environment.

> 6)  Finally, we may need some platform-specific code to make shared
>
> > libraries work, for example, on Window's we're likely to want to place
> > __declspec(dllimport) before each declaration in the header.  This
> > needs wrapping in a macros, say MYLIBRARY_API, so that it's only used
> > in the appropriate places.
>
> This isn't a general problem (it certainly isn't on Unix and Unix like
> systems).

So?

It may only be a minority of systems that require such things, but the
Windows DLL model is an important special case.  If I'm developing a
library, I will often want it to run on as many different systems as
possible, and that will very often include Windows, and frequently in
Windows built as a DLL.  Take a look at the Boost headers for
libraries such as Interprocess, Graph, Thread or Signals, or the
libxml2 or Xerces headers, or the QT graphics libraries or the Curl
library, or any of dozens of others.  They all do it.  Try grepping
through /usr/include on a typical Unix box.  You may be surprised at
how common it is.

But it means that any good, portable library, whether written in C or C
++, needs to put declarations like __declspec(dllimport) on every non-
inline function.  Unlike extern "C" which can be put once at the
beginning of the file and then forgotten, the same does not apply with
__declspec(dllimport), and so you need an otherwise-unnecessary macro
on every single function declaration.


> > Any thoughts?  The changes are all minimal and unlikely to break
> > anything.  It's too late now for C++0x, sadly,  but they certainly
> > seem worth considering for the next version (or a TR if there's an
> > appropriate one).
>
> The only real language smell is boolean compatibility and declaration.
> Assuming _Bool and bool are compatible, this really boils down to the C
> problem of mixing C99 and C95 code.

No.  It's completely different.  Mixing C99 with earlier versions of C
is a temporary problem.  At some point you decide to abandon support
for earlier versions of C.  At the moment, it may still makes sense to
assume that not all compilers support _Bool, in which case a
MYLIBRARY_BOOL macro that expands to either _Bool or int makes sense.
But once the library authors decide they no longer care about pre-C99
compilers, the MYLIBRARY_BOOL macro no longer has a use in C.  And in
my experience, C programmers are *far* more likely to care about
supporting old dialects of C than they are to support C++.  So once
MYLIBRARY_BOOL no longer has a use for C compatibility, it will
frequently vanish, breaking C++; the same applies to
MYLIBRARY_RESTRICT.

By contrast, the problem of compatibility between C and C++ will not
go away.  One of C++'s biggest strengths is that it just use C
libraries without additional effort.  I can't see how it is possibly
in C++'s interests to lose that compatibility, so it's important that C
++ continues to co-evolve with C so that almost all C headers continue
to just work in C++.

Richard Smith


-- 
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

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

Thread

Re: Improving C and C++ header compatibility Ian Collins <ian-news@hotmail.com> - 2011-03-29 13:07 -0600
  Re: Improving C and C++ header compatibility Richard Smith <richard@ex-parrot.com> - 2011-04-02 09:24 -0600
    Re: Improving C and C++ header compatibility  Francis Glassborow <francis.glassborow@btinternet.com> - 2011-04-03 09:28 -0600
    Re: Improving C and C++ header compatibility  Ian Collins <ian-news@hotmail.com> - 2011-04-07 01:29 -0600
      Re: Improving C and C++ header compatibility  Richard Smith <richard@ex-parrot.com> - 2011-04-09 01:25 -0600
        Re: Improving C and C++ header compatibility  Francis Glassborow <francis.glassborow@btinternet.com> - 2011-04-09 10:17 -0600

csiph-web