Date: Tue, 05 Mar 2002 09:38:48 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Eugene L. Vorokov" <vel@bugz.infotecs.ru> Cc: freebsd-hackers@freebsd.org Subject: Re: C vs C++ Message-ID: <3C8502A8.66C174D7@mindspring.com> References: <200203051407.g25E7Cd67446@bugz.infotecs.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
"Eugene L. Vorokov" wrote:
> I have a small problem. I work for software development company and
> write daemons and console tools for Unix. My boss wants everything
> to be written in C++, because he thinks C++ is cool. I prefer C
> for such tasks, but I cannot really put good arguments of why and
> where C++ can be worse than C. I know many of you prefer C too.
> Can you please explain some disadvantages of C++ comparing to C ?
> Is it slower, does it produce less effective code, why is it like
> that, etc ... or please direct me to some articles where this can
> be explained.
>
> I apologize for the offtopic whenever it happens, but this issue
> really pisses me off now.
One of the main disadvantages of C++ is that it requires self
discipline, and object oriented programming is harder to learn.
The other main disadvantage is that, if you use prototypes in
your code, you can simply compile C programs with a C++
compiler, and call the code "C++".
Another disadvantage is that you can reuse the code when you
are done with it, so you can't get paid for writing the same
code over and over again.
Inheritance compounds this problem, since it means that you
can't even rewrite mostly similar code over and over again,
since you end up inheriting everything from the base class
that was similar in the first place, and can only spend time
writing the parts that are different. This makes it really
hard to pad a contract properly, while allowing you to play
"Quake" for hours on end.
A really annoying thing about C++ is that you can't create an
uninitialized object; this makes it a lot harder to get the
good bugs.
A really really annoying thing is private vs. public, and
protected member data and functions. This makes it nearly
impossible to call the wrong function from the middle of
three routines up, or otherwise violate the API layering in
such a way as to simplify your code considerably, even if
it does break the abstration model. A good example of this
is the Microsoft PAP/CHAP PPP authentication. Everyone
knows that the layering violations they introduced are good
things, simplifying their life immensely, at the paltry cost
of all of your security. That's why the TCP-over-DNS hack
works to get you free internet connectivity using the MSN
800 number without having to log in. Imagine if they had
not violated the layering, and adhered to the silly "end
to end" requirements the IETF normally imposes on standards
on the Internet... why, there would be no free dialup
Internet connectivity at Microsoft's expense today! What a
poorer place this world would be!
Exceptions are really a pain; they make it nearly impossible
to obfuscate code with a huge number of:
if( condition) {
undo everything I did so far
return failure;
}
statements. They also lead to things like single-entry,
single-exit, which make it nigh impossible to hide things
from ASSERTs about whether or not things are locked (sure,
coders who are interested in working code instead of money
can do single-entry, single-exit in C, using underhanded
techniques like negative logic, but it's easy to convert
such code so as to hide it's true function). Probably
most unforgivably, they make you handle exceptional
conditions away from the main code path, which leaves no
room for order-of-magnitude improvements in gradual steps,
as you remove things from the common case later, and look
like a hero for doing the job you were paid to do in the
first place.
A royal pain is the fact that using pure virtual base
classes, which can't be properly instnaced without having
real member functions, means that you can't create e.g.
file system modules with unimplemented members like you
can with structs containing lists of function pointers,
so that you can later reap the rewards of NULL pointer
dereference related crashes.
Probably the absolute worst, most unforgivable attribute
if C++ is dynamic scoping, with automatic deconstruction;
it means that if I simply declare an instance of an object
as an auto variable on the stack, that when I leave the
scope the object is automatically deconstructed. This is
evil, in that it makes it impossible to be subtle about
leaking memory: no matter how you try to hide your memory
leaks, if you use this approach, they become glaringly
obvious. Worse, intentional leaks using "new" with no
corresponding "delete" stick out like a sore thumb, no
matter how you try to hide them.
About the only upside is that if you use pure virtual base
classes, or templates, such that a single class instance
needs to be constructed at runtime by the .init and then
deconstructed by the .fini at the end of the run, you
can't use the code in the kernel, because the startup
doesn't call these initializers for you, like the crt0
code calls it for user space programs, so you can avoid
using C++ in the kernel, if you gratuitously use these
constructs, and don't tell anyone why they won't work in
the kernel so that you can be told to avoid them.
Sorry the news isn't brighter, but the crusade against
C++ must go on!
Remember! Ad nihilus per aspera!
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8502A8.66C174D7>