Dnia niedziela 18 listopada 2007, Alan Grimes napisa=C5=82:
> C++ sux.
> Here's why.
I'm just a KTechlab user, but I know a fair bit of C++ and Qt, so I think I=
might be able to clarify some issues. First and foremost, this is not exact=
C++ that bothers you and it doesn't suck, it's just that you didn't know=20
> Look at the constructor. Instead of just having variables, it has
> "properties", a special OOP construct which hides function calls in
> simple assignment statements (!!!). Just by declaring that it has a
> property, it is allowed to specify the type, limiting values, and
> initial value...
Nothing "special" in that, nor extraordinary. They're around since OOP exis=
and it's a good thing to use them because the code using a class gets=20
cleaner - at the expense of the class' code, but that's exactly how it shou=
be done. You don't need to care as a user of the class if it has to update=
its state when you change its property - in fact, you must not care, or els=
what's the point of using objects instead of structs?
> Once this is done, something rather spectacular happens, First, in the
> UI, a list of these properties appear and the user is given the ability
> to change them directly... -- I've only begun to understand how this
> works much less trace the execution path through the dozens of classes
> that are doubtlessly involved. Furthermore, there is even more hidden
> code which automatically keeps the GUI synchronized with the actual
> state of the device, through what's called the "observer" paradigm. It's
> a C++ missfeature which quadruples the amount of work someone
> maintaining the code needs to do to figure out what is effecting what in
> the code. =3D\
And divides by n times that the amount of senseless and unproductive repeat=
of someone's work a programmer needs to do to have such a system in place=20
where it's needed. And this code is not "hidden". It's just the Qt library=
doing all the tedious things.
> Second, there is no such thing as "circuitdocumentfile.cpp" Nothing in
> the code handles .circuit files! Instead, there is some library routine,
> in a package that I have not yet been able to identify much less get
> documentation on, the file is built up by collecting these properties
> from all objects in the circuit and making some other library call,
> which I haven't located yet, which generates (and reads!!!) XML files of
> a reasonable and robust format. -- It will simply ignore unsupported
> features of different versions.
That's probably Qt, again. So you don't have to write a shedload of dull co=
just to load and save a stupid file. Why would you?
> This is all slicker than snot, and utterly untracable to anyone who
> doesn't know how it all works in advance. Every method call is a method
> call to a parent class, as opposed to a class variable, so there is no
> prefix to grep for. At various points in the chain, the direction of
> invocation reverses so if you identify the parent class supporting one
> of these calls, you then have to identify the other interface in the
> class's protocol that is being invoked by some other part in the system,
> identify that function, and then resume your trace up the class
> hierarchy. I only know the vaguest outlines, I really don't yet
> understand what the actual class responsibilities are and much more
> importantly, which methods I should and should not modify...
> One issue that is really getting on my nerves is the use of what appears
> to be C++ keywords I've never heard of, or some extension to C++ by a
> mechanism which is equally foreign to me.
Those are Qt macros.
> fragment: #######
> class ComponentModelLibrary : public QObject
> See that? Q_OBJECT. WHAT IN GOD'S NAME DOES WRITING Q_OBJECT THERE DO?
It tells the Qt macro preprocessor to do some arcane mysteries to this clas=
so that what follows makes sense.
> I know what public: is, I know what private: is. I even know where to
> look up what protected: is. BUT WHAT IN GOD'S NAME IS PUBLIC SLOTS:????
> Kdevelop paints the "slots" keyword blue but I have no idea what it
> means or why it is there. =3D(
It's a Qt mechanism for triggering and receiving events. You just define=20
signals and slots, connect them and stop caring about how things work=20
together from that point on - they work and that's it.
> Connect, which at first appears to be an ordinary function/method call,
> is painted blue by kdevelop so it is probably something else, god only
> knows what! same with SIGNAL and SLOT.
Wow, I'm a god? Amazing... Seriously, connect() is a macro, too.
> I don't even think this is C++, it's more like C+=3D2. =3D(
It's C++ with Qt.
> I can't find this by keyword in Bjarne Strostrup's "The C++ Programming
> Language." There is probably a name for it that I could look up, but I
> don't know it. =3D(
Google for Qt Library. One of the best library documentations around. Or lo=
for the "C++ GUI programming with Qt3" book, if you can get it cheap. Nice,=
just a bit outdated with Qt4 around, but still relevant.
All in all, what you see is a perfectly good C++/Qt code, as in the whole K=
project and any other non-KDE Qt application out there. And I'm sure you'll=
like Qt when you get to know it better, it just saves a LOT of time otherwi=
wasted on writing dumb thins that need to be there but have nothing to do=20
with what the program actually does, like updating GUI with object's=20
properties or vice versa and saving/loading files.
Remigiusz "Enleth" Marcinkiewicz, enleth@...
WWW http://enleth.com http://heroes.net.pl