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

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

Re: Improving C and C++ header compatibility

Show all headers | View raw

On 03/23/11 08:30 AM, Richard Smith wrote:

>
> [Resent after 80+ hours.]
>
> It's quite common to want to write a header for a library written in C
> that can be used from both C and C++.  Conceptually, this is quite
> straightforward, but in practice it usually seems to get needlessly
> messy.  I think it would be easy to make a very few minor and safe
> changes to C++ that would make this process a lot cleaner.
>
> Let's take a very simple example.  I have a function that acts as
> strncpy except that it returns true if it copied up to a null
> character on the source string, and false if it stopped because the
> the destination buffer was false.  This might have the signature:
>
>   bool my_strncpy( char const* src, char* dst, size_t n );
>
> Let's look at what's needed to turn this into a reasonable quality C/C
> +
> + header.  It starts off easily enough:
>
> 1)  Include guards.  Easy enough: the same syntax works in both
> languages.
>
> 2)  Include a header for size_t.  Again, easy enough: the<stddef.h>
> header does this in both languages, and avoids any complications that
> might (in theory if not in practice) exist with<cstddef>  putting it
> in the std namespace.
>
> But now things start getting messy:
>
> 3)  In C, we need a header for bool.  In principle, this is easy:
> <stdbool.h>  does the right thing in C and is (nearly) a no-op in C++.
> But in practice, it's bad practice to include<stdbool.h>  from a
> library header in C.  It's not uncommon to find programs originally
> written for C90 that have defined true, false and (more troublesomely)
> bool as integers.  The macros in<stdbool.h>  would break that.  The
> boolean keyword in C99 is spelt _Bool, and it's good practice to use
> this instead of the bool macro in a C header.  We're not allowed to
> define _Bool as a macro in C++ as it's a reserve word, so we're left
> either doing something like:
>
>   #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.

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.

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

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.

-- 
Ian Collins


[ 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 — 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