From owner-freebsd-hackers Tue Mar 5 9:39:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 5F01B37B416 for ; Tue, 5 Mar 2002 09:39:17 -0800 (PST) Received: from pool0452.cvx40-bradley.dialup.earthlink.net ([216.244.43.197] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16iItz-0005mg-00; Tue, 05 Mar 2002 09:39:03 -0800 Message-ID: <3C8502A8.66C174D7@mindspring.com> Date: Tue, 05 Mar 2002 09:38:48 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Eugene L. Vorokov" Cc: freebsd-hackers@freebsd.org Subject: Re: C vs C++ References: <200203051407.g25E7Cd67446@bugz.infotecs.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "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