From owner-freebsd-chat Wed Mar 6 10:18:34 2002 Delivered-To: freebsd-chat@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id B626737B405 for ; Wed, 6 Mar 2002 10:18:23 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA28891; Wed, 6 Mar 2002 11:16:47 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g26IGlI35044; Wed, 6 Mar 2002 11:16:47 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.23822.972400.759310@caddis.yogotech.com> Date: Wed, 6 Mar 2002 11:16:46 -0700 To: Raymond Wiker Cc: nate@yogotech.com (Nate Williams), Giorgos Keramidas , Terry Lambert , "Steve B." , freebsd-chat@FreeBSD.ORG Subject: Re: C vs C++ In-Reply-To: <15494.22039.581536.624619@raw.grenland.fast.no> References: <20020305132457.A4700-100000@alpha.yumyumyum.org> <001701c1c481$d0d5eab0$f642d9cf@DROID> <20020305231252.GC5328@hades.hell.gr> <3C8568E0.76415D99@mindspring.com> <20020306032029.GA7926@hades.hell.gr> <15494.13878.219807.949085@raw.grenland.fast.no> <15494.20631.682803.383406@caddis.yogotech.com> <15494.22039.581536.624619@raw.grenland.fast.no> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > [ Moving this thread over to -chat as well. We'll get them all over in time ] > > > > Raymond Wiker writes: > > > Giorgos Keramidas writes: > > > > Well, to be frank, I've seen a few C++ coding style documents, that suggest > > > > avoiding altogether when writing in C++. > > > > > > I assume you mean ? > > > > > Anyway, I *really* can't see any reason not to use , > > > , and friends. > > > > The fact that the programmer has no control over *how* the data is > > displayed, and relies on the person who wrote the class to display the > > data is one good reason. > > > > iostreams gives all the control the the person who writes the class, so > > in order to print things out, you have to extend the class (which often > > means peeking into it's private data, a violation of layering), or doing > > all sort of kludges/hacks to get things working. > > And exactly *how* is this helped by using printf instead? If > you want to have control of the output using printf, you *still* need > access to class members, including (possibly) protected data. Easy. class FP { public: FP() { _value = 0.0; } FP(double v) { _value = v; } float getValue() { return _value; } private: float _value; } int main() { FP f(1.0); printf("Value = %3.2f\n", f.getValue()); return 1; } However, for native data types (float, double, short, int, long, etc..), one rarely uses classes. > > > I also cannot see any reason not to use exceptions, the standard > > > containers, the string classes etc. > > > > Because exceptions are *still* not portable across multiple platforms. > > There are N different implementations of exceptions, 'standard > > containers', and all behave slightly different. > > I disagree with this. C++ compilers may not be up-to-date wrt > to the latest standard (e.g, g++ 2.95.x vs ), but this should > be a "transient" problem. It's not a transient problem when you can't use it *today*. Try using C++ exceptions on *any* released version of FreeBSD. Try using it on HP/UX. Try using it on AIX. Try using standard containers and see how they behave differently on different releases of Solaris. > It's certainly the case that if you don't > require your compiler vendor to comply with the standard, they don't > really have an incentive to provide these features. Bingo. If they aren't globally available, then they aren't a standard part of the language. > Further, if you don't use the advanced features of C++, you may just > as well stick to to C. Naw, it's still C++. All versions of C++ support inheritance, scoping protection, object initialization and teardown, as well as function/operator overloading. Of the above described features, only operator overloading tends to cause strange problems. Those above features make C++ 'safer' than C, but very few programmers use the above small-subset of available features. The tendency to point the gun at your foot (because I *can*) is too great. Face it, programmers as a lot have large egos, and who wants to admit that they're incapable of using a feature correctly? > > IMO, this is probably the biggest single stumbling block for using C++ > > extended features. Very few people know how to use these features > > correctly, and since they were so unportable, they are essentially > > unused except by those folks who worked very hard at using them, and as > > such have a higher clue-factor than most. > > They *aren't* that unportable. See above. I can only use the portably/safely on a single platform. (Windows). And, the compiler on that platform is so awful that I spent a large portion of my time trying to determine if it's an optimizer bug, or some strange interaction that I didn't complete think through in my C++ classes. > > > Used properly, these make it possible to write code that is > > > inherently safer than anything built around printf/scanf, char *, > > > longjump, etc. Without these (and a few others) you may just as well > > > stay with standard C. > > > > Safer? The intracacies of printf/scanf are *well* known, so I wouldn't > > say that it's any more/less safe. At least with the above functions, > > you *know* ahead of time the issues, vs. some random implementation of a > > class you don't want to look at. > > The intricacies of print/scanf may be *well* known, as you > say, but *not* to the average C programmer This I disagree with. Back when I learned C in college (late 80s), it wasn't as well known as it is now. However, even back then we discussed some of the pitfalls of scanf. With printf/scanf, at least you have only *one* set of routines to deal with. With streams, you have a bunch of different pitfalls that may vary from class to class. Simple *is* better. > Some people think that the standard string classes are to > inefficient, or too dissimilar from char *, so they end up writing > their own string classes. Or it may be that the standard string classes aren't nearly as helpful as they could be. They're getting better, but the 'better' versions aren't standardized. By the time C++ *finally* had a standard that was useful for the average programmer, the rest of the world had moved on. > > Exceptions are great, but there are too many gotchas because the > > behavior is not standardizes well enough to depend on them. (And, if > > you're not careful, you can cause yourself *all* sorts of problems using > > them.) > > I'd *really* like an example of this. Because they aren't completely standard, you can get different behavior depending on the implementation used. Heck, g++ supports two different types of exception handling, and one works better than the other. > The only serious > argument I've heard about exceptions in the last couple of years is > that they are inefficient, and even that is not a valid argument for > avoiding them completely. Agreed. I'm actually not against exceptions, except (;) for the fact that I can't use them safely. I *like* excptions. :) > > > Then again, if you want to do object-oriented programming, C++ > > > is probably not the right choice. If you want to use several different > > > paradigms simulataneously in one language, C++ may be a better fit - > > > although Common Lisp is a much better choice :-) > > > > Except that it's *obnoxiously* hard to deploy it. > > Not really - if you assume that you have equivalent > infrastructure for Common Lisp as for C++, Perl, Java etc, there is no > great difference. Been there, done that, ain't going there again. It's *OBNOXIOUSLY* hard to deploy it! > A comparison to Java is obviously not the last word. For > example, the last week or so a colleague and I have been struggling > with getting RW libraries to work on a couple of platforms. The RW > people, in their strictly limited wisdom, have decided to use an > interactive, graphical, Java-based abomination to build the > libraries. They should be shot, then hanged, then shot again. Just because it's cool/new doesn't mean it's appropriate. :) Java isn't *the* solution to everything either. Every tool has places where it's more appropriate. However, it doesn't mean that just because it'll work, it's necessarily appropriate. In the same manner, I'm not re-writing the software in my current project in Java, since it's in C++. It *could* all be re-written in Java, and I honestly believe it would run *faster*, and the design would allow for the kind of flexibility we're currently trying to shoe-horn into the system. However, it's not an appropriate use of resources, and we simply don't have the time to do it right. So, we keep plugging along with C++.... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message