Re: Slightly OT: Compilation question
 

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.

Re: Slightly OT: Compilation question
 

On Jun 14, 12:55 am, Martin Ambuhl <mamb...@earthlink.net> 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:james.kanze@gmail.com
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

Re: Slightly OT: Compilation question
 

>>>>> "JK" == James Kanze <james.kanze@gmail.com> writes:

JK> On Jun 14, 12:55 am, Martin Ambuhl <mamb...@earthlink.net> 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
cwilbur@chromatico.net

Re: Slightly OT: Compilation question
 

James Kanze wrote:
> On Jun 14, 12:55 am, Martin Ambuhl <mamb...@earthlink.net> 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.

Re: Slightly OT: Compilation question
 

On Jun 15, 5:04 am, Charlton Wilbur <cwil...@chromatico.net> wrote:
> >>>>> "JK" == James Kanze <james.ka...@gmail.com> writes:

> JK> On Jun 14, 12:55 am, Martin Ambuhl <mamb...@earthlink.net> 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:james.kanze@gmail.com
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

Re: Slightly OT: Compilation question
 

On Jun 15, 8:41 am, Martin Ambuhl <mamb...@earthlink.net> wrote:
> James Kanze wrote:
> > On Jun 14, 12:55 am, Martin Ambuhl <mamb...@earthlink.net> 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:james.kanze@gmail.com
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

Re: Slightly OT: Compilation question
 

James Kanze <james.kanze@gmail.com> 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) kst-u@mib.org <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"

Re: Slightly OT: Compilation question
 

On Jun 15, 5:08 pm, Keith Thompson <ks...@mib.org> wrote:
> James Kanze <james.ka...@gmail.com> 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:james.kanze@gmail.com
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