Why is not more FreeBSD software written in C++?

[Benjamin Lutz]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-chat/attachments/20060420/25308a9f/attachment.pgp