[LAD] Looking for an introduction to rt programming with a gui

Olivier Guilyardi list at samalyse.com
Mon May 24 10:36:43 UTC 2010


On 05/24/2010 10:24 AM, torbenh wrote:
> On Sun, May 23, 2010 at 11:07:27PM +0200, Olivier Guilyardi wrote:

[...]

>> I once read a great (and funny) article arguing that you simple can't assume
>> anything about what the following means in C++:
>>
>> a = b + c
>>
>> Nothing
> 
> yeah. but if thats not a concatenation or an addition the programmer of
> the operator overload should be shot on sight.

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
time.

>>> This may be one really serious advantage for the everything-in-C types
>>> -- a competent C programmer can understand any C, whereas C++ is big
>>> enough to have many different "schools of C++" which are mutually
>>> unintelligible without further study.
>>>
>>> That's also the seed of its popularity, I suppose -- everyone can
>>> write the way they like in it, and if you can't work out how to do it
>>> properly, you can always drop back into C.
>> Yeah, C rocks :-)
>>
>> But, the problem is that, in my experience, C++ can increase productivity by a
>> factor of x10 or so over C. It's my personal experience. Very often, I have to
>> consider making a choice between the two, and I often end up coding the engine
>> in C and the rest in C++ or a dynamic language.
> 
> hmm.. i dont really see the advantage of writing an engine in C.
> first of all you loose RAII locks.
> http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

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
>> as in C++? I suppose the guys at Gnome would agree with that..
> 
> there is a reason why gob2 and vala emerged. 
> writing a GObject in C is a pretty big PITA.

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
> template. 
> but i am not aware of some rails/paster like framework to create this
> boilerplate with a single command.

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.

--
  Olivier








More information about the Linux-audio-dev mailing list