This isn't a debate pal, you've been slaughtered and now you're just whining pitifully whilst backing into a corner.
Absolutely. No really, the best one was "you say that memory management is bad, so why don't you use Java instead of C++ ?" Did you like this one too ? Such brilliant analysis of the problem, such in-depth grasp of all the issues...
Yes, yes, I confess, I'm a loser bad coder whiner and everything. I'm also paid by Microsoft and the KDE League to undermine the efforts of Gnome with my silly writings. There, I've said it. Ah, I feel better already.
Now, since you're so obviously a code master of skills way above mines, will you please further enlighten me ? Can you point me at the numerous incredible contributions which you doubtlessly have made to Gnome, so I can learn from them ? Please, pretty please ?
Evolution : 17 full-time people during 2 years. KMail : I think the core team is about 2 or 3 people, spare time.
Nautilus : 13 full-time devs, 1 year Konq : around 4 people, 1 full-time, others spare time.
did you think that the reason most GTK project have more people is because C++ puts a lot of people off
Oh my god, no I never had thought of that. Gee, what a fool I was. Thank you so much for letting me see the light. I bow to your incredible debating skills.
Why is this so difficult for the Qt zealots to understand?
Have you extensively used these bindings yourself ? I hereby challenge anyone to port Rosegarden to a GTK+ binding (any binding, Python, Perl, C++, pick one). Or even to write an app which has half of the features Rosegarden currently has.
There's a pretty big conceptual break here, either there are better hackers writing GTK/Gnome stuff, or it's simply not true that writing quality apps is easier with Qt.
Have you tried comparing the respective ressources involved in the making of these apps ? Say Nautilus vs. Konq, Evolution vs. KMail. Check how many people worked on each of these, then match that against the apps features.
Re:Valgrind and memory leaks
on
KDE 3.0 is Out
·
· Score: 1
> Will a few 100kloc do?
Not in your case it seems.
I'm sorry, but claiming that mem leaks are "straightforward to avoid" in C++ simply proves you don't know what you're talking about. Go post this on comp.lang.c++.moderated and see what answers you get.
I should have been more precise : C++ is currently the best solution on Unix. Java is arguably gaining grounds on the Windows desktop, but AFAIK, except in some high end apps it's virtually non existent on the Unix desktop. As for C#, well, in its current state it's not a solution at all.
When language fashions change, where does that leave QT?
Not much I guess. But you seem to think that a C toolkit can magically turn into a good Java or C# toolkit just by "wrapping it". It's simply not the case. The result you get is quite sub-par compared to a library directly written in Java or C#, because C is so limited.
Plus both Java and C# come with a standard graphic toolkit (and most probably so will all forthcoming languages), so there's not much point in wrapping a C graphic toolkit with those.
I also know quite a few C++ lovers who very much like Qt, and who honestly think it uses C++ very well.
But there's nothing to like or dislike here. This is only a tool. I don't use C++ or Qt because I like them but because they're the best tool for my purpose.
No, but unfortunately it's currently the best solution for programming large desktop application.
Just compare the language bindings available for each. The number available for GNOME absolutely dwarfs those for KDE.
Yes, I know, each time this subject is brought up someone comes up with this argument. But how many of these bindings are actually complete, or even used ? How many applications are based on them ?
The point here is to develop useful working applications, not to herd wrappers for the sake of it. It's better to have a limited set of viable options than a large set of bad ones.
The Sun developers suggested that the Gnome Hackers had done a fantastic job getting all the libraries right
As someone who's spent considerable time wrapping a few Gnome libraries in C++ when I was involved in Gtk--, and who finally switched to KDE for my development platform, I can assure you this is not the case. Far from it.
Both desktops may look similar in features from the user's point of view, but as a development environment there's simply no comparison.
> sometimes i want a dialog to leave one or more of its children alone. you can't do that in Qt.
I think you can. Set 0 as the parent. But on the other hand why would you want to do that ? If it's because the widget creation is slow, then it's not a problem with Qt : closing a dialog doesn't destroy the widget (unless you specify so), it just unmaps them.
> gtkmm offers full STL compatibility, which Qt does not
I have, so have many others, and the verdict is always the same : Qt is remarkably easy to use, including on large projects. Especially on large projects, actually.
> I know this, but the point is that when reading the code I have to know this - every time.
I understand, but in practice I really don't think it will take you more than 10 seconds to get used to it. Honestly.
> he makes an instance of class MyHandyClass and then doesn't free it ? I now have to look at the class definition to see if it is in some way derived from a Qt class [...]
But you'll have big hint on whether this is correct or not : the class ctor will have a "parent" QWidget (or QObject) argument. The context of the code will also be a strong indication.
And also, this is something common to most OO languages, you very often have to check what a class is derived from to make sure of how it should be used...
> I don't like cosmic class libraries because they force their policy on all my code,
But that's actually a good thing. That's one less thing to worry about, and less complexity to deal with.
> similarly I'm not too keen on those that break the core language idioms
I disagree. Every midly complex C++ class hierarchy will implement some kind of memory management policy, it will either be value-based or pointer based, etc... thus bending the idiom in his own way.
If a library leaves up to you the task of managing its memory, I think it's a failure. That was one of our main disagreements with Karl Nelson when I left Gtk-- actually, and it seems Murray Cummings (the current de facto maintainer), also thinks like you:-). But in practice, I still find it to be a huge asset.
> then that's wrong ? Again, I'm not being sarcastic, I just want to know....
Well, I've just checked in a small example and it seems I'm right.
> a common example of a bad class design practice that can work, but tends to break over time - that is giving a resource to someone else to manage.
But this is extremely common:-). And I'm not sure how you can avoid this in reality. Or if the added complexity of the code is worth the cost. I think that the only policy which scales well and withstand "real life" is to make an API as easy to use as possible, and choose your policies according to that, not according to what people know or might know. Exposing nuts and bolts because you think it might otherwise confuse people doesn't work.
And as far as "breaking over time" goes, I think that if Qt's design was brittle, KDE would have broken down a long time ago already.
Feel free to email me if you want to push this discussion further, as/. is a bit of a clumsy medium.
> so it costs me mental space to remember the exceptions
I suggest you look at Qt before saying this. You seem to make an awful fuss over an extremely simple rule : QObjects have parents, parents delete their children. That's all there is to it. In practice this means that I can do this :
QVBox *box = new QVBox(mainwindow);
new QLabel("a label", box);
new QLabel("another label", box);
and this is not a leak, because box owns the labels. I've been using Qt both at home and at work for almost two years. I've had to do a few emergency patches under pressure. This memory management paradigm has *never* been a problem, because it's so obvious.
> I'm just pointing out that I can't without something to help (thanks for the reply anyway)...
Come on, every C++ project above 2 kloc has to set some memory management policy for some classes. At some point you have to clearly specify "this object owns this one and is in charge of deleting it, while this other is not". That's one of the nastiest side of C++, and it's never straightforward. And for once, Qt handles this very well.
> see also my longer response to another's reply...
I've read it, it is flawed for two reasons :
- you are still perfectly allowed to delete a widget, it will unmap itself and tell his parent about it
- you generally don't "set" widgets, these aren't attributes you give to a class. You just create them and let them live.
I suggest you take a look at the Qt tutorial, it seems you're just building your opinion on Al Stevens' article.
> primarily the way that the framework breaks the "new/delete" idiom.
It doesn't break it, it hides it from you. That's what any good library should do, hide the complexity from the programmer.
> but for those who're using Qt/KDE is this a big concern ?
It's actually one of the biggest advantages of Qt over any C/C++ UI toolkit I know.
> Do you write a handler wrapper class around widgets that hides this mis-match, or do you just live with it ?
We very happily live with it. What would be the point of resisting this ? Qt frees you of having to delete Qt objects. That's one less chore you have to tend to, and a fairly nasty and error-prone one to boot. Why would you want to get it back ?
This is like saying std::string is bad because it frees you from allocating and freeing char arrays.
No, it's the best C++ toolkit currently available.
> but it's a crufty design that shows that it's older than many features of modern C++.
Basically none of these features are widely portable, so for all practical purposes, you'll be quite happy with what Qt provides. And Qt's design is actually extremely good.
> you think their signal/slot system and rtti system and such are "good."
The slot/signal system is very easy to use and very readable. As for their RTTI, you don't have to use it.
> Requiring moc? Wtf?
moc is hardly seen by the developper. I've done Qt development both at work and at home for two years now, it has practically never been a problem, except when dealing with MSVC project files.
> GTK-- is much, much nicer overall than Qt, from a C++ engineering standpoint.
Have you tried programming a large application with both ? I have. Do so, and see how quickly and how far each one gets you.
I don't know of a way to reliably count the memory used by several processes using shared libraries, and you don't indicate how you obtained this result so discussing it is pretty pointless. And even then, by today's standards it's not that big:-).
> A Java-based desktop would run within a single virtual machine, and it would likely come in far below that.
"would":-). Hard to say without actually developping it, right ? On my machine, the SwingSet2 demo from JDK 1.3, which merely exercises some widgets, takes about 50Mb resident, and about 200Mb shared. It doesn't load any data except for a few pixmaps. Are you really sure a whole desktop with text editor, web browser, mailer, etc... would be "way below 63Mb" ??
Plus how would it fork applications ? If they all run as threads, you loose memory protection. A single, bad behaving app can bring the whole desktop down, and we're back to how it was 10 years ago.
> Sun's JDK and Intel's (free) ORP come close to C++ speed
This is certainly not what I've experienced when I tried the JDK 1.3. The performance is vastly better than 1.2, but still very far away from C++.
> Java bytecode can easily be obscured so that it is no easier to decode than Pentium machine code
Yes, that's what we do at work and it's a huge pain in the ass for maintenance.
> you can compile it to native code and then load it as a native library
And lose the portability, and complicate the building and installation process even more.
Forgive my asking, but what experience do you have exactly with C++ and Java development ? I suddenly get the feeling you're still in college.
> It's still expense money, and it is still a large fraction of, if not more than, what is budgeted for each individual developer.
More expensive tools are routinely purchased everywhere.
> [...] and a few years later the project disbands and the people picking up the pieces are left with high software licensing costs and oddball tools that they can't get experienced developers for
So what do you suggest, that nobody should buy tools ?
Getting "experienced" enough with Qt enough so that you can be productive with it is a matter of days. Also, when new people take over an old project, the main problem is not the tools but what they've done with it, and how well that is documented.
> I claimed that at the time that KDE started, there were a number of free toolkits that were at least comparable in quality to Qt at the time.
Again, name one. I still claim there wasn't.
> Swing, in my opinion, beats Qt hands down.
I agree. Java beats C++ hands down, actually. But as of today, even with the huge progress of the last JDK, it's still not a viable solution for the typical desktop machine. Too slow, too big. And the fact that Java bytecode is so easily turned back into source code is also a major problem for commercial, licensed software.
> (And, no, you haven't even scratched the surface of toolkits available for Linux.)
I'm not going to list every single toolkit which I've looked at. And as far as I can tell, Qt simply has no contestants on Unix today. There are no other toolkits which can claim the same level of quality, feature-completeness, ease of use, documentation, freedom of use, and portability.
I'd be curious to see you naming one, actually.
> Obviously, you have no idea how corporate budgeting works
I've worked for several large and less large companies, among which IBM and Lucent, so I believe I do. Buying something like a software license is usually decided by a specific department, on request of a team. It's never the decision of a single engineer. The company I currently work for sells a toolkit for about 10 times the price of Qt, and we do have a lot of customers. And the company I previously worked for was also selling software licenses for several times the price of Qt.
It's the best development platform available on Linux today (and yes, I've tried Gnome, GnuStep and Tcl/Tk).
> It can't be because the functionality is missing from Linux
Yes it is.
> many of the KDE applications had excellent, free, non-Qt-based equivalents before the KDE project even started.
No (think integration here).
> And many of the KDE applications are easily implemented as little Tk or expect scripts.
Some may be, but far from all (Tcl scales very badly) but think integration again here. And looks too.
> Who actually benefits from this?
Users and application developpers.
> If I wanted a Windows-like environment, why wouldn't I just use Windows?
Openness, reliablity.
> And if KDE goes through all this trouble, why pick a toolkit that makes it more expensive for commercial entities to develop for KDE than it is to develop for Windows?
The cost of a Qt license is negligeable compared to the total cost of development of a typical desktop application. It's less than a month worth of salary for an average engineer.
> And why is KDE embracing an approach, large C++ libraries and dynamic loading of native code, that Microsoft is already beginning to abandon?
Because it works and there currently aren't any better alternatives.
Yes, bloat, but if you do not use the STL, exceptions, and RTTI, c++ binaries are about the size of c binaries.
You're taking it the wrong way. If you try to get the equivalent of the STL, exceptions and RTTI in C, you will get binaries even bigger than in C++, and unmaintainable code.
And yes, most of kde does not use RTTI, STL, and exceptions
Many KDE programs do use RTTI (dynamic_cast), I believe some use the STL but this is much less common. It's true that it doesn't use exceptions, mostly because the overhead is currently too big.
(Qt uses RTTI afaik, but it's not as big of a bloat maker as exceptions are).
No, Qt has its own "simili-RTTI" which isn't used in KDE because standard C++ RTTI is just as good if not better, and more general (you can use it on any class, while Qt's RTTI is for QObjects only).
I don't claim that. I claim that for a given problem (here, desktop application programming), some tools are better than others.
Many people find C to be much more efficient and logical that C++.
Yes, I agree. But again : that doesn't make them as efficient as someone else who's using C++ efficiently. They still have to type more code and to pay attention to more details.
personally, I find that Java and Gtk+ have moved me the most.
You haven't answered my question about Java. Suppose I claim that any C programmer can achieve the same work as you in Java, in the same amount of time, and with the same level of quality. Would you agree ?
Fewer lines of code != more logical, powerful, easy to use structure. Sorry.
Let me refine that : a language which lets you express the same logical pattern with fewer lines of code is more powerful. The bulk of the discussion was about derivation. The other guy claimed that it's just as easy to derive a class with GTK+ than with C++. Do you really think it's just as easy to cut'n paste a hundred lines than to just type "class Foo : public Bar" ?
For your needs QT is the best thing out there. For some people, C based OO systems like those used in Max/MSP, PD and Gtk+ are the best answer.
I'm not sure we are talking about the same thing here. I'm not taking specific requirements into consideration where for some reason you can't use Qt. I'm talking about how GTK+ and Qt compare in general. If for some reason you need to use GTK+, then fine. But that doesn't make it as easy to use as Qt. If you don't know or don't like C++ and Qt, and prefer to use GTK+, that still doesn't mean you're just as efficient as someone who uses C++ and Qt (unless he's a terrible programmer of course).
Sorry, counting lines of code is no proof for "ease" and power of a programming environment... if that were true visual basic would rain king.
I don't know VB so I can't talk too much about it, but given its usage rate and what you can do with just a couple hundred lines of code, yes, it seems that it's quite a powerful programming langage.
Ease of use is a subjective thing.
In some cases may be, where your own background warps your point of view (like you've been using the same language for so long that you can't learn anything else). But I fail to see how, needing 100 lines of code with language A and needing only 1 in language B to do the same thing can be "subjective".
it isn't gtk, and it starts with a J
OK, you're a Java programmer. Now suppose someone claims that it's just as easy to derive a class with GTK+ as with Java. Or that memory management is just as easy in C++ as in Java. Would you agree with those claims ?
thanks for that link to a a discussion of opinions
That's not a discussion of opinions, that's a discussion of me proving someone just like you that he's hopelessly wrong, although he obviously won't admit it.
By definition, the simplicity of a method is based on subjective opinion
Not in programming. Merely counting the number of code lines needed to achieve a given task or the number of pages of docs you have to go through to get there can at least give you a good hint of what is simple and what is not.
unfortunately for your silly argument, thousands of coders disagree with you and think that gtk+ is a joy to work with.
As I clearly state in the aforementionned discussion, I don't dispute that GTK+ is a bad toolkit. What I do claim is that Qt is much better, beyond any considerations of taste or personal preference, but just by looking at how quickly you'll get the job done using it, and how maintainable your code will be.
Deal with it.
I do, however just like the person I was discussing with (and most people who get somewhat sentimental over the tools they use) you seem to have trouble dealing with the opposite yourself. Hence the sarcastic and rather rude tone of your reply.
I'm not a Qt fan, I don't use it because I like it but because it's the best available tool for my needs (until Java becomes suitable for desktop apps). I just happen to know enough about both GTK+ and Qt to be able to correct you assertion than both are equals. They are not.
Slashdot Mirror
This isn't a debate pal, you've been slaughtered and now you're just whining pitifully whilst backing into a corner.
Absolutely. No really, the best one was "you say that memory management is bad, so why don't you use Java instead of C++ ?" Did you like this one too ? Such brilliant analysis of the problem, such in-depth grasp of all the issues...
Yes, yes, I confess, I'm a loser bad coder whiner and everything. I'm also paid by Microsoft and the KDE League to undermine the efforts of Gnome with my silly writings. There, I've said it. Ah, I feel better already.
Now, since you're so obviously a code master of skills way above mines, will you please further enlighten me ? Can you point me at the numerous incredible contributions which you doubtlessly have made to Gnome, so I can learn from them ? Please, pretty please ?
Even if that was true
Evolution : 17 full-time people during 2 years.
KMail : I think the core team is about 2 or 3 people, spare time.
Nautilus : 13 full-time devs, 1 year
Konq : around 4 people, 1 full-time, others spare time.
did you think that the reason most GTK project have more people is because C++ puts a lot of people off
Oh my god, no I never had thought of that. Gee, what a fool I was. Thank you so much for letting me see the light. I bow to your incredible debating skills.
Have you extensively used these bindings yourself ? I hereby challenge anyone to port Rosegarden to a GTK+ binding (any binding, Python, Perl, C++, pick one). Or even to write an app which has half of the features Rosegarden currently has.
See this for more details on the problem.
Have you tried comparing the respective ressources involved in the making of these apps ? Say Nautilus vs. Konq, Evolution vs. KMail. Check how many people worked on each of these, then match that against the apps features.
> Will a few 100kloc do?
Not in your case it seems.
I'm sorry, but claiming that mem leaks are "straightforward to avoid" in C++ simply proves you don't know what you're talking about. Go post this on comp.lang.c++.moderated and see what answers you get.
Really? What about Java and C#?
I should have been more precise : C++ is currently the best solution on Unix. Java is arguably gaining grounds on the Windows desktop, but AFAIK, except in some high end apps it's virtually non existent on the Unix desktop. As for C#, well, in its current state it's not a solution at all.
When language fashions change, where does that leave QT?
Not much I guess. But you seem to think that a C toolkit can magically turn into a good Java or C# toolkit just by "wrapping it". It's simply not the case. The result you get is quite sub-par compared to a library directly written in Java or C#, because C is so limited.
Plus both Java and C# come with a standard graphic toolkit (and most probably so will all forthcoming languages), so there's not much point in wrapping a C graphic toolkit with those.
Hi Murray,
:-).
I also know quite a few C++ lovers who very much like Qt, and who honestly think it uses C++ very well.
But there's nothing to like or dislike here. This is only a tool. I don't use C++ or Qt because I like them but because they're the best tool for my purpose.
Anyway, we've had this conversation before
Not everyone likes C++
No, but unfortunately it's currently the best solution for programming large desktop application.
Just compare the language bindings available for each. The number available for GNOME absolutely dwarfs those for KDE.
Yes, I know, each time this subject is brought up someone comes up with this argument. But how many of these bindings are actually complete, or even used ? How many applications are based on them ?
The point here is to develop useful working applications, not to herd wrappers for the sake of it. It's better to have a limited set of viable options than a large set of bad ones.
The Sun developers suggested that the Gnome Hackers had done a fantastic job getting all the libraries right
As someone who's spent considerable time wrapping a few Gnome libraries in C++ when I was involved in Gtk--, and who finally switched to KDE for my development platform, I can assure you this is not the case. Far from it.
Both desktops may look similar in features from the user's point of view, but as a development environment there's simply no comparison.
> sometimes i want a dialog to leave one or more of its children alone. you can't do that in Qt.
I think you can. Set 0 as the parent. But on the other hand why would you want to do that ? If it's because the widget creation is slow, then it's not a problem with Qt : closing a dialog doesn't destroy the widget (unless you specify so), it just unmaps them.
> gtkmm offers full STL compatibility, which Qt does not
Yes it does. Qt3's iterator are STL compatible.
We just released Rosegarden 4 v0.1.
> asking those who have done so
:-). But in practice, I still find it to be a huge asset.
:-). And I'm not sure how you can avoid this in reality. Or if the added complexity of the code is worth the cost. I think that the only policy which scales well and withstand "real life" is to make an API as easy to use as possible, and choose your policies according to that, not according to what people know or might know. Exposing nuts and bolts because you think it might otherwise confuse people doesn't work.
/. is a bit of a clumsy medium.
I have, so have many others, and the verdict is always the same : Qt is remarkably easy to use, including on large projects. Especially on large projects, actually.
> I know this, but the point is that when reading the code I have to know this - every time.
I understand, but in practice I really don't think it will take you more than 10 seconds to get used to it. Honestly.
> he makes an instance of class MyHandyClass and then doesn't free it ? I now have to look at the class definition to see if it is in some way derived from a Qt class [...]
But you'll have big hint on whether this is correct or not : the class ctor will have a "parent" QWidget (or QObject) argument. The context of the code will also be a strong indication.
And also, this is something common to most OO languages, you very often have to check what a class is derived from to make sure of how it should be used...
> I don't like cosmic class libraries because they force their policy on all my code,
But that's actually a good thing. That's one less thing to worry about, and less complexity to deal with.
> similarly I'm not too keen on those that break the core language idioms
I disagree. Every midly complex C++ class hierarchy will implement some kind of memory management policy, it will either be value-based or pointer based, etc... thus bending the idiom in his own way.
If a library leaves up to you the task of managing its memory, I think it's a failure. That was one of our main disagreements with Karl Nelson when I left Gtk-- actually, and it seems Murray Cummings (the current de facto maintainer), also thinks like you
> then that's wrong ? Again, I'm not being sarcastic, I just want to know....
Well, I've just checked in a small example and it seems I'm right.
> a common example of a bad class design practice that can work, but tends to break over time - that is giving a resource to someone else to manage.
But this is extremely common
And as far as "breaking over time" goes, I think that if Qt's design was brittle, KDE would have broken down a long time ago already.
Feel free to email me if you want to push this discussion further, as
> so it costs me mental space to remember the exceptions
...
I suggest you look at Qt before saying this. You seem to make an awful fuss over an extremely simple rule : QObjects have parents, parents delete their children. That's all there is to it. In practice this means that I can do this :
QVBox *box = new QVBox(mainwindow);
new QLabel("a label", box);
new QLabel("another label", box);
and this is not a leak, because box owns the labels. I've been using Qt both at home and at work for almost two years. I've had to do a few emergency patches under pressure. This memory management paradigm has *never* been a problem, because it's so obvious.
> I'm just pointing out that I can't without something to help (thanks for the reply anyway)
Come on, every C++ project above 2 kloc has to set some memory management policy for some classes. At some point you have to clearly specify "this object owns this one and is in charge of deleting it, while this other is not". That's one of the nastiest side of C++, and it's never straightforward. And for once, Qt handles this very well.
> see also my longer response to another's reply...
I've read it, it is flawed for two reasons :
- you are still perfectly allowed to delete a widget, it will unmap itself and tell his parent about it
- you generally don't "set" widgets, these aren't attributes you give to a class. You just create them and let them live.
I suggest you take a look at the Qt tutorial, it seems you're just building your opinion on Al Stevens' article.
> primarily the way that the framework breaks the "new/delete" idiom.
It doesn't break it, it hides it from you. That's what any good library should do, hide the complexity from the programmer.
> but for those who're using Qt/KDE is this a big concern ?
It's actually one of the biggest advantages of Qt over any C/C++ UI toolkit I know.
> Do you write a handler wrapper class around widgets that hides this mis-match, or do you just live with it ?
We very happily live with it. What would be the point of resisting this ? Qt frees you of having to delete Qt objects. That's one less chore you have to tend to, and a fairly nasty and error-prone one to boot. Why would you want to get it back ?
This is like saying std::string is bad because it frees you from allocating and freeing char arrays.
> Qt is really quite bad for a C++ project.
No, it's the best C++ toolkit currently available.
> but it's a crufty design that shows that it's older than many features of modern C++.
Basically none of these features are widely portable, so for all practical purposes, you'll be quite happy with what Qt provides. And Qt's design is actually extremely good.
> you think their signal/slot system and rtti system and such are "good."
The slot/signal system is very easy to use and very readable. As for their RTTI, you don't have to use it.
> Requiring moc? Wtf?
moc is hardly seen by the developper. I've done Qt development both at work and at home for two years now, it has practically never been a problem, except when dealing with MSVC project files.
> GTK-- is much, much nicer overall than Qt, from a C++ engineering standpoint.
Have you tried programming a large application with both ? I have. Do so, and see how quickly and how far each one gets you.
> 63Mbytes
:-).
:-). Hard to say without actually developping it, right ? On my machine, the SwingSet2 demo from JDK 1.3, which merely exercises some widgets, takes about 50Mb resident, and about 200Mb shared. It doesn't load any data except for a few pixmaps. Are you really sure a whole desktop with text editor, web browser, mailer, etc... would be "way below 63Mb" ??
I don't know of a way to reliably count the memory used by several processes using shared libraries, and you don't indicate how you obtained this result so discussing it is pretty pointless. And even then, by today's standards it's not that big
> A Java-based desktop would run within a single virtual machine, and it would likely come in far below that.
"would"
Plus how would it fork applications ? If they all run as threads, you loose memory protection. A single, bad behaving app can bring the whole desktop down, and we're back to how it was 10 years ago.
> Sun's JDK and Intel's (free) ORP come close to C++ speed
This is certainly not what I've experienced when I tried the JDK 1.3. The performance is vastly better than 1.2, but still very far away from C++.
> Java bytecode can easily be obscured so that it is no easier to decode than Pentium machine code
Yes, that's what we do at work and it's a huge pain in the ass for maintenance.
> you can compile it to native code and then load it as a native library
And lose the portability, and complicate the building and installation process even more.
Forgive my asking, but what experience do you have exactly with C++ and Java development ? I suddenly get the feeling you're still in college.
> It's still expense money, and it is still a large fraction of, if not more than, what is budgeted for each individual developer.
More expensive tools are routinely purchased everywhere.
> [...] and a few years later the project disbands and the people picking up the pieces are left with high software licensing costs and oddball tools that they can't get experienced developers for
So what do you suggest, that nobody should buy tools ?
Getting "experienced" enough with Qt enough so that you can be productive with it is a matter of days. Also, when new people take over an old project, the main problem is not the tools but what they've done with it, and how well that is documented.
> I claimed that at the time that KDE started, there were a number of free toolkits that were at least comparable in quality to Qt at the time.
Again, name one. I still claim there wasn't.
> Swing, in my opinion, beats Qt hands down.
I agree. Java beats C++ hands down, actually. But as of today, even with the huge progress of the last JDK, it's still not a viable solution for the typical desktop machine. Too slow, too big. And the fact that Java bytecode is so easily turned back into source code is also a major problem for commercial, licensed software.
> That's supposed to be an argument?
Yes.
> It's merely a statement of your beliefs.
No, of my experience.
> (And, no, you haven't even scratched the surface of toolkits available for Linux.)
I'm not going to list every single toolkit which I've looked at. And as far as I can tell, Qt simply has no contestants on Unix today. There are no other toolkits which can claim the same level of quality, feature-completeness, ease of use, documentation, freedom of use, and portability.
I'd be curious to see you naming one, actually.
> Obviously, you have no idea how corporate budgeting works
I've worked for several large and less large companies, among which IBM and Lucent, so I believe I do. Buying something like a software license is usually decided by a specific department, on request of a team. It's never the decision of a single engineer. The company I currently work for sells a toolkit for about 10 times the price of Qt, and we do have a lot of customers. And the company I previously worked for was also selling software licenses for several times the price of Qt.
> What is the motivation?
It's the best development platform available on Linux today (and yes, I've tried Gnome, GnuStep and Tcl/Tk).
> It can't be because the functionality is missing from Linux
Yes it is.
> many of the KDE applications had excellent, free, non-Qt-based equivalents before the KDE project even started.
No (think integration here).
> And many of the KDE applications are easily implemented as little Tk or expect scripts.
Some may be, but far from all (Tcl scales very badly) but think integration again here. And looks too.
> Who actually benefits from this?
Users and application developpers.
> If I wanted a Windows-like environment, why wouldn't I just use Windows?
Openness, reliablity.
> And if KDE goes through all this trouble, why pick a toolkit that makes it more expensive for commercial entities to develop for KDE than it is to develop for Windows?
The cost of a Qt license is negligeable compared to the total cost of development of a typical desktop application. It's less than a month worth of salary for an average engineer.
> And why is KDE embracing an approach, large C++ libraries and dynamic loading of native code, that Microsoft is already beginning to abandon?
Because it works and there currently aren't any better alternatives.
You're taking it the wrong way. If you try to get the equivalent of the STL, exceptions and RTTI in C, you will get binaries even bigger than in C++, and unmaintainable code.
And yes, most of kde does not use RTTI, STL, and exceptions
Many KDE programs do use RTTI (dynamic_cast), I believe some use the STL but this is much less common. It's true that it doesn't use exceptions, mostly because the overhead is currently too big.
(Qt uses RTTI afaik, but it's not as big of a bloat maker as exceptions are).
No, Qt has its own "simili-RTTI" which isn't used in KDE because standard C++ RTTI is just as good if not better, and more general (you can use it on any class, while Qt's RTTI is for QObjects only).
There is no one true tool.
I don't claim that. I claim that for a given problem (here, desktop application programming), some tools are better than others.
Many people find C to be much more efficient and logical that C++.
Yes, I agree. But again : that doesn't make them as efficient as someone else who's using C++ efficiently. They still have to type more code and to pay attention to more details.
personally, I find that Java and Gtk+ have moved me the most.
You haven't answered my question about Java. Suppose I claim that any C programmer can achieve the same work as you in Java, in the same amount of time, and with the same level of quality. Would you agree ?
Fewer lines of code != more logical, powerful, easy to use structure. Sorry.
Let me refine that : a language which lets you express the same logical pattern with fewer lines of code is more powerful. The bulk of the discussion was about derivation. The other guy claimed that it's just as easy to derive a class with GTK+ than with C++. Do you really think it's just as easy to cut'n paste a hundred lines than to just type "class Foo : public Bar" ?
For your needs QT is the best thing out there. For some people, C based OO systems like those used in Max/MSP, PD and Gtk+ are the best answer.
I'm not sure we are talking about the same thing here. I'm not taking specific requirements into consideration where for some reason you can't use Qt. I'm talking about how GTK+ and Qt compare in general. If for some reason you need to use GTK+, then fine. But that doesn't make it as easy to use as Qt. If you don't know or don't like C++ and Qt, and prefer to use GTK+, that still doesn't mean you're just as efficient as someone who uses C++ and Qt (unless he's a terrible programmer of course).
Sorry, counting lines of code is no proof for "ease" and power of a programming environment... if that were true visual basic would rain king.
I don't know VB so I can't talk too much about it, but given its usage rate and what you can do with just a couple hundred lines of code, yes, it seems that it's quite a powerful programming langage.
Ease of use is a subjective thing.
In some cases may be, where your own background warps your point of view (like you've been using the same language for so long that you can't learn anything else). But I fail to see how, needing 100 lines of code with language A and needing only 1 in language B to do the same thing can be "subjective".
it isn't gtk, and it starts with a J
OK, you're a Java programmer. Now suppose someone claims that it's just as easy to derive a class with GTK+ as with Java. Or that memory management is just as easy in C++ as in Java. Would you agree with those claims ?
That's not a discussion of opinions, that's a discussion of me proving someone just like you that he's hopelessly wrong, although he obviously won't admit it.
By definition, the simplicity of a method is based on subjective opinion
Not in programming. Merely counting the number of code lines needed to achieve a given task or the number of pages of docs you have to go through to get there can at least give you a good hint of what is simple and what is not.
unfortunately for your silly argument, thousands of coders disagree with you and think that gtk+ is a joy to work with.
As I clearly state in the aforementionned discussion, I don't dispute that GTK+ is a bad toolkit. What I do claim is that Qt is much better, beyond any considerations of taste or personal preference, but just by looking at how quickly you'll get the job done using it, and how maintainable your code will be.
Deal with it.
I do, however just like the person I was discussing with (and most people who get somewhat sentimental over the tools they use) you seem to have trouble dealing with the opposite yourself. Hence the sarcastic and rather rude tone of your reply.
I'm not a Qt fan, I don't use it because I like it but because it's the best available tool for my needs (until Java becomes suitable for desktop apps). I just happen to know enough about both GTK+ and Qt to be able to correct you assertion than both are equals. They are not.
No, it's an easily verifiable fact. Check here for a discussion why.