Date: Fri, 21 Apr 2006 09:20:51 -0700 From: Don Dugger <dugger@hotlz.com> To: freebsd-chat@freebsd.org Cc: Dan Strick <strick@covad.net> Subject: Re: Why is not more FreeBSD software written in C++? Message-ID: <44490663.3040506@hotlz.com>
next in thread | raw e-mail | index | archive | help
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
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44490663.3040506>