From owner-freebsd-chat Wed Mar 6 9:47:26 2002 Delivered-To: freebsd-chat@freebsd.org Received: from tepid.osl.fast.no (tepid.osl.fast.no [213.188.9.130]) by hub.freebsd.org (Postfix) with ESMTP id 8666737B400 for ; Wed, 6 Mar 2002 09:47:20 -0800 (PST) Received: from raw.grenland.fast.no.fast.no (raw.grenland.fast.no [192.168.48.104]) by tepid.osl.fast.no (8.9.3/8.9.1) with ESMTP id SAA13408; Wed, 6 Mar 2002 18:47:06 +0100 (CET) (envelope-from Raymond.Wiker@fast.no) From: Raymond Wiker MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15494.22039.581536.624619@raw.grenland.fast.no> Date: Wed, 6 Mar 2002 18:47:03 +0100 To: nate@yogotech.com (Nate Williams) Cc: Raymond Wiker , Giorgos Keramidas , Terry Lambert , "Steve B." , freebsd-chat@FreeBSD.ORG Subject: Re: C vs C++ In-Reply-To: <15494.20631.682803.383406@caddis.yogotech.com> 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> X-Mailer: VM 7.00 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Nate Williams writes: > [ 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. > > 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 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. Further, if you don't use the advanced features of C++, you may just as well stick to to C. > 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. > > 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 - certainly no more than the intricacies std::string, std::stream and the standard comtainer are to the average C++ programmer. 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. They end up with something that has lower quality than the standard classes, is underdocumented, underfeatured and probably inefficient. > 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. 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. > > 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. 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. Note: I don't actually like C++, but I find that it gets better if I can actually use the high-level features of the language. //Raymond. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message