Re: why still use C?
From: Richard Heathfield (dontmail_at_address.co.uk.invalid)
Date: 10/27/03
- Next message: Sheldon Simms: "Re: Copying struct and unsigned char buffer"
- Previous message: Eric Sosman: "Re: Recursive Functions"
- In reply to: James Kuyper: "Re: why still use C?"
- Next in thread: James Kuyper: "Re: why still use C?"
- Reply: James Kuyper: "Re: why still use C?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 27 Oct 2003 18:37:06 +0000 (UTC)
James Kuyper wrote:
<snip>
> "Correct code for that implementation" is "correct code", for that
> implementation. The fact that it's not portable doesn't make it
> incorrect.
MMMV. :-)
<snip>
>> Thirdly and perhaps most importantly, I am
>> referring specifically to the construct:
>>
>> extern "C"
>> {
>> #include "c_header.h"
>> };
>>
>> where the header contains the usual (or what /ought/ to be usual) mixture
>> of comments, preprocessor directives, typedefs, and function prototypes.
>
> I didn't realize that you were restricting the scope of your comment
> that way.
That is entirely my fault, of course. I have a particular style which I
consider robust, and I all too easily fall into the trap of answering
questions w.r.t. "my" way of writing C.
> I agree with your list of reasonable contents for a header
> file, except that I would also include declarations of global
> variables. Global variables are often a sign of bad design, but not
> always, and as a practical matter it can take a long time to remove
> them from legacy code.
I think that to offer my opinion re global variables here would side-track
the discussion too much. :-)
> Since you're not talking about files containing function bodies, that
> reduces the likelihood of running into problems. Of course, any
> problem that can be created in code in a function body, can also be
> created by use of a macro defined in a header file, and expanding into
> such code when actually used.
Absolutely correct, and that's Yet Another Reason to avoid macros whenever
possible.
> However, even ignoring the possible problems with macros, there's
> other C/C++ problems that can occur even in a properly used header
> file. Any header which contains any of the following features can be a
> problem:
>
> 1. Declarations of identifiers matching C++ keywords that are not C
> keywords.
Funny you should say that, because I was considering that very problem (or
rather, the potential for it) earlier today, in Real Life. Hence this
reply, really. I must confess that I'm a bit of a fan of using C++ keywords
in C code; I must make a mental note not to do this in headers! (I don't
recall ever doing this, but then I don't recall not doing it, either.)
> 2. Tentative definitions.
>From my perspective that's Someone Else's Problem, but yes, it's a fair
point.
<some less common points snipped>
> 6. Storage class specifiers as part of the definition of a pure type;
> that is, a typedef, or a struct, union, or enumeration declaration
> that is not also the declaring any particular object of that type.
Could you possibly elaborate on this? What, specifically, is the problem
here?
> 7. A typedef with the same name as a struct tag.
This one may yet bite me, although in recent years I've got into the habit
of using a trailing underscore on the tag specifically to disambiguate it
(mainly for the benefit of Visual C++'s "go to definition" hotkey).
<a number of less common points snipped>
> 14. Any use of an enumeration. Different enumeration types can have
> different sizes and representations in C++, which would make virtually
> any use of them in a header file context dangerous.
I don't /think/ this is a problem for me, but thanks for the warning.
>
> I'll grant you, use of these features isn't very common, and many of
> these problems are guaranteed to produce diagnostics. However, they
> are things you need to worry about, beyond simply inserting extern
> "C".
Thank you for a most informative article, which I've saved for future
reference. As a result of reading it, I'm now far less convinced than I was
about the ease with which C code can be linked to C++ code. I'll have to
think about it, I guess.
-- Richard Heathfield : binary@eton.powernet.co.uk "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999. C FAQ: http://www.eskimo.com/~scs/C-faq/top.html K&R answers, C books, etc: http://users.powernet.co.uk/eton
- Next message: Sheldon Simms: "Re: Copying struct and unsigned char buffer"
- Previous message: Eric Sosman: "Re: Recursive Functions"
- In reply to: James Kuyper: "Re: why still use C?"
- Next in thread: James Kuyper: "Re: why still use C?"
- Reply: James Kuyper: "Re: why still use C?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
