Date: Thu, 20 Apr 2006 22:58:35 +0200 From: Benjamin Lutz <benlutz@datacomm.ch> To: freebsd-chat@freebsd.org Cc: Dan Strick <strick@covad.net> Subject: Re: Why is not more FreeBSD software written in C++? Message-ID: <200604202258.38424.benlutz@datacomm.ch> In-Reply-To: <200604161033.k3GAXZSK001785@mist.nodomain> References: <200604161033.k3GAXZSK001785@mist.nodomain>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200604202258.38424.benlutz>