Is necessary to switch to C++ or some object-oriented language?

[Ian Collins]

Agreed on all counts - different interpretations of "minor". The list
of differences is small, and each of them is minor. It is possible to
turn valid C code into valid C++ code with a few minor modifications;
that is, it is incredibly unlikely to need any redesign, almost all
the changes would be little more than editorial, and there usually
wouldn't be that many of them. That doesn't mean that C code can be
compiled as C++ code, or that it's a minor job to take a real-world C
program and do the minimal work required to make it a valid C++
program.

I've only had to do this once and it was tedious but not too hard. I
certainly wouldn't do it unless the cost was justified.

If you want to use the common subset, do it from day 1.

 

[Richard Bos]

I don't see how that's relevant to the question. If the minor
exceptions are widely used, there'll obviously be problems compiling.

If they're widely used, I wouldn't call them minor. Some people would
say that the differences between a monkey's genome and a human's are
minor; but the differences between the resulting money and human
definitely aren't.

Richard

 

[Default User]

If they're widely used, I wouldn't call them minor. Some people would
say that the differences between a monkey's genome and a human's are
minor; but the differences between the resulting money and human
definitely aren't.

The common set of C and C++ is pretty broad and useful if one has some
reason to use it. I haven't personally ever needed it.

As far as porting from one language to another, C->C++ is one of the
easiest to do. For the most part, the programs will be broadly
structured correctly, and most the standard headers are acceptable
(except possibly C99 ones) although they should probably be updated to
the C++ replacements at some point. Additionally the C89 standard
library is available.

It can also be a non-trivial job to port some C89 programs to C99. I'm
in the process of modernizing my old text-adventure game, and one of
the tools I used was to run files through a C++ compiler. That
pinpointed all the implicit ints, undeclared functions, and K&R
function defintions that were still hanging around in the code.



Brian

 

[user923005]

The common set of C and C++ is pretty broad and useful if one has some
reason to use it. I haven't personally ever needed it.

As far as porting from one language to another, C->C++ is one of the
easiest to do. For the most part, the programs will be broadly
structured correctly, and most the standard headers are acceptable
(except possibly C99 ones) although they should probably be updated to
the C++ replacements at some point. Additionally the C89 standard
library is available.

It can also be a non-trivial job to port some C89 programs to C99. I'm
in the process of modernizing my old text-adventure game, and one of
the tools I used was to run files through a C++ compiler. That
pinpointed all the implicit ints, undeclared functions, and K&R
function defintions that were still hanging around in the code.

It can also be fairly difficult to port from C to C++ (if that was
never the intention of the original authors).
I had a notion to try with PostgreSQL, but soon realized that hundreds
(thousands?) of hours were at stake and abandoned it.
We did the first (that I know of) port of PostgreSQL to Win32 several
years ago and we usually convert everything to C++ here, but that one
was a no-go.
The current version of PostgreSQL has some of our code in it.

 

[Malcolm McLean]

It can also be fairly difficult to port from C to C++ (if that was
never the intention of the original authors).
I had a notion to try with PostgreSQL, but soon realized that hundreds
(thousands?) of hours were at stake and abandoned it.
We did the first (that I know of) port of PostgreSQL to Win32 several
years ago and we usually convert everything to C++ here, but that one
was a no-go.
The current version of PostgreSQL has some of our code in it.

I am sure that a C++ izer would find a ready market if anyone can be
bothered to hack into a C compiler to write one.

 

[J. J. Farrell]

If they're widely used, I wouldn't call them minor. Some people would
say that the differences between a monkey's genome and a human's are
minor; but the differences between the resulting money and human
definitely aren't.

You're confusing the differences with their impacts. The exceptions
are few and minor, but that shouldn't be taken to imply that they have
little impact. The difference between driving on the left and driving
on the right is minor; the effect of ignoring the difference is not.

 

[David Thompson]

I've just spent the last three days translating a Fortran 77 routine to C.
It was a long routine. The C version will probably run slower, but it will
be easier to try out different algorithms to speed it up, and it can take
inputs of arbitrary size. F77 doesn't have a malloc().

F77 doesn't, but F>=90 has dynamic allocation of arrays and strings
(and F03 also of scalars including structures) that can handle most of
the things you would need malloc() for, and is mostly upward
compatible: F90 is strictly compatible with _Standard_ F77, F95 (and
F03) also except for a few minor things that were bad style anyway,
and F90/95 contains new features than can replace many of the things
that often needed (and used) nonStandard extensions in F<=77.

And I have not verified it myself, but according to the folks in
c.l.fortran all commercial compilers still supported are upgraded to
at least F95 (most are working on F03), and for free-software folks
there are TWO active projects doing F95 for GCC, both of which are now
close enough to handle most things and probably all old code.

This doesn't mean you shouldn't rewrite (or write) in C if you want
(for values of you that may include your boss/client/etc.) just that
needing dynamic allocation is not by itself sufficient reason.