There is ONE exception [LWN.net]

There is ONE exception

Posted Apr 3, 2009 6:01 UTC (Fri) by khim (subscriber, #9252)
In reply to: A GNOME 3.0 plan by qg6te2
Parent article: A GNOME 3.0 plan

Using the same logic one could argue that "there is nothing at all you can do in C that you can't do in assembler", including having an object oriented approach.

Unfortunatelly it's not true at all. Yes, you can implement OOP in assembler (heck, TASM 3.0 included a lot of OOP-oriented constructs), but in the end the acholess heel of assembler is the fact that you can not write portable program in assembler. You even may need to call functions differently under different OS with the same CPU! Thus C makes sense as "high-level-portable-assembler".

There is a multitude of reasons why C++ exists, one of them being that much of the drudgery of handling objects is taken care of by the compiler.

Unfortunatelly it only means you must fight the compiler tooth and nail to make it produce somewhat sane code. Take a look on this and compare it with the same things in sane languages (Java or even GObject - even if it's not language it's must easier to make it do what you want and not what it wants).

(Log in to post comments)

There is ONE exception

Posted Apr 3, 2009 6:16 UTC (Fri) by qg6te2 (guest, #52587) [Link]

I'm not sure about "fighting the compiler tooth and nail". If one does that, it generally means one is fighting against the language rather than using it properly. Any language can be abused, and C++ is no exception. Furthermore, the link provided above leads to much Qt-specific code, which shouldn't be equated with all of C++ code. Qt has far more specific idiosyncrasies than gtkmm, for example.

There is ONE exception

Posted Apr 3, 2009 13:06 UTC (Fri) by nix (subscriber, #2304) [Link]

Actually, most of the stuff in that link is about not violating the
compiler's invariants regarding class definitions that change. As this is
technically a violation of the One Definition Rule in the C++ Standard,
it's unsurprising that it's a bit of a nest of snakes... but you come
across *exactly the same problem in C* if you have a system that makes
heavy use of structures and you want to change some of them without
recompiling all their users. The rules just *look* odder because the
structures are automatically built for you by the compiler: if you had to
build them by hand, *all the same issues would arise anyway*.

There is ONE exception

Posted Apr 3, 2009 15:07 UTC (Fri) by cybernytrix (guest, #5727) [Link]

If you see how QT throws away almost everything C++ provides and it reinvents all these:
1. Why do you need MOC? Debugging is a royal pain!
2. Why doesnt it use C++ strings?
3. Why do you need to implement introspection? Isnt C++ "high level" to provide this.
4. STL???

So on... GTK and GObject arguably does the same. What is the point of using C++ when your toolkit simply does not use many language features and invents a whole lot of crap?
Qt is a fine library and now it is even licensed as LGPL. The only feature of C++ they seem to be actively using is automatic calling of destructors and exceptions. Why bother with C++ for just these?

There is ONE exception

Posted Apr 3, 2009 15:24 UTC (Fri) by boudewijn (subscriber, #14185) [Link]

1) No, actually not. Debugging is painless -- at least, that's my experience over the past ten years.
2) Because they aren't half as poweful as QStrings.
3) No, C++ isn't highlevel enough.
4) All Qt container classes are compatible with the STL.

And about the features of C++ Qt uses... Well, that was just silly hyperbole, right, not an honest
question you'd like answered?