[asterisk-dev] Why not C++?
maxmeneault at free.fr
Thu Nov 8 03:44:58 CST 2007
Power, Paul C. wrote:
> I was wondering why Asterisk is not written in C++ or if
> there is any interest in having Asterisk written in C++.
The simple answer: originally written in C there is no need to do turn
it into C++. As long as we can program it in C and maintain it in C,
just keep it in C!
As others said before, programming language is only a matter of taste,
you are used to program in C++ so you will defend its cause.
I have got a lot experience in programming, I coded a lot in
C++, scheme, assembly, tcl/tk, java and C. I actually prefer C because
this is the last language I worked on but when I was working in Java 1
year ago I would have said C is just an old ugly language....
When you are working on a new language (I mean really working not
learning), there is always a repulsion time because of the differences
from your preferred language. But as soon as you get into it you forget
everything and start loving it. (Even scheme or assembly!!!)
And in IMHO C++ is only a "best practices" C. So a really good
programmer which is aware of C problematics and object-oriented features
and design considerations won't go into trouble while programming in C.
You can easily program in an object-oriented manner in C, this is only a
question of defining it clearly (function and variable naming
conventions, required functions, parameter definition...)
What is usually bad in object-oriented language is that some end-up
following too much conventions (which don't feet well for a specific
project -- some of them are simply imposed by the language itself) and
code becomes overloaded by unnecessary function calls where simple
member access would suffice.
Performance would be affected not by slow language performance but
rather by unneeded function calls (i.e stack saving/restore).
Experts in object-oriented language wouldn't probably fall into that
kind of caveats but usually they do because they end-up targeting at
maintainability at a the price of forgetting about performances.
I do agree that stack saving/restore doesn't affect much on today's
computers and a bad algorithm choice would probably affect much more the
Anyway my opinion on language choice is that:
- For client-side programs I recommend using an object-oriented language
because performances are usually not critical and it is then better to
target at maintainability.
- For servers I recommend using C (or even assembly) where performance
is really time critical (or if it could be run along with something
As asterisk is a server program which is meant to be used on servers
where performances are really important then we may better keep it in C.
> I have been watching the list of bugs and other proposed
> changes to asterisk (fast-ast2).
> It has occurred to me there may be great values in leveraging
> something like the BOOST libraries to take care of some of
> the minutiae that seems to cause problems.
> I am thinking mostly collecitons, threading, string processing.
If it had been well designed that kind of problems wouldn't occur, but
this is a common problem in open-source community. Design considerations
are simply avoided. Most contributors only targets at adding new
features that simply work.
"what do you expect? that's free software..."
Most are programming for hobby purposes and don't want to be bothered
with any kind of documentation (including design consideration)...
Moreover a lot of programmers do not have the knowledge of to issue that
kind of considerations.
Being a programmer does not mean being a software engineer.
In asterisk world I think that most contributors are from telecom world
not from computer engineering world. While there are a lot of
universities that do provide mixed courses you can not compare someone
which studied computer engineering during 5 years and someone who
learned C during 1 year...
And I am not talking about the ones that are neither telecom engineer
nor computer engineers...
So the word of end is that:
If you target at getting more contributors for open-source community
turn-it into PHP :) (but be aware of what you will get)
IMHO asterisk only need some written 'design considerations' and the
most important good programmers!
More information about the asterisk-dev