Re: Slightly OT: Compilation question

Discussion in 'C++' started by Martin Ambuhl, Jun 13, 2008.

  1. Bit Byte wrote:
    > I have some legacy C code that I intend to port over (eventually) to
    > C++. As a first step, I am thinking of renaming all of the *.c files to
    > *.cpp, so I can benefit from the "more strict" C++ compilation.


    You will get more strict compilation if the code is intended to be C++.
    You will get broken and incorrect translation in the code is intended
    to be C.
    >
    > Is there anything I need to be aware of (i.e. any hidden dangers etc) ?


    Yes. C and C++ are different languages with different syntax and
    different semantics. Treating C code as if it were C++ is asking for
    trouble.

    > - I am thinking specifically about things like default ctors (perhaps)
    > being generated by the compiler for things structs etc ... (not sure if
    > this would pose a problem in it self, but I simply want to make sure I
    > have not overlooked anything ...


    If your target is a language other than C (such as C++), you probably
    should do a real rewrite. The code you have may have taken advantage of
    features of C which have semantic differences in C; it may have taken
    advantage of features specific to its original environment not
    guaranteed to work even with C. And if there is any point at all in
    your plan to move it to C++, it for sure takes advantage of _none_ of
    the possible reasons you might have for doing so. Unless you are
    willing to do a rewrite taking advantage of real differences between C
    and C++, a plan to move to C++ just looks like adecade-late exercise in
    fad-following.
    Martin Ambuhl, Jun 13, 2008
    #1
    1. Advertising

  2. Martin Ambuhl

    James Kanze Guest

    On Jun 14, 12:55 am, Martin Ambuhl <> wrote:
    > Yes. C and C++ are different languages with different syntax and
    > different semantics. Treating C code as if it were C++ is asking for
    > trouble.


    That's interesting, because Kernighan and Richie claim that you
    can compile all of the programs in their book on C with a C++
    compiler, and still get the same semantics.

    In practice, I find that the first step when moving code from C
    to C++ is to compile it, unchanged, with a C++ compiler. You'll
    usually get a certain number of errors (e.g. because the results
    of malloc weren't cast to the target type, or you had a variable
    named class), but I've yet to see a case where the code
    compiled, but had different observable behavior. (I know how to
    artificially create such cases, but I've never actually seen one
    in practice.)

    > > - I am thinking specifically about things like default ctors
    > > (perhaps) being generated by the compiler for things structs
    > > etc ... (not sure if this would pose a problem in it self,
    > > but I simply want to make sure I have not overlooked
    > > anything ...


    > If your target is a language other than C (such as C++), you
    > probably should do a real rewrite.


    Sooner or later. Otherwise, there's not much point in
    migrating. But you don't necessarily have to do it immediately.

    > The code you have may have taken advantage of features of C
    > which have semantic differences in C; it may have taken
    > advantage of features specific to its original environment not
    > guaranteed to work even with C. And if there is any point at
    > all in your plan to move it to C++, it for sure takes
    > advantage of _none_ of the possible reasons you might have for
    > doing so. Unless you are willing to do a rewrite taking
    > advantage of real differences between C and C++, a plan to
    > move to C++ just looks like adecade-late exercise in
    > fad-following.


    More likely, he has to add some new features, and wants to
    implement them in C++. If the original C is reasonably well
    written (and you can write clean code in C), then it shouldn't
    be necessary to rewrite all of a module just to add an
    additional argument (of class type) to one function.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jun 14, 2008
    #2
    1. Advertising

  3. >>>>> "JK" == James Kanze <> writes:

    JK> On Jun 14, 12:55 am, Martin Ambuhl <> wrote:

    >> Yes. C and C++ are different languages with different syntax and
    >> different semantics. Treating C code as if it were C++ is asking
    >> for trouble.


    JK> That's interesting, because Kernighan and Richie claim that you
    JK> can compile all of the programs in their book on C with a C++
    JK> compiler, and still get the same semantics.

    That claim was made in 1988, before C was standardized; it was likely
    true at the time. C and C++ have changed since, and C++ had standards
    released in 1998 and 2003; it is fairly evident that the claim no longer
    holds.

    Charlton


    --
    Charlton Wilbur
    Charlton Wilbur, Jun 15, 2008
    #3
  4. James Kanze wrote:
    > On Jun 14, 12:55 am, Martin Ambuhl <> wrote:
    >> Yes. C and C++ are different languages with different syntax and
    >> different semantics. Treating C code as if it were C++ is asking for
    >> trouble.

    >
    > That's interesting, because Kernighan and Richie claim that you
    > can compile all of the programs in their book on C with a C++
    > compiler, and still get the same semantics.


    Neither C nor C++ had a standard at that time. Using this citation is
    bogus and anyone who knows enough to quote it knows that it is bogus.
    This somehow leads me to question your good faith.
    Martin Ambuhl, Jun 15, 2008
    #4
  5. Martin Ambuhl

    James Kanze Guest

    On Jun 15, 5:04 am, Charlton Wilbur <> wrote:
    > >>>>> "JK" == James Kanze <> writes:


    > JK> On Jun 14, 12:55 am, Martin Ambuhl <> wrote:


    > >> Yes. C and C++ are different languages with different syntax and
    > >> different semantics. Treating C code as if it were C++ is asking
    > >> for trouble.


    > JK> That's interesting, because Kernighan and Richie claim that you
    > JK> can compile all of the programs in their book on C with a C++
    > JK> compiler, and still get the same semantics.


    > That claim was made in 1988, before C was standardized; it was
    > likely true at the time. C and C++ have changed since, and
    > C++ had standards released in 1998 and 2003; it is fairly
    > evident that the claim no longer holds.


    Is it? What doesn't compile with a C++ in K&R2? (I know that
    C++ has grown considerably since then, but the basic object
    model is still more or less unchanged, and I can't think of
    any change off-hand which would cause a problem with C code.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jun 15, 2008
    #5
  6. Martin Ambuhl

    James Kanze Guest

    On Jun 15, 8:41 am, Martin Ambuhl <> wrote:
    > James Kanze wrote:
    > > On Jun 14, 12:55 am, Martin Ambuhl <> wrote:
    > >> Yes. C and C++ are different languages with different syntax and
    > >> different semantics. Treating C code as if it were C++ is asking for
    > >> trouble.


    > > That's interesting, because Kernighan and Richie claim that
    > > you can compile all of the programs in their book on C with
    > > a C++ compiler, and still get the same semantics.


    > Neither C nor C++ had a standard at that time. Using this
    > citation is bogus and anyone who knows enough to quote it
    > knows that it is bogus. This somehow leads me to question
    > your good faith.


    Can you cite some examples which wouldn't compile using a C++
    compiler? I know that even recently, I've had to compile C
    using a C++ compiler, and it's not caused undue problems: the
    lack of a cast on the return value of malloc() being the main
    one (and Kernighan and Richie have always claimed that the cast
    should be used in well written C as well, or at least, that's
    what I've been told by people who worked with them).

    The fact is that you made a blatantly false claim.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jun 15, 2008
    #6
  7. James Kanze <> writes:
    [...]
    > Can you cite some examples which wouldn't compile using a C++
    > compiler? I know that even recently, I've had to compile C
    > using a C++ compiler, and it's not caused undue problems: the
    > lack of a cast on the return value of malloc() being the main
    > one (and Kernighan and Richie have always claimed that the cast
    > should be used in well written C as well, or at least, that's
    > what I've been told by people who worked with them).

    [...]

    The errata list for K&R2, at
    <http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>, says:

    142(6.5, toward the end): The remark about casting the return
    value of malloc ("the proper method is to declare ... then
    explicitly coerce") needs to be rewritten. The example is correct
    and works, but the advice is debatable in the context of the
    1988-1989 ANSI/ISO standards. It's not necessary (given that
    coercion of void * to ALMOSTANYTYPE * is automatic), and possibly
    harmful if malloc, or a proxy for it, fails to be declared as
    returning void *. The explicit cast can cover up an unintended
    error. On the other hand, pre-ANSI, the cast was necessary, and it
    is in C++ also.

    As for your actual question (whether any examples in K&R2 won't
    compile with a C++ compiler), I don't know, but I note that the C++
    standard draft says that the C standard headers such as <stdio.h> (as
    opposed to <cstdio>) are deprecated, meaning that they're required by
    the current standard but not guaranteed to be part of future
    standards. I think the current C++ standard says the same thing.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 15, 2008
    #7
  8. Martin Ambuhl

    James Kanze Guest

    On Jun 15, 5:08 pm, Keith Thompson <> wrote:
    > James Kanze <> writes:


    > [...]> Can you cite some examples which wouldn't compile using a C++
    > > compiler? I know that even recently, I've had to compile C
    > > using a C++ compiler, and it's not caused undue problems: the
    > > lack of a cast on the return value of malloc() being the main
    > > one (and Kernighan and Richie have always claimed that the cast
    > > should be used in well written C as well, or at least, that's
    > > what I've been told by people who worked with them).


    > [...]


    > The errata list for K&R2, at
    > <http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html>, says:


    > 142(6.5, toward the end): The remark about casting the return
    > value of malloc ("the proper method is to declare ... then
    > explicitly coerce") needs to be rewritten. The example is correct
    > and works, but the advice is debatable in the context of the
    > 1988-1989 ANSI/ISO standards. It's not necessary (given that
    > coercion of void * to ALMOSTANYTYPE * is automatic), and possibly
    > harmful if malloc, or a proxy for it, fails to be declared as
    > returning void *. The explicit cast can cover up an unintended
    > error. On the other hand, pre-ANSI, the cast was necessary, and it
    > is in C++ also.


    Yes. I think what K&R didn't like was the automatic conversion
    of void* to any other pointer type.

    It's interesting to note that when C++ first appeared, it did
    two things with respect to C: it extended it, and it fixed a
    number of "errors" in the language. Most of the error fixes
    have been back ported to C (things like function prototypes, the
    void type, etc.), but for some reason, the replacement of
    malloc/free by new/delete never made it.

    > As for your actual question (whether any examples in K&R2
    > won't compile with a C++ compiler), I don't know, but I note
    > that the C++ standard draft says that the C standard headers
    > such as <stdio.h> (as opposed to <cstdio>) are deprecated,
    > meaning that they're required by the current standard but not
    > guaranteed to be part of future standards. I think the
    > current C++ standard says the same thing.


    Probably. On the other hand, deprecated or not, they are still
    part of the standard, and they're not going to disappear.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jun 15, 2008
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Martin Ambuhl

    Re: Slightly OT: Compilation question

    Martin Ambuhl, Jun 13, 2008, in forum: C Programming
    Replies:
    7
    Views:
    289
    James Kanze
    Jun 15, 2008
  2. Paul Hsieh
    Replies:
    16
    Views:
    525
    James Kanze
    Jun 18, 2008
  3. Paul Hsieh

    Re: Slightly OT: Compilation question

    Paul Hsieh, Jun 14, 2008, in forum: C Programming
    Replies:
    18
    Views:
    454
    James Kanze
    Jun 18, 2008
  4. Tomás Ó hÉilidhe

    Re: Slightly OT: Compilation question

    Tomás Ó hÉilidhe, Jun 14, 2008, in forum: C++
    Replies:
    4
    Views:
    264
    Richard
    Jun 15, 2008
  5. Tomás Ó hÉilidhe

    Re: Slightly OT: Compilation question

    Tomás Ó hÉilidhe, Jun 14, 2008, in forum: C Programming
    Replies:
    4
    Views:
    256
    Richard
    Jun 15, 2008
Loading...

Share This Page