On 05/24/2010 10:24 AM, torbenh wrote:
>> I once read a great (and funny) article arguing that you simple can't assume
In C, this means adding integers and/or pointers. In C++, what the programmer
considers to be concatenation or addition, especially with somehow complex
objects, is very subjective. In the end, I think that you can yourself end up
writing odd things. And, this is different from Python op overloading, because
in C++, you almost always /have to/ overload the = operator. It's not marginal.
The problem here is that, in the end, we're not really dealing with a /language/
anymore. Words and operators do not have any specified meaning. The same thing
goes with function overloading, where, as in Java, two functions with the same
name but a different signature are two different things. This doesn't happen in C:
- a name is a name,
- a punctuation (operator) is a punctuation,
- a verb (function) is a verb.
But, of course, with much care, you can respect these rules in C++, and thus
stay in the language domain. But, in C, this is somehow enforced, and that helps
when you're dealing with complex algorithms: you can concentrate on what you
have to say with the language, rather than reinventing the language at the same
>>> This may be one really serious advantage for the everything-in-C types
Oh yes, there are many great features in C++.
> then you need to manage most memory yourself again....
Which may results in choosing a simplified memory model, and thus optimization.
> could you explain your reasons a bit more ?
First, it's not all about reasons, it's also a matter of taste. But what I like
about C is that, for the reasons outlined above, it's closer to doing what it
says than C++, the price being verbosity. And when I work with some low level
audio routines, where things have to be as optimized and stable as possible, I
like this clarity. Yes, your must manage memory and other things yourself, but
it's all there in front of your eyes.
That said, in the past I chose to write a GUI using pure C with Gtk, and this
was really a mistake I think. Adding simple features is really heavy now.
>> But maybe that, with experience and methodology, one can get as productive in C
Indeed, and that's why I don't use Vala. To make any real use of it, you need to
write GObjects wrappers for the libraries or low level C/C++ routines that you
need, before you can bind them into Vala.
Nevertheless, Vala looks promising. But I don't like the GObject model. I made
my own OO constructs in C with inheritance and such, but if you want the whole
thing, with interfaces etc.., I think that C just isn't the way to go.
> its probably possible to create the boilerplate out of some kind of
Actually, I'm currently thinking about some very clever IDE and intellisense
features for C. When I look at this Eclipse IDE, and all that it understands,
and thus automatically proposes, I think that similar aids could really be
useful in C.
Linux-audio-dev mailing list