Date: Sat, 22 Apr 2006 12:09:30 -0700 From: Don Dugger <dugger@hotlz.com> To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, freebsd-chat@freebsd.org Subject: Re: Why is not more FreeBSD software written in C++? Message-ID: <444A7F6A.4050206@hotlz.com> In-Reply-To: <86zmido6m7.fsf@xps.des.no> References: <200604221603.k3MG3rmI003382@mist.nodomain> <444A64A3.2020208@hotlz.com> <86zmido6m7.fsf@xps.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smørgrav wrote: >Don Dugger <dugger@hotlz.com> writes: > > >>But "streams" have been around a lot longer then c++. I first encountered >>them in AIX protocol stacks. Didn't like 'em then either. >> >> > >SysV streams and C++ I/O streams are completely unrelated (except that >they both originated at AT&T and one probably inspired the other) > > > >>Although the idea of pushing functional units down a pipe does seem >>interesting, however I have never found it works very well in >>practice, and the reason was always performance. >> >> > >No "functional units" are being "pushed down the pipe" with C++ I/O >streams. The << stuff is mere syntactic sugar. What happens is >simply that the correct function is called to format each element and >pass it to the output stream. > > > Ok you don't like my way of describing it. Functional units lined up one after the other or however you prefer. The point is that they both use the word streams and that's what both of them are about functional units which pass information form one to the other. My point was that I do believe that the one inspired the other. If you know this not to be the case please enlighten me. >>I think the problem is in fact is a general problem the more under >>lying functionality you have the less performance. >> >> > >Wrong. Higher-level constructs allow the compiler more latitude to >optimize the code. This is why well-written Lisp, for instance, can >outperform well-written C (provided you use a decent Lisp compiler). > > > Wait are trying to say that it not true that doing more takes more time. While I will agree that higher-level constructs can lead to better optimization. I stand by the statement, doing more stuff takes more time. >>If you need to you can us >> >>e the c lib stuff and only use the c++ >>added functionality when it pays to. After all some of the c++ stuff >>is just better, "//" comments and passing by reference and etc. >> >> > >// comments are neither better nor worse than /* */ comments, and they >have been available in C for seven years now. > > That's pure opinion and one that I haven't head. >C++ references are very nice, but almost impossible for a non-expert >to use properly (any object passed by reference *must* be of a class >which has a correctly designed copy constructor) > > That doesn't make foo(int& i) very hard to use. And come on you seem to be capable, writing a copy constructor isn't that bad and when your done you have done just as much moving of the data as you need, if you leave that up to a compiler it may not be what you want. Of course there are time when your not concerned about performance but I thought that's what we there talking about. Look writing good code takes work and if you think that's going away by a better language get in line they been try for 50 years and so far what see is what we've got. > > >>I think the reason streams was added to c++ early on was that a lot >>of people didn't like printf(), the found it hard to use, which I >>never understood. >> >> > >Nobody claims printf() is hard to understand, but it is neither >extensible nor type-safe. > > > And how many times have I seen "<<" simply impl'd as a printf(), how does that change anything. The tact is the first time someone told me about c++ they there telling how they didn't have to use that printf() thing any more, as if it was a life changing thing. I don't think it's hard to use and I agree that it has major draw back and you only mention two. I just don't like iostreams and I happen to agree that there performance is bad. >What C++ lacks to be a top-notch OO language is garbage collection and >iterators which aren't a PITA to use. Both will be present in C++0x. > >DES > > I'm not sure I follow that statement, however lisp is not a replacement the c++ and OO is not the only way to go and in many cases is a very pour way to go. While I like it for a lot of reasons I don't think that it's the answer to all the problem that come along. Hey I like lisp too but there's times it just not the right language for the job. Don 8)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?444A7F6A.4050206>