curious use of labels in C++

[worksofcraft]

No doubt most of us know of using labels with dreaded goto statement and inside classes we label parts as private:/protected:/public: but learning QT atm I see the following:

class CannonField : public QWidget {
public:
... usual bunch of methods

// but what use is a public label here ?
public slots:
     void setAngle(int angle);
     void setForce(int force);

// and another label here?
signals:
     void angleChanged(int newAngle);
     void forceChanged(int newForce);

 protected:
... then back on familiar terrain 

if I take out it won't compile

[GeneralZod]

Those aren't labels: those are some of the "extensions" to C++ that Qt uses for its signals and slots system - they are processed automatically by Qt's moc tool into "normal" C++ prior to compilation.

Think of them as artificial syntactic sugar

Edit:

Oh, and I may as well nip this in the bud - it's "Qt", not "QT"

[worksofcraft]

Those aren't labels: those are some of the "extensions" to C++ that Qt uses for its signals and slots system - they are processed automatically by Qt's moc tool into "normal" C++ prior to compilation.

Think of them as artificial syntactic sugar

Edit:

Oh, and I may as well nip this in the bud - it's "Qt", not "QT"

Ah... OK that makes more sense now, TYVM
I don't particularly like proprietary language extension pre- processors like this, but I suppose it's better than having to learn a whole new language like C# or Vala and it makes me wonder what is so beneficial about the esoteric extensions that it couldn't have been solved with regular language features

[GeneralZod]

Vala basically is a "proprietary language extension pre-processor"

Qt's signals and slots (as well as it's QProperties) provide run-time introspection of an objects capabilities, allowing you to greatly reduce the coupling between objects - you can connect objects together that literally have no knowledge of each other at all - something that's awkward to pull off in a statically-typed language like C++.

[nvteighen]

Ah... OK that makes more sense now, TYVM
I don't particularly like proprietary language extension pre- processors like this, but I suppose it's better than having to learn a whole new language like C# or Vala and it makes me wonder what is so beneficial about the esoteric extensions that it couldn't have been solved with regular language features

When using Qt, always keep in mind that it was designed when there was no C++ standard yet... and that it had to keep several features because of backwards compatibility.

[worksofcraft]

When using Qt, always keep in mind that it was designed when there was no C++ standard yet... and that it had to keep several features because of backwards compatibility.

Hummm... yes well I'm not that happy with QT now that I've had a chance to experiment.

What I'm actually working towards is a fully functional bidirectional language terminal emulator. That is one that can handle a mixture of left to right and right to left languages.

Like Gtk, Qt has all the official algorithms built in. So to test it oout, I hacked an Arabic text into QT tutorial #8 and once I changed "tr" to "trUtf8" it seemed to work... up to the point when I moved the slider. Suddently numbers displayed were hopped from the left side to the right side of the text and back again depending on their magnitude

ANyway I planned to prune out the irrelevant bits and just display some bidirectional text. I started simply copying all the .h and .cpp files into one single source file that was perfectly legitimate by C++ standards (with exception of afore mentioned QT extensions) and I get stacks of inexplicable linker messages like:

cannonmain.cpp:(.text+0x72): undefined reference to `vtable for LCDRange'

Then I notice QT doesn't use gettext for internationalization and has it's own localization hard coded for the set of languages that it supports.

That trUtf8 call that was necessary to display my utf-8 characters also implied it was going to try and translate it all and in my terminal emulator application that is really NOT what I want: I'm displaying what the user is typing as well as the output from any commands that run, and those will be using their own l10n facilities where applicable

So as far as I'm concerned QT is simply too clever for it's own good I need something dumber... like perhaps I take it back to the original X11 interface

[spjackson]

Hummm... yes well I'm not that happy with QT now that I've had a chance to experiment.

After a short spell using Qt any problems you have encountered will naturally by down to defects in Qt.

What I'm actually working towards is a fully functional bidirectional language terminal emulator. That is one that can handle a mixture of left to right and right to left languages.

Like Gtk, Qt has all the official algorithms built in. So to test it oout, I hacked an Arabic text into QT tutorial #8 and once I changed "tr" to "trUtf8" it seemed to work... up to the point when I moved the slider. Suddently numbers displayed were hopped from the left side to the right side of the text and back again depending on their magnitude

If you have found a demonstrable, repeatable bug in Qt, then why don't you report it? Did you report any of the Gtk faults you found to the Gtk project?

ANyway I planned to prune out the irrelevant bits and just display some bidirectional text. I started simply copying all the .h and .cpp files into one single source file that was perfectly legitimate by C++ standards (with exception of afore mentioned QT extensions) and I get stacks of inexplicable linker messages like:

cannonmain.cpp:(.text+0x72): undefined reference to `vtable for LCDRange'

Yes, moc is defective: it fails when users ignore the instructions.

Then I notice QT doesn't use gettext for internationalization and has it's own localization hard coded for the set of languages that it supports.

Naturally, Qt does not use gettext because gettext is GPL. The GPL is not compatible with Nokia's (and formerly Trolltech's) licensing policy.

That trUtf8 call that was necessary to display my utf-8 characters also implied it was going to try and translate it all and in my terminal emulator application that is really NOT what I want: I'm displaying what the user is typing as well as the output from any commands that run, and those will be using their own l10n facilities where applicable

The tr() and trUtf8() calls do indeed try to translate whatever you pass them. If you don't want the translation, then fromUtf8() might be what you are looking for. The functions should perhaps have been called trStandsForTranslate() and trStandsForTranslateUtf8().

So as far as I'm concerned QT is simply too clever for it's own good I need something dumber... like perhaps I take it back to the original X11 interface

I look forward to the list of defects you find in X11.

Now I have no particular axe to grind in defending Qt - I am merely a user and I do have my own criticisms. However, I note that the problems you have had in your project have all been the fault of Gtk, C++ and now Qt. I do wonder whether you are possibly being a little unfair.

If you direct your concerns to the qt-interest mailing list, expressed rationally and calmly, I would be surprised if Thiago Maciera did not do his best to address them. You might also be interested to read some of Josh Grauman's (fairly recent) postings on his Hebrew project. However, you seem to have already dismissed Qt as not fit for purpose, so perhaps there's not much point in that.

[dwhitney67]

ANyway I planned to prune out the irrelevant bits and just display some bidirectional text. I started simply copying all the .h and .cpp files into one single source file that was perfectly legitimate by C++ standards (with exception of afore mentioned QT extensions) and I get stacks of inexplicable linker messages like:

cannonmain.cpp:(.text+0x72): undefined reference to `vtable for LCDRange'

The error above tells me that you did not implement one or more virtual methods in the LCDRange class. This is not a Qt problem... this is a programmer problem.

[worksofcraft]

After a short spell using Qt any problems you have encountered will naturally by down to defects in Qt.
If you have found a demonstrable, repeatable bug in Qt, then why don't you report it? Did you report any of the Gtk faults you found to the Gtk project?
Yes, moc is defective: it fails when users ignore the instructions.
Naturally, Qt does not use gettext because gettext is GPL. The GPL is not compatible with Nokia's (and formerly Trolltech's) licensing policy.
The tr() and trUtf8() calls do indeed try to translate whatever you pass them. If you don't want the translation, then fromUtf8() might be what you are looking for. The functions should perhaps have been called trStandsForTranslate() and trStandsForTranslateUtf8().
I look forward to the list of defects you find in X11.

Now I have no particular axe to grind in defending Qt - I am merely a user and I do have my own criticisms. However, I note that the problems you have had in your project have all been the fault of Gtk, C++ and now Qt. I do wonder whether you are possibly being a little unfair.

If you direct your concerns to the qt-interest mailing list, expressed rationally and calmly, I would be surprised if Thiago Maciera did not do his best to address them. You might also be interested to read some of Josh Grauman's (fairly recent) postings on his Hebrew project. However, you seem to have already dismissed Qt as not fit for purpose, so perhaps there's not much point in that.

I haven't dismissed anything.

I could spend all day every day for years reading all the opinions and research done by other people and no doubt different publications promote different perspectives. Without actually experiencing the problems first hand I probably won't even understand what they are talking about.

It is question of taking an objective look at the issues of programming with these different packages. Based on what I like and what I dislike I make a rational choice which I hope will prevent me from bashing my head against a dead-end brick wall further down the line.

Personally I greatly favor the principle of KISS: "Keep it simply stupid" and on that basis I don't like the moc system nor do I find it appealing that localization logic in QT seems to be hard coded into the package.

I had a good look at the code for gnome-terminal and the vte widget. From what I have seen I would not enjoy working on that code.

Motivation for developing something new is usually based on dissatisfaction with what is already available. If it were not for that, then you would probably still be programming in Cobol.

[worksofcraft]

The error above tells me that you did not implement one or more virtual methods in the LCDRange class. This is not a Qt problem... this is a programmer problem.

Yeah that's what I thought too at first, but eventually I worked out that it's because I have to put all QOBJECT's in separate .h files so that the moc generated source files can include them. Strangely it doesn't complain at compile time but just gives above linker error.

Note: Regarding posting bug reports, Here are images of R2L problems with a simple string and number. It is debatable whether these are even bugs. Doing proper testing and identifying repeatability of such issues in any of these packages is a major project in it's own right and not one I set out to be working on atm. A quick google tells us there are plenty of people who do actually know how their language needs to be displayed who have been posting such bug reports for many years.