Qt-interest Archive, August 2002
Re: GTK vs QT
Pages: Prev | 1 | 2 | 3 | 4 | Next
Message 31 in thread
> > That's what GTK-- uses isn't it? The big problem with GTK-- for me,
> > though, is it has no Windows port. Now I prefer programming on Linux but I
> > want my software to be used by as many people as possible.
>
> This factor is by the by. There are Windows compilers that can handle
> modern C++ well now, no ?
From what I gather GTK+ is still very experimental in Windows. Therefore
GTK-- is unlikely to be of any use for writing serious Window spps.
> OK, so there was all sorts of good reasons that the trolls decided to
> throw out most of C++
Most of C++! erm - it uses objects, inheritance, polymorphism,
pointers, templates...
I agree it doesn't use the STL (I would personally perfer it if it did,
as it's the standard) but that's not C++ itself, but an add on albeit
standard library.
> when they wrote their toolkit: compilers at the
> time were pretty poor. Even today there are numerous problems, and I
> suspect Trolltech have numerous business reasons for supporting old
> systems still.
>
Maybe there are, but I can't think of anything better out there for
writing cross platform C++ GUI programs in clear comprehensible code. Do
you have any suggestions? I would be willing to investigate further if you
have...
Nick
Message 32 in thread
On Sat, Aug 03, 2002 at 08:58:53PM +0100, Nick Whitelegg wrote:
> I agree it doesn't use the STL (I would personally perfer it if it did,
> as it's the standard) but that's not C++ itself, but an add on albeit
> standard library.
IMHO use of the STL is important in good C++ code, mainly for reasons
familiarity - every new API that needs to be learnt translates into bugs
(am I the only person who was hit by QString::isNull ?)
> > when they wrote their toolkit: compilers at the
> > time were pretty poor. Even today there are numerous problems, and I
> > suspect Trolltech have numerous business reasons for supporting old
> > systems still.
>
> Maybe there are, but I can't think of anything better out there for
> writing cross platform C++ GUI programs in clear comprehensible code. Do
> you have any suggestions? I would be willing to investigate further if you
> have...
I don't know of any better options than Qt, but I haven't tried out a
particularly wide range of toolkits
regards
john
--
[ signature omitted ]
Message 33 in thread
> On Sat, Aug 03, 2002 at 08:58:53PM +0100, Nick Whitelegg wrote:
>
> > I agree it doesn't use the STL (I would personally perfer it if it
did,
> > as it's the standard) but that's not C++ itself, but an add on
albeit
> > standard library.
>
> IMHO use of the STL is important in good C++ code, mainly for reasons
> familiarity - every new API that needs to be learnt translates into
bugs
> (am I the only person who was hit by QString::isNull ?)
Uh, how much can you do wrong with QString::isNull(), when the
documentation reads
"Returns TRUE if the string is null; otherwise returns FALSE. A
null string is always empty.
\code
QString a; // a.unicode() == 0, a.length() == 0
a.isNull(); // TRUE, because a.unicode() == 0
a.isEmpty(); // TRUE
\endcode
\sa isEmpty(), length()"
--
[ signature omitted ]
Message 34 in thread
On Sun, Aug 04, 2002 at 06:44:49PM +0200, Volker Hilsheimer wrote:
> Uh, how much can you do wrong with QString::isNull(), when the
> documentation reads
>
> "Returns TRUE if the string is null;
The very existence of this possibility is a surprise to an unsuspecting
C++ programmer. And can you tell me without referring to the
documentation exactly which API calls can return a null string ?
It is a surprising and non-obvious behaviour.
regards
john
--
[ signature omitted ]
Message 35 in thread
> On Sun, Aug 04, 2002 at 06:44:49PM +0200, Volker Hilsheimer wrote:
>
> > Uh, how much can you do wrong with QString::isNull(), when the
> > documentation reads
> >
> > "Returns TRUE if the string is null;
>
> The very existence of this possibility is a surprise to an
unsuspecting
> C++ programmer. And can you tell me without referring to the
> documentation exactly which API calls can return a null string ?
>
> It is a surprising and non-obvious behaviour.
>
> regards
> john
A C++ programmer should have at least enough C background to know that
const char *null = 0;
is not the same as
const char *empty = "";
(or char const* ;-)
QString preserves this not insignificant information. E.g. casting a
null-string to a const char * gives you a null pointer, and putting that
into strlen will crash, while using strlen on an empty string returns 0.
APIs return a null string when there is no information to return, e.g.
QString short( "123" );
QString part = short.mid( 5, 10 );
"part" will be a null-string, because there is nothing to initialize it
with. This is quite obvious - an empty string would mean "there was some
emptyness out there" (and to know about that emptyness, QString would
have to perform an illegal operation).
APIs return an empty string if there was an empty string. E.g.
QLineEdit::text() returns an empty string if the contents of the
QLineEdit are empty. This also is quite obvious.
It's quite possible that there are inconsistencies in the Qt API in that
respect (inconsitencies that are hard to get rid of without breaking
code relying on them), but the return values are documented and the docu
can be consulted when the "rule of thumb" outlined above does not hold.
--
[ signature omitted ]
Message 36 in thread
On Sun, Aug 04, 2002 at 07:36:15PM +0200, Volker Hilsheimer wrote:
> A C++ programmer should have at least enough C background to know that
>
> QString preserves this not insignificant information. E.g. casting a
> null-string to a const char * gives you a null pointer, and putting that
> into strlen will crash, while using strlen on an empty string returns 0.
C++ programmers generally use std::string unless there are over-riding
reasons not to, precisely because C string handling is so awful.
> APIs return a null string when there is no information to return, e.g.
>
> QString short( "123" );
> QString part = short.mid( 5, 10 );
>
> "part" will be a null-string, because there is nothing to initialize it
> with. This is quite obvious - an empty string would mean "there was some
> emptyness out there" (and to know about that emptyness, QString would
> have to perform an illegal operation).
Why not check out the approach the C++ standard library uses ?
As far as I can see, QString::isNull() is there primarily as an
(obscure) exception handling mechanism for things like
QFileDialog::getOpenFileName()
regards
john
--
[ signature omitted ]
Message 37 in thread
> On Sun, Aug 04, 2002 at 07:36:15PM +0200, Volker Hilsheimer wrote:
>
> > A C++ programmer should have at least enough C background to know
that
> >
> > QString preserves this not insignificant information. E.g. casting a
> > null-string to a const char * gives you a null pointer, and putting
that
> > into strlen will crash, while using strlen on an empty string
returns 0.
>
> C++ programmers generally use std::string unless there are over-riding
> reasons not to, precisely because C string handling is so awful.
So, and how does that C++ programmer interfaces with a C library? Most
of the significant algorithms are still provided in C, for a reason, and
that you can use C when you don't need object orientation is one of the
strenghts of C++. I think you pull again an argument of "C++ by the
book" vs. "C++ in the real world". In the real world as it is today,
std::string is damn close to almost meaningless.
> > APIs return a null string when there is no information to return,
e.g.
> >
> > QString short( "123" );
> > QString part = short.mid( 5, 10 );
> >
> > "part" will be a null-string, because there is nothing to initialize
it
> > with. This is quite obvious - an empty string would mean "there was
some
> > emptyness out there" (and to know about that emptyness, QString
would
> > have to perform an illegal operation).
>
> Why not check out the approach the C++ standard library uses ?
Which is? Instead of QString::mid they have basic_string::copy, which
has probably the worst API in a C++ class I have seen today. No, thanks,
I'll stick with QString::null.
> As far as I can see, QString::isNull() is there primarily as an
> (obscure) exception handling mechanism for things like
> QFileDialog::getOpenFileName()
>
Exception handling is nice sometimes, but overrated. Throwing an
exception every time you call QString::mid with an invalid index or when
the user presses cancel in a dialog is just a terrible idea.
The justification I see for exception handling is when calling foreign
code. Non-fatal error situations that can be handled by return values
should be handled by return values. Cleaner, faster, smaller and easier.
--
[ signature omitted ]
Message 38 in thread
On Sun, Aug 04, 2002 at 08:14:44PM +0200, Volker Hilsheimer wrote:
> > C++ programmers generally use std::string unless there are over-riding
> > reasons not to, precisely because C string handling is so awful.
>
> So, and how does that C++ programmer interfaces with a C library? Most
Perhaps you didn't read carefully enough. In particular the "reasons not
to" bit. And even then, you restrict bare use of char[] as much as
possible.
> std::string is damn close to almost meaningless.
I don't know what real world you are in, but it is not the same as mine.
But this has veered wildly offtopic
john
--
[ signature omitted ]
Message 39 in thread
> >
>
> Exception handling is nice sometimes, but overrated. Throwing an
> exception every time you call QString::mid with an invalid index or when
> the user presses cancel in a dialog is just a terrible idea.
>
> The justification I see for exception handling is when calling foreign
> code. Non-fatal error situations that can be handled by return values
> should be handled by return values. Cleaner, faster, smaller and easier.
>
I actually prefer exception handling, seems nicer and more intuitive to
me. I use it rather a lot in my Mapmaker application (often throwing
QStrings - that's basically my approach, I pick and choose from whatever
aspects of C++ and the Qt library that I like :-) ) to handle errors.
Doing the equivalent code with return codes would be much messier.
Nick
Message 40 in thread
> > Exception handling is nice sometimes, but overrated. Throwing an
> > exception every time you call QString::mid with an invalid index or
when
> > the user presses cancel in a dialog is just a terrible idea.
> >
> > The justification I see for exception handling is when calling
foreign
> > code. Non-fatal error situations that can be handled by return
values
> > should be handled by return values. Cleaner, faster, smaller and
easier.
> >
>
> I actually prefer exception handling, seems nicer and more intuitive
to
> me. I use it rather a lot in my Mapmaker application (often throwing
> QStrings - that's basically my approach, I pick and choose from
whatever
> aspects of C++ and the Qt library that I like :-) ) to handle errors.
> Doing the equivalent code with return codes would be much messier.
>
> Nick
>
Leaves "faster, smaller" as arguments. Anyway, it's ok to throw
exceptions in an application where the application developer has control
over what he does, and how, and knows whether he cares about performance
or binary sizes or not.
It's not ok to throw exceptions in a library just because you can, esp.
with a library that must support all sorts of compilers that have no
usable exception handling.
--
[ signature omitted ]
Message 41 in thread
Volker Hilsheimer (vohi@gmx.de) wrote:
:
: Which is? Instead of QString::mid they have basic_string::copy, which
: has probably the worst API in a C++ class I have seen today. No, thanks,
: I'll stick with QString::null.
Or you could use basic_string::substr, which requires a start index and a
count of the number of characters you want to retrieve. The return value
is a string containing the requested sub-part of the string. You have to
admit that this is pretty close to using QString::mid don't you? :)
Morten.
Message 42 in thread
> Volker Hilsheimer (vohi@gmx.de) wrote:
> :
> : Which is? Instead of QString::mid they have basic_string::copy,
which
> : has probably the worst API in a C++ class I have seen today. No,
thanks,
> : I'll stick with QString::null.
>
> Or you could use basic_string::substr, which requires a start index
and a
> count of the number of characters you want to retrieve. The return
value
> is a string containing the requested sub-part of the string. You have
to
> admit that this is pretty close to using QString::mid don't you? :)
>
> Morten.
>
Indeed. I didn't see it in the MSDN for some reason (I really tried, but
I guess I got confused by the typedef mess they have there...). And
indeed, they throw an exception when pos is out of bounds, which means
for Microsoft's not-so-brilliant STL implementation that you can't even
use it without exceptions being enabled... great!
Anyway, as pointed out by John, this is not GTK vs Qt anymore at all,
and not Qt related enough to justify pursuing this thread any longer.
Volker
Message 43 in thread
Volker Hilsheimer wrote:
>>On Sat, Aug 03, 2002 at 08:58:53PM +0100, Nick Whitelegg wrote:
>>
>>
>>>I agree it doesn't use the STL (I would personally perfer it if it
>>
> did,
>
>>>as it's the standard) but that's not C++ itself, but an add on
>>
> albeit
>
>>>standard library.
>>
>>IMHO use of the STL is important in good C++ code, mainly for reasons
>>familiarity - every new API that needs to be learnt translates into
>
> bugs
>
>>(am I the only person who was hit by QString::isNull ?)
>
>
> Uh, how much can you do wrong with QString::isNull(), when the
> documentation reads
Not much but pretty easy and very often: string s(qs.latin1());
Thomas
Message 44 in thread
On Fri, Aug 02, 2002 at 04:40:47PM +0200, qt-interest@lithos-mineralien.de wrote:
> > Qt:
> >
> > connect(source, SIGNAL(clicked()), target, SLOT(clicked());
> >
> > libsigc++
> >
> > source.connect(slot(target, &Target::clicked));
> >
> > boost::signals
> >
> > source.connect(boost::bind(&Target::clicked, target));
> >
> > More difficult ? Come on !
> Not more difficult, but problematic from another point of view: The class the
> source is pointing to has to be known (just extern class foo; doesn't cut it)
I have yet to find this a problem.
> with Qt it's simple because you operate on an generic type.
It's simple to make errors, wait 10 minutes, then discover 2 months
later that the connection was wrong ...
> You probably loathe RTTI as well...
You've lost me.
> Btw which signal are you connecting in the libsigc++ and boost examples. I
> can't decipher what you are trying to do there.
Silly typo. More like source->clicked.connect ... or
source.clicked.connect
> > > When I wrote this, the idea was to see how difficult porting from Gtk to
> > > Qt is. The answer is: easily!
> >
> > For some toy program
> No, absolutely untrue.
I did not say that it wasn't easy for more complex programs, did I ? I
merely pointed out that that example is not evidence enough.
> know I made a living out of it during that time), to Qt in about a week. You
> are just unhappy with a decision someone took (and stands by that decision)
> some time ago. I am happy with just that decision and wouldn't have it any
> other way.
Fine; quite a few people seem to feel that way.
> Besides that, you are getting insulting here. Any program someone spends his
> time programming is worth the effort. Be it that (s)he wants to learn
> something new or make a $1000 per copy because it's so brilliantly new and
> innovative that anyone would pay that much.
I didn't mean to offend, merely point out that small programs are not
necessarily indicative. Sorry.
> Don't knock it until you try it. I still can remember when cfront was a
Are you listening ? I have and do try it, and it makes my life more
difficult. Again: I use Qt and think it's a well-constructed toolkit on
the whole.
regards
john
--
[ signature omitted ]
Message 45 in thread
> > Don't you ever use macros ?
>
> No. I write in C++, where the C preprocessor is dangerous and usually
> a very bad idea. Amongst other things, it pollutes the global namespace.
> Ever tried to use a class with a method called emit in some Qt code ?
No, neither do I try to define a method of my own called size() on a QWidget
because QWidget already has one. And I avoid calling my methods Q_OBJECT
either.
I see your point but I don't see it as a major drawback.
For emit, you can easily disable it since it evaluates to nothing. You can
even disable SIGNAL and SLOT and use the ascii equivalents.
> > > 2) binding errors are (maybe, maybe not) discovered at
> > > runtime. That sucks.
> >
> > Do you have example of not detected binding errors ? I haven't ever
> > encountered any.
>
> Huh ? As in the prototypes don't match. It happens all the time.
Then my prototypes always match. I copy/paste them usually.
> > I did not know about that but you are probably right. Do you often use
'char
> > const *' ?
>
> Yes, or I would do. Our coding style dictates it.
And you mix semantically equivalent but syntactically different types ? I
avoid that, not just because Qt does not support it but because I find it
unclear for the guy reading me afterwards. I hope your coding style is not
promoting that directly ?
> > True, but it is most of the time automatically handled. Either with
Visual,
> > tmake or KDE's build stuff.
>
> And somebody has to build all this automatic handling if you're not
> using one of these three.
You are right. And you have to do it for .ui too.
I am curious: what do you think of Trolltech's .ui files ? I find their
approach elegant in comparison with the other that I have seen sofar, eg
Visual C++, where you mix generated code and manual code. Have you some
other magic pure C++ method to do that too ?
[ it may sound ironical but it is not, I am just curious. ]
> Basically, the abuse of the preprocessor extends the C++ keyword
> namespace into some pseudo-C++ language, prevent perfectly sensible use
> of common words. This is super-fine (I guess) if you are working purely
> on Qt code; the minute you have to interface to the outside world, it
> becomes a big problem.
I was working on Qt only code, that's why I had less problems.
>
> > I had a look at libsig++. It looks really cool. However, it is more
> > difficult to use that than Qt's signal/stuff.
>
> Qt:
> connect(source, SIGNAL(clicked()), target, SLOT(clicked());
>
> libsigc++
> source.connect(slot(target, &Target::clicked));
>
> boost::signals
> source.connect(boost::bind(&Target::clicked, target));
I was thinking about the declaration:
Qt:
class XXX : QObject
{
Q_OBJECT
[...]
public slots:
int foo1(int);
void foo2(int);
signals:
void sig1(int);
void sig2(int);
};
libsig++:
class XXX : Object
{
[...]
int foo1(int);
void foo2(int);
};
void some_function()
{
Signal1<int,int> sig1;
Signal1<void,int> sig2;
[...]
}
I like the fact that Qt explicitely labels signals and slots in its headers.
> More difficult ? Come on !
Okay, I was wrong. This is a matter of habbit. Both are equally easy to use
from a coding point of view. With Qt more difficult because of the Q_OBJECT.
> Sorry, I do not see the above as "advanced C++ knowledge". It's
> programming by numbers.
The syntax of the signal declaration looks slightly more complicated with
libsig++ than with Qt. But I already said you are right, this is nitpicking.
> > Specifically, the number one platform that you can not ignore as a
> > commercial app developer, Windows, needs additional work.
>
> ICBW, but boost works fine under windows, and even has hacks to support
> the most broken of Visual C++ versions.
signals/slots are not in the boost documentation. Reading the list, it looks
like it is planned to be included.
> > So libsig++ is cool in theory, unusable in practice for a portable GUI
> > application. You have to take Qt with the good and the bad.
>
> At least make the effort to try both systems. I've used all
> three of the above.
I have no need for the other system, Qt is perfect for me. So I won't try
them until I need to. But knowing that boost has a signal/slot
implementation is very intersting.
> > When I wrote this, the idea was to see how difficult porting from Gtk to
Qt
> > is. The answer is: easily!
>
> For some toy program
Yes, klotski/gnotski is a toy program.
But I did the port of gvim to kvim, which is not a toy program. I had to
deal with menu, toolbars, scrollbars, fonts, dialogs, buttons, layout and
raw drawing. For all these items, I have found the Qt code to be simpler and
more efficient. But it would use the same paradigm as Gtk, so porting was
really easy. I give an example in the comparison page, with the dialog code.
This is exactly the same fonctionality, but Qt code's length is 1/3 of Gtk
code. This is because Qt has more intelligent default than Gtk, and because
syntax is shorter.
regards,
Philippe
Pages: Prev | 1 | 2 | 3 | 4 | Next
