Date: Wed, 6 Mar 2002 18:47:03 +0100 From: Raymond Wiker <Raymond.Wiker@fast.no> To: nate@yogotech.com (Nate Williams) Cc: Raymond Wiker <Raymond.Wiker@fast.no>, Giorgos Keramidas <keramida@ceid.upatras.gr>, Terry Lambert <tlambert2@mindspring.com>, "Steve B." <steveb99@earthlink.net>, freebsd-chat@FreeBSD.ORG Subject: Re: C vs C++ Message-ID: <15494.22039.581536.624619@raw.grenland.fast.no> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <stdout.h> altogether when writing in C++.
> >
> > I assume you mean <stdio.h>?
>
> > Anyway, I *really* can't see any reason not to use <iostream>,
> > <fstream>, <sstream> 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 <sstream>), 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15494.22039.581536.624619>