From owner-freebsd-chat@FreeBSD.ORG Fri Apr 21 16:30:53 2006 Return-Path: X-Original-To: freebsd-chat@freebsd.org Delivered-To: freebsd-chat@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 610D616A402 for ; Fri, 21 Apr 2006 16:30:53 +0000 (UTC) (envelope-from dugger@hotlz.com) Received: from www.hotlz.com (freedom.hotlz.com [209.20.218.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id B22A643D48 for ; Fri, 21 Apr 2006 16:30:48 +0000 (GMT) (envelope-from dugger@hotlz.com) Received: from [172.27.240.45] (henry.local.hotlz.com [172.27.240.45]) by pilgrim.local.hotlz.com (8.13.3/8.13.3) with ESMTP id k3LGKnfs001399; Fri, 21 Apr 2006 09:20:49 -0700 (PDT) (envelope-from dugger@hotlz.com) Message-ID: <44490663.3040506@hotlz.com> Date: Fri, 21 Apr 2006 09:20:51 -0700 From: Don Dugger User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-chat@freebsd.org Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Dan Strick Subject: Re: Why is not more FreeBSD software written in C++? X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2006 16:30:53 -0000 The fact is that all your c code will compile in c++ and the c++ compiler may optimize better then the c compiler. When you use things like iostreams and string you get a lot of code that does a lot more then what you may need at time however it may save you a lot of time in the future when you need the functionality or there is a bug that they saved you from. But all of this need to be determine by the needs of the app. Some times speed is important other time security is and so on. C++ and c are a general purpose *compilers*. The fact is all the other languages I've seen talk about in this thread are not. C++ and C are languages that are defined by ANSI and the users have a great deal to say about what that definition is, many of the languages talked about are not (Ref Tip 59 of "The Pragmatic Programmer" Hunt & Thomas). As far as OOP and c++, there seem to be a myth out there that c++ is a OOP language, it's not, it a language which supports OOP. What I mean to say is that it is not design to only be used for OOP it designed to be general purpose. OOP is not aways best way to design an app just talk to the aspect guys. Many of the things that people find difficult about c++ are there in order to sure that the engineer using it is able to do as much as would with assembly language, which was one of c's original goals. Make no mistake about it you can write bad code in any language. C++ belong to us, the engineer and programmer that have to grind out code every day and I think it's better if we work to improve it rather and embracing a corporate own thing which will make us slaves to there whims. This is why I use FreeBSD. I disagree with the group more often then not but at leases I get a say based on merit not on money. About the original question I think the answer is that some of it is legacy and some is the authors feel more comfortable with good old c and feel that they will get more contributors. On the point of legacy code I have found that much of my old c code was easily converted to c++ just by changing the make file to c++. In many cases I was then able to use things like string and many of my c++ libs. I was surprised at how easy it was. Just the ramblings of an over worked software engineer.. Don 8) Benjamin Lutz wrote: >On Sunday 16 April 2006 12:33, Dan Strick wrote: > > >>I really like C++ but I am not sure how to deal with the performance problems. They are not so trivial that they can always be ignored. I have done a few casual benchmarks. Code that uses C++ strings can run up to 100 times slower than functionally equivalent code that uses C character arrays (though such an extreme case is surely pathological). Code that uses C++ iostreams typically runs >>somewhere between 2 and 9 times slower than code that uses C stdio. >> >>You don't believe me? Compare >> cout << ' '; >>to >> putchar(' '); >>and weep. >> >>Of course most programs presumably spend only a small part of their runtime on strings and i/o. I wish I could say the the advantages of C++ are so great as to outweigh any possible performance glitch, but I can't quite bring myself to do that. >> >> > >The example above is not exactly a realworld example. Even if you stick to plain C, a repeated putchar(' ') is 1-2 orders of magnitude slower than aggregating those characters and write()'ing them every few dozen chars. > >I'm not sure that I/O routine efficiency is really that relevant. I can't think of any program I use whose I/O routines are CPU bound. Ok, I guess if we look at really weak or embedded devices, say, those Soekris net4501 boards, I/O CPU efficiency will make a difference. > >The advantages of the iostream framework are clear though, you can do things like > > cout << some_complicated_data_structure_object; > >even if you don't know what the class of the object you're dealing with is. > > > >>Programs written in a good C++ style naturally use C++ standard library facilities (classes, private functions, templates) that can be expensive. Since C++ programmers generally do not consider the underlying >>implementations (arguably a very good thing), significant unintended run-time overhead can result. >> >> > >But it's not like have to choose standard implementations in every case. If the STL indeed does not give satisfactory performance, you can still write your own specialized (fast) code. > > > >>The problem is that a major reason for using C++ in the first place is to take advantage of these specific C++ library features. A major motivation for the development of C++ itself was to facilitate code sharing by better isolating main program code from library implementation details. A C++ program that avoids using simplifying standard library facilities by reimplementing them is arguably bad C++. >> >> > >The STL is not the only feature you get with C++. OOP is the major other one, and it's useful even if you choose not to use any 3rd party libraries. > >Cheers >Benjamin > >