Date: Wed, 06 Mar 2002 15:38:40 -0600 From: Joe Halpin <joe.halpin@attbi.com> To: freebsd-chat@FreeBSD.ORG Subject: Re: C vs C++ Message-ID: <3C868C60.37E156BB@attbi.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 wrote: > > [ 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. One of the main points of iostreams is that the programmer has complete control over how the data for his class is diplayed. That's what inheritance is for. Or do you mean that you don't have complete control over how the data is displayed by a class that someone else wrote? If so, how do you get that with C (considering C doesn't have this concept at all)? Why should you have that? If I write a class, why should you have complete control over how it's displayed? Or do you have in mind the standard classes? If so, then you can always look at the standard to see what they output, which is what you'd have to do for printf(). No guessing, or source code needed. > 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. Can you provide an example of when this has to happen? I've been writing C++ for over ten years and I never had to do this. Even if you have to filter the output of another class, you can do that without having access to the base code. > > 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'll agree with you here. In my opinion, exceptions are a pain in the ass, a portability nightmare, and generally just a source of problems. > 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. I agree here as well. > > 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. What do you mean by random? C++ is defined by a standard that specifies how the standard I/O streams work, what they do, etc. How is that random? If you mean that compilers haven't universally caught up with the standard yet, I'll buy that. Joe 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?3C868C60.37E156BB>