Old Wolf said:
What do you mean by "converted to C++" exactly ?
Renaming .c files to .cpp and changing malloc to new,
is a great way to produce unmaintainable code.
Oh believe me when I tell you, this code I'm maintaining
was plenty "unmaintainable" as a C program, and continues
to be equally "unmaintainable" as a C++ program. Which
makes maintaining it loads of <sarcasm>fun</sarcasm>.
I didn't change any malloc to new. There weren't any,
actually. Lots of GlobalAlloc(), which is the Windows
version of the same thing. I left those alone.
The reasons I converted the program to C++ were two:
1. To get the much stronger typing of MS-VC++ 6's C++
compiler, in place of the weak typing of it's C compiler.
(Which involved fixing about 5000 compiler errors and
10000 linker errors after the switch, due to the author's
mind-boglingly sloppy handling of data types.)
2. To allow use of the C++ STL, especially maps and deques.
(We were adding features that needed maps of structs,
keyed by ints, where the structs contained deques. Doing
that in C would have been unwieldy, but in C++, it was
a breeze.)
It's probably too late now
Waaaaaaay too late.
but IMHO it is better to leave C files as C and write new
stuff as C++ (and link the two together, which is simple)
Why? See above under "stronger typing". After converting
to C++ and fixing the many thousands of compiler and linker
errors which immediately cropped up, my co-workers and I
found that many of the bugs which customers and field-service
reps had be complaining about over the years mysteriously
vanished overnight. The key was, taking the time to figure
out why each data-type conflict was occuring, and to try to
solve it at its source, rather than bandaid it with a
typecast, which is a good way to hide bugs rather than fixing
them.
I agree that if you have a WELL-WRITTEN C program, and
want to add C++ stuff to it (STL, containers, algorithms,
templates, classes, polymorphism, whatever), it's best to
leave the C files alone, and write the new stuff as separate
C++ files and just link 'm in. (Taking measures to ensure
stuff links right, of course, which involves heavy use of
"extern C" among other things.)
However, this particular C program was NOT well-written,
so converting the whole #! to C++ actually helped.
until you are ready to fully re-write a particular unit as
good C++.
That's not going to happen in the life of this program.
The money's not there. The bosses want bug fixes and new
features, not re-factoring.
I wrote about the possible use of the "non-local for vars"
in the program, and my fear of breaking such uses, and
Old Wolf replied:
Then you would get compiler errors in every place that
relied on the non-standard behaviour, and you could quickly
fix it all.
Maybe, maybe not. As you later admited in the same post:
However a more subtle problem is:
int foo()
{
int mimsy = 3;
if ( bar() )
{
for (int mimsy = 0; mimsy != 5; ++mimsy)
qux();
return mimsy;
}
}
where the behaviour would silently change with this 'fix'.
Which is exactly why I'm not going to impliment MS's
recommended fix globally. Like I say, I may use it
in some individual files with few for statements, where
I can clearly see it won't break anything.
Perhaps you could set your compiler to generate assembly
output, then make the fix and do a diff on the generated
assembly. You'd need to be heavily optimising of course,
so that it skips out the extra "if..else" .
Unless one knows i386 assembly rather well, I don't
see how that would help. Two versions of a C++ program
that generate different assembly outputs may be functionally
different... or they may be functionally the same. I don't
know assembly language well enough to tell the difference.
I'd be squinting, mumbling "PUSH here, POP there, MOV here,
ADD there, and what's this NOP doing? Oh, right, nothing...
Um... HELP!!!" No, I think I'll stick to C++.
--
Cheers!
Robbie Hatley
Tustin, CA, USA
email: lonewolfintj at pacbell dot net
web: home dot pacbell dot net slant earnur slant
