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

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

Re: Improving C and C++ header compatibility

Show all headers | View raw

On 09/04/2011 08:25, Richard Smith wrote:
>
> On Apr 7, 8:29 am, Ian Collins<ian-n...@hotmail.com>  wrote:
>> On 04/ 3/11 03:24 AM, Richard Smith wrote:
>>
>>> On Mar 29, 8:07 pm, Ian Collins<ian-n...@hotmail.com>   wrote:
>>
>> Francis address the first point.
>
> He certainly raised some interesting points, but he didn't address my
> basic point which was that _Bool should be a C++ keyword.

Why? A macro fixes any problem there might be.
   C and C++
> cope sharing the name 'int' between them, despite their not being a
> formal guarantee that the types are the same.
>
>
>>>>> [...]  This means adding
>>>>> another MYLIBRARY_RESTRICT macro as restrict is not permitted in C++.

WG21 did not leave out restrict through lack of thought. It was a
consensus opinion that restrict does not deliver and that if it were in
the language it would be defined as doing nothing. If the languages are
going to be incompatible why should we hide it by including a
meaningless keyword?

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

Sure, YOUR ENVIRONMENT not the C++ Standard.

>>
>>> I'm not sure I understand what you're saying.  Consider the following
>>> header:
>>
>> What I'm saying is I misunderstood your point!  Checking my system
>> (Solaris) headers, they have
>>
>> #if (defined(__STDC__)&&  defined(_STDC_C99))
>> #define _RESTRICT_KYWD  restrict
>> #else
>> #define _RESTRICT_KYWD
>> #endif
>>
>> Which is similar to what you proposed.
>
> And the system headers on the machine I'm using to type this define
> __restrict for this purpose.  But that's not standardised so it's of
> no help.  I don't care what the system headers do internally as
> there's rarely any reason for me to read them.
>
> I do, however, care that whether possible to easily write C library
> headers that work as C++.  These macros are no use for that.  Sure, if
> I *only* want to compile on Solaris, I can use _RESTRICT_KYWD.

What exactly is wrong with
#define restrict

In a C++ implementation? It would be wrong in C because you should not
be ~defining a keyword, but fine in C++ where it isn't a keyword.
> (Though do they document the feature and guarantee that the next
> update won't alter it's spelling?).  But that's absolutely no use in
> writing portable library headers.  Once again, we're back to requiring
> a MYLIBRARY_RESTRICT macro, and experience suggests that library
> authors will only use macros that uglify their code if they serves an
> important purpose.  To many C programmers, C++ compatibility is not
> that important.  But nevertheless, C++ programmers rely fairly heavily
> on the fact that C library headers do just work in C++.  The
> divergence of C and C++ due to _Bool and restrict will start to hamper
> that goal.

C made the decision to have _Bool AFTER C++ had had bool for over 5
years for reasons related to legacy code. How sure are you that making
_Bool a keyword in C++ will not break any C++ code?

restrict is a different issue. Where both languages have the same
keyword it should do the same thing (and with the fundamental types that
is true though both languages allow implementation defined sizes). User
defined types (struct and enum, and in C++ class) have some subtle
differences. BTW why not yell at C for not making class a keyword.
Compatibility isn't a one way street and getting as close as we have has
been hard work and involved many hours of thought and discussion led by
a group of people who are well familiar with both languages and have a
real interest in compatibility.

>
>
>>>> 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.
>>
>> May be, but special cases are not something that is standardised.
>
> With respect, I think you perhaps need to re-read what I proposed as I
> *didn't* propose that __declspec((dllimport)) is standardised.  What I
> said was:
>
> || C)  Add a non-normative note paragraph to 7.5 [dcl.link]
> encouraging
> || vendors that support other linkage-like options, such as
> || __declspec(dllimport), to extend the compound linkage specification
> || grammar to allow them on the extern "Lang" blocks, e.g. extern
> || __declspec(dllimport) "C" { ... }.  There's precedent for giving
> || guidance such as this in the standard, for example in
> || [lib.iterator.traits] guidance on __far pointers is given.
>
> That's not standardising anything.  It is encouraging implementers to
> adopt a common and less verbose strategy to providing extensions of
> this nature.  In fact, thinking further, a better approach might be to
> allow an attribute-specifier-seq on the the extern "LANG" block, e.g.:
>
>   extern "C++" [[__declspec(dllimport)]] { ... }
>
> And in that case, it would involve a minor change to the grammar.  But
> either way, the important points are (i) that nothing specific to the
> Windows DLL model would be standardised, (ii) the syntax is much less
> verbose than needed at present because one attribute applies to
> multiple functions, (iii) DLL importing and calling convention
> overrides (think __cdecl) are the most common example of this, and an
> (non-normative) example using one or both of those should be given.

I am not sure where you are going on this issue. There is a deep and
fundamental difference between Windows and Unix with dynamic libraries.
A group of very experienced people spent time looking at this to see if
there was any way that C++ could support both as part of the Standard.
Other issues became more pressing so it was abandoned
>
>
>>> 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.

FOFL are you an active C programmer? There is a large section of that
community that is still deeply antagonistic to C99 and legacy C code is
likely to be around for many years more.


>
> The whole point of my email was in making it easy to write clean,
> portable C/C++ code.

There is no such beast. There is a subset of C that can be used cleanly
as C++ and WG14 and WG21 have co-operated to try to keep that as large
as possible whilst not prejudicing the language they are responsible for.

We have always known that writing compatible code is hard work. Making
it appear easier than it actually is will do no-one any favours. It will
just result in subtle, hard to detect bugs.

Note that we already have too many people who think that they can link a
C library to C++ just be using extern "C" and the headers. Strictly
speaking you cannot even do that in C. Nonetheless most implementations
happily link potentially incompatible code and most of the time it works.



   That was possible in C90/C++98, but the failure
> of C++ to support some of the new constructs in C99 is hampering
> that.  (And I'm not talking about more specialised constructs such as
> _Complex, although fixing to be fully interchangeable with
> std::complex<>  would be nice; nor am I talking about VLAs, as such
> things rarely occur in headers.)

And there you have a fundamental design issue. C has to add fundamental
types because it has no mechanism for adding true first class user
defined types. C++ only adds a fundamental type when that is essential
(e.g. bool where the comparison operators need to use it)

>
> I don't subscribe to be view that macros are evil and must be avoided,
> but frequent use of them rapidly makes code hard to understand.  But
> equally, if the common subset of the languages supported by the
> compilers you care about doesn't include the functionality you want,
> macros are essential to ensure portability.  Which leads to a choice:
> either you can write portable C/C++ code or you can write clean C/C++
> code.  The fact that the standards force you to that choice, even for
> a construct as simple as a boolean type, seems to me to be
> fundamentally misguided.

If you want to safely mix and match languages without much effort you
need far more support from the implementations than either language can
specify.

Make restrict a keyword in C++ and provide it with the same semantics as
in C99 (if we could actually determine what those are -- my C colleagues
are far from in agreement about this) and every C++ implementation would
have to add that complexity to already overworked compilers. Far better,
IMHO, to leave it out until such time as people can agree as to what it
should and can do. Do not waste time telling me what you think it does.
I know what was intended, but I also no that the reality is much less
and it makes promises that cannot always be kept.

Francis


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