Date: Wed, 6 Mar 2002 11:16:46 -0700 From: Nate Williams <nate@yogotech.com> To: Raymond Wiker <Raymond.Wiker@fast.no> Cc: nate@yogotech.com (Nate Williams), 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.23822.972400.759310@caddis.yogotech.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> > [ 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.
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 <sstream>), 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15494.23822.972400.759310>