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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
