«

On Jun 13, 4:14 am, Bit Byte <r...@yourbox.com> 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.
>
> Is there anything I need to be aware of (i.e. any hidden dangers etc) ?

Apparently sizeof has an actually different meaning in C++. I have
not run into a case where I needed to investigate this myself as of
yet.

If you started with C99 code, you might have things declared as
complex (though I recognize the probability of this is basically zero)
which is apparently incompatible with the C++ support for complex, and
apparently there is a direct syntax clash.

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

No, default ctors for structs are to do exactly what C does today
which is nothing.

One of the main differences is that C++ is more type strict, in
particular void * is its own type and is not compatible with other
pointer types -- you have to explicitly cast them to the types you are
intending to use them as before accepting a coercion. It also forces
you to be more exact in function declarations. This I found to be the
biggest actual source code impact, as it basically forces you to cast
all mallocs.

In C sometimes you could get away with declaring the prototype with no
parameters, then the implementation and call sites with some specific
parameters, which can lead to a kind of tricky way of doing
polymorphic parameter passing -- I think this fails in C++, because C+
+ needs to know the exact type of the function at time it is declared.

Other than that, usually you just find that C++ has stricter warnings.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Paul Hsieh <> writes:
> On Jun 13, 4:14 am, Bit Byte <r...@yourbox.com> 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.
>>
>> Is there anything I need to be aware of (i.e. any hidden dangers etc) ?
>
> Apparently sizeof has an actually different meaning in C++. I have
> not run into a case where I needed to investigate this myself as of
> yet.

No, sizeof means the same thing; it yields the size in bytes of its
operand.

Some operands may have different sizes in C than in C++; for example,
sizeof 'x'
yields sizeof(int) in C and 1 (sizeof(char)) in C++. But that's a
difference in the meaning of 'x', not in the meaning of sizeof.

[...]

> One of the main differences is that C++ is more type strict, in
> particular void * is its own type and is not compatible with other
> pointer types -- you have to explicitly cast them to the types you are
> intending to use them as before accepting a coercion.

More or less. But void* is a distinct type in C. The difference is
that C permits implicit conversions to and from void* in more cases
than C++ does.

> It also forces
> you to be more exact in function declarations. This I found to be the
> biggest actual source code impact, as it basically forces you to cast
> all mallocs.

Right (but it's usually better practice to use new and delete in C++
anyway, or some STL type that manages memory for you).

> In C sometimes you could get away with declaring the prototype with no
> parameters, then the implementation and call sites with some specific
> parameters, which can lead to a kind of tricky way of doing
> polymorphic parameter passing -- I think this fails in C++, because C+
> + needs to know the exact type of the function at time it is declared.
>
> Other than that, usually you just find that C++ has stricter warnings.

At least a couple of people have posted pointers to good sources of
information about the incompatibilities between C and C++.

--
Keith Thompson (The_Other_Keith) kst- <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"

On 14 Jun 2008 at 2:56, Paul Hsieh wrote:
> Apparently sizeof has an actually different meaning in C++. I have
> not run into a case where I needed to investigate this myself as of
> yet.

$ cat a.c
#include <stdio.h>

struct A {
};

int main(void)
{
printf("%d\n", sizeof(struct A));
return 0;
}

$ gcc -o a a.c
$ ./a
0
$ g++ -o a a.c
$ ./a
1

Antoninus Twink wrote:
> On 14 Jun 2008 at 2:56, Paul Hsieh wrote:
>> Apparently sizeof has an actually different meaning in C++. I have
>> not run into a case where I needed to investigate this myself as of
>> yet.
>
> $ cat a.c
> #include <stdio.h>
>
> struct A {
> };
>
> int main(void)
> {
> printf("%d\n", sizeof(struct A));
> return 0;
> }
>
> $ gcc -o a a.c
> $ ./a
> 0
> $ g++ -o a a.c
> $ ./a
> 1
>
Well what do you expect if you compare a construct which is illegal in C?

gcc a.c -Wall -ansi -pedantic
/tmp/a.c:4: warning: struct has no members

c99 a.c
"a.c", line 4: zero-sized struct/union
c99: acomp failed for /tmp/a.c

--
Ian Collins.

On Jun 14, 5:15 am, Keith Thompson <ks...@mib.org> wrote:
> Paul Hsieh <websn...@gmail.com> writes:
> > On Jun 13, 4:14 am, Bit Byte <r...@yourbox.com> 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.

> >> Is there anything I need to be aware of (i.e. any hidden
> >> dangers etc) ?

> > Apparently sizeof has an actually different meaning in C++.
> > I have not run into a case where I needed to investigate
> > this myself as of yet.

> No, sizeof means the same thing; it yields the size in bytes
> of its operand.

In C++, sizeof is guaranteed to be a compile time constant; this
isn't the case in C99. (In other words, sizeof in C++ is the
same as sizeof in C90.)

> [...]
> > It also forces
> > you to be more exact in function declarations. This I found to be the
> > biggest actual source code impact, as it basically forces you to cast
> > all mallocs.

> Right (but it's usually better practice to use new and delete in C++
> anyway, or some STL type that manages memory for you).

Never the less, this is typically the issue which requires the
most modification when trying to compile C with a C++ compiler.
(Actually, when I did this with my own libraries, something like
18 years ago, the largest single problem was that I had more
than a few variables named "class".)

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

On Jun 14, 12:14 pm, Antoninus Twink <nos...@nospam.invalid> wrote:
> On 14 Jun 2008 at 2:56, Paul Hsieh wrote:

> > Apparently sizeof has an actually different meaning in C++.
> > I have not run into a case where I needed to investigate
> > this myself as of yet.

> $ cat a.c
> #include <stdio.h>

> struct A {
> };

> int main(void)
> {
> printf("%d\n", sizeof(struct A));
> return 0;
> }

> $ gcc -o a a.c
> $ ./a
> 0
> $ g++ -o a a.c
> $ ./a
> 1

That looks like a bug in gcc to me. C doesn't allow struct's
with no members. (Like C++, C also doesn't allow zero sized
objects. For the same reason: pointer arithmetic.)

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

On Jun 13, 8:15 pm, Keith Thompson <ks...@mib.org> wrote:
> Paul Hsieh <websn...@gmail.com> writes:
> > It also forces
> > you to be more exact in function declarations. This I found to be
> > the biggest actual source code impact, as it basically forces you
> > to cast all mallocs.
>
> Right (but it's usually better practice to use new and delete in C++
> anyway, or some STL type that manages memory for you).

C++ is built on the RAII principle. Using new and delete invoke
constructors which you might not want to happen. Furthermore, its
easy to show that STL's vector templates have either ridiculously bad
performance in comparison to hand managed realloc()'s precisely
because of the RAII overhead or else compromise your design to the
point that you might as well use realloc().

I.e., its not surprising that malloc/free has not been and will not be
deprecated in the C++.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Paul Hsieh wrote:
> On Jun 13, 8:15 pm, Keith Thompson <ks...@mib.org> wrote:
>> Paul Hsieh <websn...@gmail.com> writes:
>>> It also forces
>>> you to be more exact in function declarations. This I found to be
>>> the biggest actual source code impact, as it basically forces you
>>> to cast all mallocs.
>> Right (but it's usually better practice to use new and delete in C++
>> anyway, or some STL type that manages memory for you).
>
> C++ is built on the RAII principle.

Is it?

> Using new and delete invoke
> constructors which you might not want to happen. Furthermore, its
> easy to show that STL's vector templates have either ridiculously bad
> performance in comparison to hand managed realloc()'s precisely
> because of the RAII overhead or else compromise your design to the
> point that you might as well use realloc().
>
Care to demonstrate?

--
Ian Collins.

Paul Hsieh wrote:
> On Jun 13, 8:15 pm, Keith Thompson <ks...@mib.org> wrote:
>> Paul Hsieh <websn...@gmail.com> writes:
>>> It also
>>> forces you to be more exact in function declarations. This I
>>> found to be the biggest actual source code impact, as it
>>> basically forces you to cast all mallocs.
>>
>> Right (but it's usually better practice to use new and delete in
>> C++ anyway, or some STL type that manages memory for you).
>
> C++ is built on the RAII principle. Using new and delete invoke
> constructors which you might not want to happen. Furthermore, its
> easy to show that STL's vector templates have either ridiculously
> bad performance in comparison to hand managed realloc()'s precisely
> because of the RAII overhead or else compromise your design to the
> point that you might as well use realloc().

Constructors are invoked for types that have constructors. How do you
do that with realloc?

>
> I.e., its not surprising that malloc/free has not been and will not
> be deprecated in the C++.

Is it?


Bo Persson

On Jun 16, 12:10 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> Paul Hsieh wrote:
> > On Jun 13, 8:15 pm, Keith Thompson <ks...@mib.org> wrote:
> >> Paul Hsieh <websn...@gmail.com> writes:
> >>> It also forces
> >>> you to be more exact in function declarations. This I found to be
> >>> the biggest actual source code impact, as it basically forces you
> >>> to cast all mallocs.
> >> Right (but it's usually better practice to use new and delete in C++
> >> anyway, or some STL type that manages memory for you).
>
> > C++ is built on the RAII principle.
>
> Is it?

All struct or class declarations invoke whatever the default
constructor it has. Furthermore any class with a constructor must
invoke a constructor at the time of declaration. That's basically
what RAII is -- a method of synchronizing allocation and
initialization.

> > Using new and delete invoke
> > constructors which you might not want to happen. Furthermore, its
> > easy to show that STL's vector templates have either ridiculously bad
> > performance in comparison to hand managed realloc()'s precisely
> > because of the RAII overhead or else compromise your design to the
> > point that you might as well use realloc().
>
> Care to demonstrate?

Sure. Lets make a class of mail messages. Note that its impossible
to have an empty mail message (because there is always at least a
header), hence a mail message can only be initialized based on some
input text stream or string; there is no well defined concept of a
default mail message constructor. Further it makes very little sense
to mutate a mail message by changing its contents after the fact. So
its a well motivated read-only class without an empty or default
constructor.

Now lets say you want to have a dynamic vector of mail messages (this
is exactly what you would expect a deserialized mailbox essentially to
be). The implementation of STL vectors require that the class have a
default constructor if the vector is modified (which it would be as a
result of incrementally reading the mailbox).

There are numerous work arounds to this such as creating a wrapper
class which does have an empty constructor which hides a pointer to a
mail message class that starts out NULL. But individual new()s to
each one is still going to take extra overhead (performance + memory)
so you would prefer to point into a memory pool of your own which you
maintain with malloc() or realloc() anyways, in which case you have
not saved or improved anything by using these C++ constructs.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/