[Ktechlab-devel] Mystery Code

Sun Nov 18 19:05:01 UTC 2007

Dnia niedziela 18 listopada 2007, Alan Grimes napisał:
> 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 exactly 
C++ that bothers you and it doesn't suck, it's just that you didn't know 
about something.

>
> 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 exists 
and it's a good thing to use them because the code using a class gets 
cleaner - at the expense of the class' code, but that's exactly how it should 
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 else 
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. =\

And divides by n times that the amount of senseless and unproductive repeating 
of someone's work a programmer needs to do to have such a system in place 
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 code 
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
> {
> 	Q_OBJECT
> 	public:
> ##############
>
> 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 class 
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. =(

It's a Qt mechanism for triggering and receiving events. You just define 
signals and slots, connect them and stop caring about how things work 
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+=2. =(
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. =(

Google for Qt Library. One of the best library documentations around. Or look 
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 KDE 
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 otherwise 
wasted on writing dumb thins that need to be there but have nothing to do 
with what the program actually does, like updating GUI with object's 
properties or vice versa and saving/loading files.

-- 
Remigiusz "Enleth" Marcinkiewicz, enleth at enleth.com
WWW http://enleth.com http://heroes.net.pl
JID enleth at chrome.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/ktechlab-devel/attachments/20071118/2d55224d/attachment.sig>