Hi
I asked How modern is C++ language used in Qt? (http://stackoverflow.com/questions/846015/how-modern-is-c-language-used-in-qt) on StackOverflow.com
If you have your opinion please write your answer to this question there.
Thanks.
Printable View
Hi
I asked How modern is C++ language used in Qt? (http://stackoverflow.com/questions/846015/how-modern-is-c-language-used-in-qt) on StackOverflow.com
If you have your opinion please write your answer to this question there.
Thanks.
Definitely not and please stop making such type of dumpy announcement for your(?) site...Quote:
Originally Posted by piotr.dobrogost
I think, in addition to being a very good extensive framework, qt is somehow a wrapper for the c++ too!
It has modernized c++'s use.
and have an easily acceptable compromise (regarding performance/programming power/compatibility) in doing so.
I think a new standard c++ can make it somewhat better, not a lot, since it already has implemented (by the API/Qt itself) much more than how much these standards modernize c++.
It's not any kind of announcement and your replay is rude.Quote:
Originally Posted by Lykurg
As to site's owners - you can check yourself who they are if you're so suspicious :)
It doesn't matter if you are the owner of the site or not. Both threads you have posted in (making a total of 100% of your posts) is about that site (and nothing more) which is a bit suspicious.
The question of yours is, sorry to say that, quite lame and speaks very badly of you and/or your programming skills which makes your posts even more suspicious - they do look like ads.
I'm removing the links. If you prove yourself, I will bring them back.
And to answer your question:
This is completely false. Using non-approved standards makes the API less robust, less flexible and harder to use because there are more restrictions applied on the compiler thus there are fewer environments running compilers compliant to those would-be standards. "Newer standards" are (or should be) backwards compatible therefore if you really want to, you can build Qt with a compiler switched to something non-standard and it will (should) build fine. It wouldn't work the other way round. Qt uses modern solutions but only those that are pure C++. Thanks to that it's not a big problem to port it to yet another platform.Quote:
Using modern C++ language in API makes it more robust, flexible and easier to use.
And for your information - there is only one C++ standard, from 1998 (and updated five years later, but it's still the same standard). There is also C++0x which is a candidate for becoming a standard but thus far it's still in research. Being "too modern" already backfired once in C++ history - Microsoft released their Visual Studio 6 toolset a day before C++ standard was accepted which made VC6 non-compliant to C++ causing many problems to thousands of developers all over the world.
http://en.wikipedia.org/wiki/C++0x
http://en.wikipedia.org/wiki/Technical_Report_1
http://en.wikipedia.org/wiki/ISO/IEC...guage_standard
Cheers!
By the way Qt is not a wrapper over C++.
Ok, then I must admit that we have a fundamental different understanding of announcements.Quote:
Originally Posted by piotr.dobrogost
Well let's see and do some hermeneutic researches:Quote:
and your replay is rude.
is telling you that I am not intending to answer your question on another board. That's my free decision. Can't see any rudeness in that. But one could say suggesting peoples - two times in two threads of total - to visit another page and answer there, which means catching peoples from one forum to another, is a little bit discourteous.Quote:
Definitely not
Notice the "please". It indicates that the following statement kindly request. What I have omitted is a "in future".Quote:
and please stop making such type
Well, is "dumpy" rude. I don't think so, especially when you reconsider your first post. And even this one is a really short one with only one aim: move peoples to the mentioned site. Because there you have already a lot of answers and commentaries and no really need of more answers is visible.Quote:
of dumpy announcement
To indicate that I am not sure if you the owner of the site (nic.com was not useful on that) i have put the (?). But because of your posts, it strongly seems so.Quote:
for your(?) site...
So, reconsidering all these facts i came to the conclusion: No my answer wasn't rude. Maybe not the nicest one, but rude definitely not. Rude answers of mine look different.
If you asking yourself, if this post now is rude, perhaps... (I'm not sure about it myself!)
Peace, people, peace :-) Make Qt, not war ;-)
You don't have to choose, you can make both! *harrrharrr*Quote:
Originally Posted by wysota
http://www.qtcentre.org/forum/attach...1&d=1243631473
I'm trying to bring attention of users of qt to qt question which I raised on very popular programming site. How is this suspicious? How is this a bad thing? Do you know the word collaboration?Quote:
Originally Posted by wysota
You are angry because I brought attention of qt users to a place where they can also help other qt users by answering their questions?
When I send information about qt questions on stackoverflow to Henrik Hartz he was grateful not angry as you. You should learn from him...
I'm not even going to say how your answer speaks of you - readers of your post can judge this by themselves.Quote:
Originally Posted by wysota
I could do this very easily because I live 30km from you but I won't because what you did and what you're saying is ridiculous to say the least.Quote:
Originally Posted by wysota
Who was talking about using non-approved standards?Quote:
Originally Posted by wysota
Everyone at least remotely interested in C++ know these facts for years...Quote:
Originally Posted by wysota
Pure nonsense. VC6 wasn't standard-compliant because MS didn't care about C++ standard at that time. When they did start to care years later they hired Herb.Quote:
Originally Posted by wysota
Cheers!
I asked to answer my question there because I had already asked this question there in the first place.Quote:
Originally Posted by Lykurg
Besides on the mentioned site (I'm afraid if I can write it's name at all here) there are other Qt related questions which users of this site might want to answer and help others. I don't expect from you to understand this, however.
If you think this forum is the only one under the sun it's really only your problem.
If you want to pretend this forum is the only one by forbidding to even mention others you should read some Orwell's literature :)
It's suspicious because you register to the site and in the first posts of yours you provide links to an external site asking for attention to it. There are policies on many sites that prevent fresh users from posting any links. We don't have such policy here but we're keeping an eye on any URL that appears on this site.Quote:
Originally Posted by piotr.dobrogost
I think I already explained it but it's never enough to stress that preventing spam is much easier than fighting it.Quote:
How is this a bad thing?
Sorry, but accusing us of the lack of will of collaboration is ridiculous :-) If you want collaboration then start helping people. Once you do that, nobody will mind if you post a link or two, even if they consider them ads, "trafic rerouters" or pagerank stealing.Quote:
Do you know the word collaboration?
I'm not angry at all. You have a right to post links to any site you want. As long as this doesn't hurt users of this site, it is fine with me. You can see the links are still there, only that web spiders won't be picking them up.Quote:
You are angry because I brought attention of qt users to a place where they can also help other qt users by answering their questions?
Again, I'm not angry. I'm angry when someone forgets to use [code] tags despite earlier notifications from the staff. This is not the case here. If I'm angry about something in your post then it's the content of the question you asked because it's almost bound to inflict a flamewar (which I love, by the way) but not about pure fact of posting.Quote:
When I send information about qt questions on stackoverflow to Henrik Hartz he was grateful not angry as you. You should learn from him...
Yes, I can be very direct in my posts. I'm also very radical, strict and conservative when it comes to programming. I'm aware of that but that's the way I am. But I'm also accepting criticism directed to myself. Just go to my thread about wwWidgets and criticize, I do deserve that because my laziness (or lack of time) once again proved its point.Quote:
I'm not even going to say how your answer speaks of you - readers of your post can judge this by themselves.
I think you misunderstood me. I meant you have to prove yourself on the forum by asking or answering questions about Qt, not visiting Warsaw and shaking my hand... If you want to shake my hand or tell me straight into my face what you think of me then I would strongly suggest you go to DevDays to Munich in October - it's a great event (fact or crap?) so even if I don't make it there and you don't have a chance to laugh into my face you will still enjoy it and it will be time well invested. Besides, you'll be able to ask Qt Software developers in person why they use so outdated concepts in their code.Quote:
I could do this very easily because I live 30km from you but I won't because what you did and what you're saying is ridiculous to say the least.
Considering the fact there is only one standard and you were speaking about something "modern" and "old" (so mentioning at least two distinctive things) then I guess I meant you. If I misunderstood you, then that's my fault, sorry. But then you should probably explain what you meant if you weren't talking about standards.Quote:
Who was talking about using non-approved standards?
So why make a FUDD about Qt using some "old" dialect of C++?Quote:
Everyone at least remotely interested in C++ know these facts for years...
Ok, have it your way. Everyone has a right to his own opinion or interpretation of ones words. Still, I'm willing to comply that God doesn't play dice with the world.Quote:
Pure nonsense. VC6 wasn't standard-compliant because MS didn't care about C++ standard at that time.
I'm very curious what you consider so old in Qt's API. Would you share your opinions with us? Because I always thought Trolls have used bleeding-edge concepts in their code, often working around broken compilers (mostly VC6 and Borland) to make them support their code for as long as possible.
@Lykurg: You are killing me with your pictures :-)
Philosophical/sophistical side thought: So you want that all answers are made on the initial board. Is that collaboration? Or is it just because you think that that is the only place under the sun where this question can be answered...Quote:
Originally Posted by piotr.dobrogost
First you can speak about other sites here. No problem at all. Second, I understand much more than you might think...Quote:
Besides on the mentioned site (I'm afraid if I can write it's name at all here) there are other Qt related questions which users of this site might want to answer and help others. I don't expect from you to understand this, however.
I don't think that way.Quote:
If you think this forum is the only one under the sun it's really only your problem.
Instead of reading sophisticated literature and making name dropping afterwards you may should take some minutes and consider if maybe not the mention of other boards is the problem but more the way of your threads.Quote:
If you want to pretend this forum is the only one by forbidding to even mention others you should read some Orwell's literature :)
Eventually a post starts like
"I already asked this question at xyz but would be interested what you think about..."
wouldn't had caused this reactions.
I also would like to know how the people of stackoverflow had had react if a new member post two post where he suggest to go to another board to answer question there, without showing any interest (and help) on their own board. Unfortunately we won't figure it out...
According to my secret plan to take over the reign of that forum, that was the ambition :D But since you have recovered the conspiracy, I will desist from it.Quote:
Originally Posted by wysota
And yeah, sometime I have these rare moments of brilliant brilliancy that lead to those pictures... Sadly not often enough.
You mean stackoverflow.com? :)Quote:
Originally Posted by piotr.dobrogost
The truth is we are hardly keeping up with answering the ones here.Quote:
there are other Qt related questions which users of this site might want to answer and help others.
It might be good for you to go back in history and find out why this site was established in the first place and where did the people who founded it migrate from.Quote:
If you think this forum is the only one under the sun it's really only your problem.
If you want to pretend this forum is the only one by forbidding to even mention others you should read some Orwell's literature :)
We don't have to figure it out. This is crossposting and is very often considered spamming just by itself, regardless of the content. Especially now that we have so good search engines that crossposting doesn't improve "findability" of a problem.Quote:
Originally Posted by Lykurg
http://en.wikipedia.org/wiki/Crossposting
Better luck next time! By the way - you really don't want to rule here... Trust me.Quote:
Originally Posted by Lykurg
Maybe one day we can compose a gallery from your art :]Quote:
And yeah, sometime I have these rare moments of brilliant brilliancy that lead to those pictures... Sadly not often enough.
1. What about using plain pointers in API?Quote:
Originally Posted by wysota
2. What about not using exceptions to communicate errors?
3. What does Qt do to support standard containers?
Can I use standard container in every place I can use qt container?
If the answer is not does qt provide adapters at least?
(Bear in mind a string is a container, too.)
4. What does Qt do to make it easy to use its containers with the rest of the Standard
Library?
Does Qt provide adapters so that I could use qt container in every place I can use a
standard one?
These are the things that come to mind when one uses any C++ library.
5. Has anyone from Qt checked how much of moc could be implemented with features
found in current standard?
Has this been tried with features from upcomming standard?
6. Is there any official document stating what's Trolltech/Nokia position with regard to
using new language features?
These are Qt specific questions.
I'm sure I'll have more questions in the course of learning and using Qt.
What's wrong with that? Nobody prevents you from wrapping them in some smart pointer classes provided you know what you are doing.Quote:
Originally Posted by piotr.dobrogost
C++ exceptions suck.Quote:
2. What about not using exceptions to communicate errors?
If by "standard" you mean std::vector and family then Qt containers have conversion methods to and from STL counterparts.Quote:
3. What does Qt do to support standard containers?
No, because there are platforms without STL implementations (or with broken ones) so in those situations you have to use Qt containers. Apart from that Qt containers and STL containers are API compatible. Qt containers tend to be faster, though. And of course they have some methods STL ones don't, i.e. QString::split().Quote:
Can I use standard container in every place I can use qt container?
I guess I already answered that.Quote:
If the answer is not does qt provide adapters at least?
QString::fromStdString(), QString::toStdString(), QString::fromStdWString(), QString::toStdWString(). Enough? Bear in mind std::string is not Unicode compatible so you might experience loss of functionality.Quote:
(Bear in mind a string is a container, too.)
You can use Qt containers with STL algorithms.Quote:
4. What does Qt do to make it easy to use its containers with the rest of the Standard
Library?
No, because they are compatible. No adapters are required.Quote:
Does Qt provide adapters so that I could use qt container in every place I can use a
standard one?
I guess that's settled then.Quote:
These are the things that come to mind when one uses any C++ library.
Oh, this has already been argued - "use templates instead of moc". I can redirect you to the documentation, that's a big topic. Bottom line is moc gives you some benefits that wouldn't be possible with templates and you don't have to use moc if you don't want to - use Boost signals.Quote:
5. Has anyone from Qt checked how much of moc could be implemented with features
found in current standard?
This I have no chance of knowing but I guess the word "upcoming" says it all. I think once all supported platforms have compilers supporting C++1x (there is no way it's going to be called 0x, it's already 2009) we might return to the topic but now this is only academic talk bearing the fact C++1x is still fluctuating.Quote:
Has this been tried with features from upcomming standard?
I'm not aware of such document. If you're interested in it, I think contacting Matthias Ettrich would be the best way of answering your question.Quote:
6. Is there any official document stating what's Trolltech/Nokia position with regard to
using new language features?
Please ask them, we'll try our best to answer them.Quote:
I'm sure I'll have more questions in the course of learning and using Qt.
Edit: by the way, C++1x (or 0x, whatever you want to call it) will not be any revolution compared to C++03. It will just make some things easier for developers but there will be no sense in rewriting code that is already written unless you have situations where the new standard will yield an execution performance boost. Again, nobody prevents you from using a C++0x compiler with Qt even now.
Good API doesn't return dangerous plain pointers waiting for its users to make the first mistake.Quote:
Originally Posted by wysota
Really. Where have you read this? Who made you think so?Quote:
Originally Posted by wysota
At least.Quote:
Originally Posted by wysota
Better yet just use standard containers :)
From Inside the Qt 4 Containers
Implicit sharing is the main difference between QVector and STL's std::vector<T> class.
That made me really laugh :)
What have they been thinking?
Something like Instead of combing two standard features lets make it even harder for users and create our own (better as always) moc-vector?
That would be too easy for users to use and too standard for Trolltech to even think of.
If you can implement Qt containers (which don't bring anything new besides yet another api) on such platforms you could have implemented STL ones in the first place...Quote:
Originally Posted by wysota
Yep, I'm sure they are much better than the ones written by several world class c++ specialists in the course of a couple of recent years. Should Bjarne immediately start learning from Trolltech's stuff?Quote:
Originally Posted by wysota
By the way - do you have any evidence?
Wow. I'm really impressed.Quote:
Originally Posted by wysota
I guess that's about 2% of what you already have in Boost String Algorithms Library which works with guess what... std::string of course.
Please do.Quote:
Originally Posted by wysota
For these some benefits all users of Qt have to pay because they are forced to use moc even if they would like to avoid it. That's absolutely not in the spirit of C++.Quote:
Originally Posted by wysota
I guess some benefits make about 20% of what moc does. Why doesn't Qt incorporate Boost signals for all these users using the remaining 80% of moc? And let these 20% use moc, moc2, super-extra-ultra-moc and other very valuable inventions of Trolltech trying to make from static C++ a dynamic language.
Thank You Good Lord, guys involved in GCC and other compilers don't think in the same way you do :) Otherwise we would have had conforming compilers about 20 years after each standard gets ratified.Quote:
Originally Posted by wysota
Just read his Designing Qt-Style C++ APIs.Quote:
Originally Posted by wysota
Most C++ books recommend references whenever possible, according to the general perception that references are "safer and nicer" than pointers. In contrast, at Trolltech, we tend to prefer pointers because they make the user code more readable.
Yep, Trolltech always knows better.
No, it won't as long as libraries' creators will keep using old features instead of the new ones forcing, by doing this, their users to do the same :)Quote:
Originally Posted by wysota
Ah, come on! Remember what you have accused me, that I would think qtcentre is the only forum? And now your statement is that references are the only holy solution, and Qt uses this bad pointer stuff.Quote:
Originally Posted by piotr.dobrogost
Beside, this are two possible and legal ways, which both have their advantages and disadvantages. There is objectively no right solution. This is how democracy work, majority and minor thought about one topic. This is also a issue with which Orwell has dealt in his Romans...
And your whole argumentation is very sarcastic and not always objective. If you don't like the Qt way you have two options, don't use it or change it. Qt is LGPL, so you have all freedom to alter the code.
Qt doesn't return any "dangerous" pointers. I agree there are places where pointers might be hidden inside explicitly shared classes but it's not possible to eliminate all pointers in C++ due to the nature of polymorphism.Quote:
Originally Posted by piotr.dobrogost
I didn't have to read it, it's a widespread opinion :-) For example if you throw an exception there are cases where destructors of objects created inside the faulty block will not be called. If there is anything positive I can say about Java is that it has much better exception model than C++.Quote:
Really. Where have you read this? Who made you think so?
If standard containers are worse, I don't really see a point in squeezing them into my code just because they are inside a library that has the word "standard" in its name.Quote:
At least.
Better yet just use standard containers :)
Yes! Love'em flamewars!Quote:
From Inside the Qt 4 Containers
Implicit sharing is the main difference between QVector and STL's std::vector<T> class.
That made me really laugh :)
Would you care to explain? And what does moc have to do with vectors?Quote:
What have they been thinking?
Something like Instead of combing two standard features lets make it even harder for users and create our own (better as always) moc-vector?
Well, that's not the same. Implicit sharing is "copy on write". What you have presented here is more close to explicit sharing. And by the way, your code is not valid C++.Quote:
That would be too easy for users to use and too standard for Trolltech to even think of.
They do, only that you obviously fail to see that :-)Quote:
If you can implement Qt containers (which don't bring anything new besides yet another api)
Well, that's not the job for the Trolls...Quote:
on such platforms you could have implemented STL ones in the first place...
Instead of being sure you can just do some benchmarks.Quote:
Yep, I'm sure they are much better than the ones written by several world class c++ specialists in the course of a couple of recent years.
Well, I don't see what would be wrong in that but that's not the issue. There are situations where STL containers are faster, there are situations where Tulip containers are faster. The problem with STL containers is that they have to be backwards compatible in the way they do their tasks so there is not much space for improvements. There is also a matter of memory footprint which is different for both sets.Quote:
Should Bjarne immediately start learning from Trolltech's stuff?
Yes. Here is something to start with:Quote:
By the way - do you have any evidence?
http://labs.trolltech.com/blogs/2006...it-worth-it-2/
http://labs.trolltech.com/blogs/2006...the-benchmark/
http://lists.trolltech.com/qt-intere...ad00118-0.html
Are we talking about standards or 3rd party additions? Your argument is that a 3rd party library is not better than a standard one because there is another 3rd party library that extends the standard one with capabilities of the former 3rd party library. Just read it and think if you didn't score an own goal here...Quote:
Wow. I'm really impressed.
I guess that's about 2% of what you already have in Boost String Algorithms Library which works with guess what... std::string of course.
Feel redirected.Quote:
Please do.
Name two such users. I guess one is yourself so finding another one should be easy... Just please find a person who can trully argument why he/she would like to avoid moc.Quote:
For these some benefits all users of Qt have to pay because they are forced to use moc even if they would like to avoid it.
Argue with project managers if they want to keep the spirit of C++ or sell software and earn money from it. If running moc is the "price" they have to "pay" for being able to build software easily, almost all of them will prefer that to tornments with "spirit of C++". Although I don't know what is not in the spirit of C++ in running moc... Building C++ based application involves calling at least four distinct tools - preprocessor (cpp), compiler (g++), assembler (platform dependant) and linker (ld). Does it really break the spirit if you add yet another one somewhere inbetween cpp and g++?Quote:
That's absolutely not in the spirit of C++.
AFAIK the concept of signals was born in Trolltech so I don't see why would they incorporate boost signals. I can see a reason not to, of course, and that's licencing.Quote:
Why doesn't Qt incorporate Boost signals for all these users using the remaining 80% of moc?
But yet again - nobody forces you to use Qt signals. You can use boost signals in your code and Qt won't mind.
I guess you should argue with your idols because they are trying to make C++ more dynamic as well...Quote:
And let these 20% use moc, moc2, super-extra-ultra-moc and other very valuable inventions of Trolltech trying to make from static C++ a dynamic language.
Bear in mind Qt is much different than a compiler so comparing the two is not a good idea.Quote:
Thank You Good Lord, guys involved in GCC and other compilers don't think in the same way you do :) Otherwise we would have had conforming compilers about 20 years after each standard gets ratified.
And I'm pretty sure GCC is not built using C++0x but using the current standard. So is Qt. GCC allows you to use C++0x, so does Qt. So after all I'm leaning towards thinking that they do think as I do.
It's a convention and you don't have to follow it. I learned it to be a good convention. I'm working with code that uses references as mutable input parameters and such code is very hard to read - you have to find a declaration of the method each time you see it used to check if any of the arguments passed are not by any chance references. Unfortunately C++ doesn't give us any hint about such cases. Using ampersands as such a marker is a workaround over C++ call syntax.Quote:
Most C++ books recommend references whenever possible, according to the general perception that references are "safer and nicer" than pointers. In contrast, at Trolltech, we tend to prefer pointers because they make the user code more readable.
Yep, Trolltech always knows better.
What you say is very idealistic but it's not a bit realistic. If you have production code, you can't enforce instabilities or fluctuating code. Please name one large C++ library that has a known brand that forces its users to use C++0x compilers.Quote:
No, it won't as long as libraries' creators will keep using old features instead of the new ones forcing, by doing this, their users to do the same :)
This is my personal subjective opinion but I think so far I've been able to knock aside each and every argument or statement of yours. So before replying to this post (which I of course strongly encourage you to do) stop mocking and read a bit of resources on Qt, starting with its reference manual. Giving statements about Qt (in)compatibility with STL containers before even taking a look at its API was a really bad idea, it just made you look like a troll (with lowercase "t", not to confuse with Qt developers).
What is beautiful about Qt is that it doesn't prevent you from keeping your coding habits and it doesn't force you to use solutions you don't want to. Take exceptions - Qt doesn't throw any exceptions but it won't break your exception-aware code. The only restriction I was able to find in Qt is that it doesn't allow you to multiply inherit QObject. And there is a limitation to moc that you can't use Q_OBJECT macro in template classes but that's not a big problem, there are ways to overcome that.