Hints on how to migrate from C++ to C

[Sune]

Hi!

I've been designing telecom applications in C++ for 8 years now
and I'm being fed up with parts of OO and C++.

To get going I would need a cross reference on how to replace
useful C++ features with their C equivalents. Since I'm quite C++
literate (and also lazy) this shortcut is needed to ever make it
happen, I think. A truly good tricks'n'hints doc would also do it
as long as what's suggested in it is somewhat accepted in the C
industry.

Something like:

C++ construct C counterpart
--------------- ----------------
Exceptions ...
Resource ownership ...

If too many 'useful' C++ constructs cannot be represented in C this
will also stop my migration.

I've got a decent knowledge of what is doable in C, but I haven't LIVED
with C as I have with C++, so my hope goes out to you guys!

Thanks in advance
/Sune

 

[Free Bird]

C++ construct C counterpart
--------------- ----------------
Exceptions ...

Three possibilities:
1) Returning an error code
2) Setting a global error variable
3) Raising a signal

Resource ownership ...

AFAICS, there are two possibilities:
1) The static keyword
2) Your own self-restraint

I hope that helps. Don't expect a seamless transition, though. If all C++
constructs could easily be translated to C without any loss of meaning than
we wouldn't need C++.

 

[Rouben Rostamian]

Hi!

I've been designing telecom applications in C++ for 8 years now
and I'm being fed up with parts of OO and C++.

To get going I would need a cross reference on how to replace
useful C++ features with their C equivalents. Since I'm quite C++
literate (and also lazy) this shortcut is needed to ever make it
happen, I think. A truly good tricks'n'hints doc would also do it
as long as what's suggested in it is somewhat accepted in the C
industry.

Something like:

C++ construct C counterpart
--------------- ----------------
Exceptions ...
Resource ownership ...

If too many 'useful' C++ constructs cannot be represented in C this
will also stop my migration.

The old saying goes: when in Rome, do as the Romans do. It is
counterproductive to move to a new language and try to preserve
your old idioms in the new language. A programming language
comes with its own philosophy and world-view. It's pointless
to coerce it to fit another language's world-view. If you try,
then at best you will be writing programs in one language that
speak with another language's accent.

My point is, don't look for a table of matching idioms in C
and C++. You may construct such a table, but it is the wrong
approach. Instead, immerse yourself in C and express your ideas
in accepted C paradigms. Don't carry over C++ paradigms to C.

That said, if you want to push C to talk with a slight C++ accent,
have look at "C Interfaces and Implementations" by David Hanson.

 

[Sune]

Rouben Rostamian skrev:

The old saying goes: when in Rome, do as the Romans do. It is
counterproductive to move to a new language and try to preserve
your old idioms in the new language. A programming language
comes with its own philosophy and world-view. It's pointless
to coerce it to fit another language's world-view. If you try,
then at best you will be writing programs in one language that
speak with another language's accent.

My point is, don't look for a table of matching idioms in C
and C++. You may construct such a table, but it is the wrong
approach. Instead, immerse yourself in C and express your ideas
in accepted C paradigms. Don't carry over C++ paradigms to C.

That said, if you want to push C to talk with a slight C++ accent,
have look at "C Interfaces and Implementations" by David Hanson.

Thanks for your viewpoint, but why would it be counter productive to
use the best of two worlds?

It's like saying:
- Either drink milk or coffe, DO NOT put milk in your coffe, that's
counter productive!

Just trying to keep an open mind...

 

[Alan Balmer]

It's like saying:
- Either drink milk or coffe, DO NOT put milk in your coffe, that's
counter productive!

If you have two consumers, one who can't drink milk and the other who
can't drink coffee, you've ruined it for both of them.

 

[Sune]

Why does a mix of milk and coffe make consumers allergic???

Cows can't jump - Confucius

 

[Martin Ambuhl]

Cows can't jump - Confucius

I have grepped my copy of _Lunyu_ and cannot find any such statement.
Do you have a citation for that?

 

[John Bode]

Hi!
[snip]

C++ construct C counterpart
--------------- ----------------
Exceptions ...
Resource ownership ...

Off the top of my head:

C++ C
---------- ------------
classes no equivalent
inheritance no equivalent
exceptions signal/raise,
setjmp/longjmp
iostreams stdio (*scanf(),
*printf(), read(),
write(), fgetc(),
fputc(), etc.)
polymorphism no equivalent
(variadic functions
DO NOT count)
templates no equivalent
operator no equivalent
overloading

 

[Sune]

Hi!

I totally appreciate your effort, thanks.

2 clarifications:
- I guess with your exception approach there will be some
additional work compared with C++, possible recursive call
unwinding etc?
- What can I implement in terms of resource ownership? Is
there a way, I'm totally C from now on.

BRs
/Olle

 

[tedu]

C++ C
---------- ------------
classes no equivalent
inheritance no equivalent

Structs with function pointers come close.

 

[Malcolm]

[ C++ like C ]
Thanks for your viewpoint, but why would it be counter productive to
use the best of two worlds?

It's like saying:
- Either drink milk or coffe, DO NOT put milk in your coffe, that's
counter productive!

Sometimes you can take a good idea from another programming language, and
use it in your own. Generally, however, the good idea requires some support
that the other language doesn't have.
For instance C++ exceptions are arguably such a good idea, and can be faked
up in C somehow. However C offers no mechanism for automatically freeing
objects called by malloc(), so you cannot unwind the stack. This makes any
attempt to implement exceptions in C very difficult and error prone. So in
fact you are better off using error return codes to indicate error
conditions in C code.

 

[Keith Thompson]

I totally appreciate your effort, thanks.

2 clarifications:
- I guess with your exception approach there will be some
additional work compared with C++, possible recursive call
unwinding etc?
- What can I implement in terms of resource ownership? Is
there a way, I'm totally C from now on.

Can you clarify what you mean by "resource ownership"?

If you need some of the features that C++ provides and C doesn't, but
you dislike some aspects of C++, you can always just program in a
subset of C++. Use the features you like, and ignore the ones you
don't. (Though ignoring features isn't necessarily easy.)

C90 is very nearly a subset of C++. If you write code that's
basically C-like except that it uses C++ exceptions, for example, you
can compile it with a C++ compiler.

If you take this approach, you'll need to discuss it in comp.lang.c++.

 

[Old Wolf]

I've been designing telecom applications in C++ for 8 years now
and I'm being fed up with parts of OO and C++.

To get going I would need a cross reference on how to replace
useful C++ features with their C equivalents. Since I'm quite C++
literate (and also lazy) this shortcut is needed to ever make it
happen, I think. A truly good tricks'n'hints doc would also do it
as long as what's suggested in it is somewhat accepted in the C
industry.

Something like:

C++ construct C counterpart
--------------- ----------------
Exceptions ...

Return a value from the function, indicating success or failure.
The calling function tests this value and takes appropriate
action.

Resource ownership ...

Free the resource when you are finished with it.

It may be beneficial to register a function with atexit()
if your operating system isn't going to automatically clean
up resources when the program exits.

If too many 'useful' C++ constructs cannot be represented in C this
will also stop my migration.

Why are you migrating anyway. You suggest that you don't like
some aspects of C++ -- if so, then simply stop using those
aspects, and use its C-like aspects instead. That's got to
be simpler than a total rewrite.

 

[Sune]

Hi all,

your remarks and hints are all valid. They can be summed up as:

1) If you write code that's basically C-like except that it uses
C++ exceptions, for example, you can compile it with a C++
compiler.

2) Tweaks as those suggested will be error prone, don't use them.

1. IMHO C will stand the test of time better than C++ if the
current trends in C++ continues, mainly: STL suckage and
syntactic sugar rushes. This is the main reason I asked these
seemingly awkward questions.

2. I hoped for tweaks, even ugly ones, to be able to use a C
in a C++ like way in some situations. However this seems,
according to you and my newly adopted opinion, not to be
the case. (A few C++ constructs and idioms are very
powerful; this is why I hoped for 'clones' in C).

Conclusion
------------------------
I will implement my application in a procedural C-like manner,
using C++ (hopefully being able to restrain C++ a bit and thus
save it from itself).

Thanks for your time and input!

BRs
/Sune

 

[Richard Heathfield]

Hi!

I've been designing telecom applications in C++ for 8 years now
and I'm being fed up with parts of OO and C++.

To get going I would need a cross reference on how to replace
useful C++ features with their C equivalents.

No problem.

Since I'm quite C++
literate (and also lazy) this shortcut is needed to ever make it
happen, I think.

Here's the whole thing: use a C compiler instead of a C++ compiler, and fix
all the resulting error messages. That will probably sort out 99% of your
problems.

Something like:

C++ construct C counterpart
--------------- ----------------
Exceptions ...

return errorcode;

Resource ownership ...

/* this bit's MINE! */

If too many 'useful' C++ constructs cannot be represented in C this
will also stop my migration.

If C++ constructs were all that useful, you wouldn't be moaning about them.

I've got a decent knowledge of what is doable in C, but I haven't LIVED
with C as I have with C++, so my hope goes out to you guys!

The door is open. Just bring your things in and find a desk. The water
cooler is over there in the corner.

 

[Richard Bos]

I have grepped my copy of _Lunyu_ and cannot find any such statement.
Do you have a citation for that?

Confucius say "Conficius say more in English than in Chinese".

Richard

 

[Alan Balmer]

Confucius say "Conficius say more in English than in Chinese".

Richard

He was ahead of his time.

 

[John Bode]

Structs with function pointers come close.

For sufficiently distant values of "close".

 

[Roger Leigh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

C++ construct C counterpart
--------------- ----------------
Exceptions ...

There are mechanisms for propagating errors back up the call stack in
C. Here's one of them:

http://developer.gnome.org/doc/API/2.0/glib/glib-Error-Reporting.html

And here's an example of its use:

http://cvs.alioth.debian.org/cgi-bi...ype=text/x-cvsweb-markup&cvsroot=buildd-tools
http://cvs.alioth.debian.org/cgi-bi...ype=text/x-cvsweb-markup&cvsroot=buildd-tools

In the header, all the ERROR enums and macros are the error codes for
the SBUILD_AUTH_ERROR error domain (equivalent to a derived exception
class, but perhaps a little more useful in practice). In the source,
sbuild_auth_run() shows how errors may be propagated up the call
stack; all the preceding functions may "throw" (propagate) an error.

This method is rather more "manual" than C++ exceptions, but in
practice is mostly equivalent. It has the advantage that you can't
have an unhandled exception abort the application unexpectedly because
all the error propagation is explicit, and because it's passed on the
stack, it's part of the function signature.

Here's where that object's exceptions are caught at the top-level:
http://cvs.alioth.debian.org/cgi-bi...ype=text/x-cvsweb-markup&cvsroot=buildd-tools
(10 lines from the bottom).


Regards,
Roger

- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFC6US0VcFcaSW/uEgRAj45AJ4wnLUySEtj5S5Q37sCYZKwDFoY8wCcDK5y
FEKq2sBcc2amrR9z/dmANsc=
=bO/l
-----END PGP SIGNATURE-----

 

[Rob Thorpe]

Hi all,

your remarks and hints are all valid. They can be summed up as:

1) If you write code that's basically C-like except that it uses
C++ exceptions, for example, you can compile it with a C++
compiler.

2) Tweaks as those suggested will be error prone, don't use them.

1. IMHO C will stand the test of time better than C++ if the
current trends in C++ continues, mainly: STL suckage and
syntactic sugar rushes. This is the main reason I asked these
seemingly awkward questions.

2. I hoped for tweaks, even ugly ones, to be able to use a C
in a C++ like way in some situations. However this seems,
according to you and my newly adopted opinion, not to be
the case. (A few C++ constructs and idioms are very
powerful; this is why I hoped for 'clones' in C).

Conclusion
------------------------
I will implement my application in a procedural C-like manner,
using C++ (hopefully being able to restrain C++ a bit and thus
save it from itself).

Thanks for your time and input!

One more thing:

Many people, myself included, think that exceptions are overused.
Their purpose should be to treat truely exceptional situations..

A good program is one that never uses exceptions. They should be a
port of final call if an error cannot be propagated through the program
in a more structured way.