Timeline for QT-C++ vs Generic C++ and STL
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 21, 2013 at 22:13 | comment | added | wirrbel | let us continue this discussion in chat | |
| Apr 21, 2013 at 12:55 | comment | added | Vector | You have lots of options with C++: I consider C++ to be 'the mother of all modern languages'. It's like the Latin of programming languages. | |
| Apr 21, 2013 at 12:52 | comment | added | Vector | Meanwhile I have to put together a tool chain that supports C++ 11. I use codelite right now - very nice IDE - but out of the box (GNU compiler) it doesn't support 11, as I just found out... Maybe I can plug an 11 compliant compiler into it. Not going to start in with D or Boo etc etc - as I said in question, I may have to hit the job market again fairly soon and I want to have the mainstream languages for marketability, not the 'one offs'. LOTS of Python jobs out there - too bad I can't stand Python any more! | |
| Apr 21, 2013 at 12:41 | comment | added | wirrbel | I think you got my point: You have lots of options with C++, with c++ you must choose wisely. Smart pointers, etc. have problems as well. Fed up with C# you might take a look at dlang.org which does lots of things better (GCed). | |
| Apr 21, 2013 at 12:22 | comment | added | Vector | So how about C++ 11? smart pointers etc would seem to alleviate many of your concerns. I am just starting to mess with it now. As I said, I agree that Qt KICKS BUTT. My plan is to use Qt for GUI and do whatever else I can using C++ 11 - which seems to render a good deal of Boost, for example, obsolete and closes to a large extent the gaps between Java/C# and old school C++. I get the feeling (at this point from a distance admittedly) that a combination of Qt and C++ 11 can be a big winner. | |
| Apr 21, 2013 at 11:25 | comment | added | wirrbel | this is not a problem of 10000 UI Objects but for complex tree datastructures with a million entries, etc. where once could resort to smarter ways of allocating things (Bulk allocation or lots of smartly written boost classes, etc.). Conclusion: the heap is not bad, it has to be smartly used. The Qt way sometimes does not scale for other stuff. It is still a fabulous toolkit in my opinion. | |
| Apr 21, 2013 at 11:08 | comment | added | wirrbel | the point I was trying to make is not that heap allocation is generally bad, it is just not the best thing for local variables. GUI classes tend to live long and are best allocated on the heap, local variables that are only temporarily needed live well on the stack. in C# with Garbace Collection they will be soon destroyed, so heap is also okay. But with manual new/delete calls this is not so easy and error prone. In critical sections (handling big data) this can make a difference, especially delete calls can be quite slow. | |
| Apr 21, 2013 at 8:00 | history | answered | wirrbel | CC BY-SA 3.0 |