From owner-freebsd-chat@FreeBSD.ORG Thu Apr 20 20:58:45 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 4815816A401 for ; Thu, 20 Apr 2006 20:58:45 +0000 (UTC) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABB9143D4C for ; Thu, 20 Apr 2006 20:58:44 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (unknown [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id D73042E0A3; Thu, 20 Apr 2006 22:58:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at atlantis.intranet Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (atlantis.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FLL9TL6ThCs; Thu, 20 Apr 2006 22:58:42 +0200 (CEST) Received: from mini.intranet (mini.intranet [10.0.0.17]) by maxlor.mine.nu (Postfix) with ESMTP id 8DFE92E0A1; Thu, 20 Apr 2006 22:58:42 +0200 (CEST) From: Benjamin Lutz To: freebsd-chat@freebsd.org Date: Thu, 20 Apr 2006 22:58:35 +0200 User-Agent: KMail/1.8.3 References: <200604161033.k3GAXZSK001785@mist.nodomain> In-Reply-To: <200604161033.k3GAXZSK001785@mist.nodomain> X-Face: $Ov27?7*N,h60fIEfNJdb!m,@#4T/d; 1hw|W0zvsHM(a$Yn6BYQ0^SEEXvi8>D`|V*F"=?iso-8859-1?q?=5F+R=0A?= 2@Aq>+mNb4`,'[[%z9v0Fa~]AD1}xQO3|>b.z&}l#R-_(P`?@Mz"kS; XC>Eti,i3>%@g?4f,=?iso-8859-1?q?=5Cc7=7CGh=0A?= =?iso-8859-1?q?_wb=26ky=24b2PJ=5E=5C0b83NkLsFKv=7CsmL/cI4UD=25Tu8alAD?= MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart44070071.c6Iv2kfUaA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200604202258.38424.benlutz@datacomm.ch> 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: Thu, 20 Apr 2006 20:58:45 -0000 --nextPart44070071.c6Iv2kfUaA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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= =20 plain C, a repeated putchar(' ') is 1-2 orders of magnitude slower than=20 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=20 think of any program I use whose I/O routines are CPU bound. Ok, I guess if= =20 we look at really weak or embedded devices, say, those Soekris net4501=20 boards, I/O CPU efficiency will make a difference. The advantages of the iostream framework are clear though, you can do thing= s=20 like=20 cout << some_complicated_data_structure_object; even if you don't know what the class of the object you're dealing with is.= =20 > 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= =20 the STL indeed does not give satisfactory performance, you can still write= =20 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 on= e,=20 and it's useful even if you choose not to use any 3rd party libraries. Cheers Benjamin --nextPart44070071.c6Iv2kfUaA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBER/X+gShs4qbRdeQRAlqUAKCQTsEXJ5tnlY5MKtW+xLtGfP20AACcDAMU U+3EOfZArVnn7MRuAdY01mc= =PI/5 -----END PGP SIGNATURE----- --nextPart44070071.c6Iv2kfUaA--