Ah, of course it is about algorithms as well, but STL simply fails to solve the basic problem - storing data. No algorithm will help you if you cannot store the data directly. Therefore you must store the pointer to data, with all troubles that it involves... That is why we have people wanting GC in C++ and other people trying to invent yet another kind of smart pointer...
Moreover, those algorithms are not as generic as they seem. E.g. std::list still needs its own sort etc...
Very stupid idea. If you want GC, why you do not use C# or Java?
You absolutely do not need GC in C++.
Using the right style and library, you can avoid all problems with resource management, without using GC or "smart" reference counting and create clean and easy to maintain code faster than in Python.
While I do not think "buffers" are the real problem of C++, I have to agree with "boost-cult" part.
I think the whole think started to sink when Bjarne hastily forced STL to become the part of language standard. STL looks very nice at first, but fails to solve the problem in real world.
In any case, it is a little but stupid to have container library unable to store objects in object oriented language (I know, C++ is called "multiparadigm", but objects are dominant part of language in many problem domains).
This in long term causes all these nice troubles and people wanting garbage collection in language, thousands of attempts to provide reference counted smart for various scenarious etc...
And then of course for some reason many "guru" C++ programmers found a new toy in templates and started all that lambda fun (which can be described as contest of writing better for_each loop).
What a pity. C++ is excellent (core) language, but it is seriously misused. And "C++ experts" live in sort of self-denial, solving problems nobody is really interested in.
If you are looking for alternatives, do not forget about Ultimate++ - www.ultimatepp.org, BSD licensed C++ platform, including IDE.
IMHO, Ultimate++ completely dominates not only other C++ development options, but is on par with scripting languages - with C/C++ exection speed.
Unfortunately, that "HO" is biased, as I am the member of U++ project team:-) Nevertheless, you can still try it to find out.
An introduction to U++ is here:
http://www.codeproject.com/useritems/IntroUpp.asp
and library overview here:
http://www.ultimatepp.org/www$uppweb$overview$en-u s.html
Ah, not, that is misunderstanding - by emulated it is meant that the platform code for widgets (like managing mouse events) is not used.
Theming widgets is another thing.
In reality, as long as there is not difference to the end user, why not. But for clarity of terms, Qt widgets indeed are emulated.
Oh.. and Qt does use native (not emulated) widgets for win/osx.
No, this is not quite true. It has own non-native implementation, but uses platform theming API to make them look native.
In the end, of course, there is little difference, as long as trolltech does it right. (And they do, otherwise people would not claim widgets are native;)
Incidentally, the best development platform for large projects in Linux/Windows is Ultimate++ (PocketPC in beta testing, MacOS support in development). BSD licensed, fast executables, very productive.
It contains TheIDE environment, which is specifically designed for large projects.
See
http://upp.sourceforge.net/
Mirek
Well, that is one interpretation, but I believe this is not correct.
Traditional CISC was using microcode and decoder that converted each CISC instruction into series of microcode operations.
The cornerstone of RISC architecture is that you make microcode your "public" ISA - that avoids CPU decoder and performs all or most instructions is single cycle.
Now see what modern CPU do: they convert input stream of "public" ISA instructions into internal microcode. Unlike old-time CISCs, they convert a couple of ISA instructions into single microcode instruction (while old CISCs converted single ISA instruction into many microcode instructions). Anyway, this is still closer to original CISC design than to RISC.
If you would like to call internal microcode machine a RISC, ok, but keep in mind that those instructions are specifically designed for its purpose and could not be used as external ISA for any CPU (ok, transmeta excluded:).
In other word, if your public ISA is not reduced and equivalent to microcode, it is not RISC CPU.
And then, on top of that, there is PowerPC G5 that interprets RISC ISA as if it was CISC ISA:)
> To be fair, CISC and moreover, RISC/CISC architectures "won" more due to
> marketing spin and the like. RISC is still superior technology, so logically
> it should have superceeded CISC and RISC/CISC.
To be really fair, RISC was made obsolete by superscalar architectures. The main advantage of RISC - simple decoder - is no longer important. Meanwhile, main disadvantage of some RISC architectures - bulky code - has bad impact on performance as it screws cache.
Note also that recent PowerPC designs (G5) mark the end of RISC era, as its superscalar architecture has quite complicated decored that converts ISA "RISC" instructions into internal "RISC" instructions, which makes it quite similar architecture to current x86 designs.
> And as the old Luna Lander had computer power equivalent to a modern average
> car, I'll expect the new ones will be far more advanced.
Actually, it had computer power equivalent to a 15 years old car. Computer equivalent of modern car were those IBM360 mainfraimes that were used down on the Earth to support the mission.
What about following that link to see some screenshots?:) Or, better, download and try.
Add 2. - I believe that development using U++ is as fast as with Python or Ruby, or even faster. At least, that is our goal.
Fair enough, anyway, there are no dirty trick in U++ code as well and it is in fact example aimed at novice programmers too.
The thing is that it is really hard to find good code that can be "translated" to "prove something". And even if you do try hard, you are always accused for not being fair anyway...
As we can hardly force Qt programmers to rewrite some of U++ code, the only option left is to rewrite some Qt code by us.
There are three layouts for the example - two are used as content for TabCtrl (Tab widget), third defines layout of dialog.
As for not being fair, well at least we have tried and separated Qt code that can be designed using visual tool.
Slashdot Mirror
Not many objects are copyable. It is hard to discuss if you have not noticed this simple fact :)
Ah, of course it is about algorithms as well, but STL simply fails to solve the basic problem - storing data. No algorithm will help you if you cannot store the data directly. Therefore you must store the pointer to data, with all troubles that it involves... That is why we have people wanting GC in C++ and other people trying to invent yet another kind of smart pointer... Moreover, those algorithms are not as generic as they seem. E.g. std::list still needs its own sort etc...
You absolutely do not need GC in C++.
Using the right style and library, you can avoid all problems with resource management, without using GC or "smart" reference counting and create clean and easy to maintain code faster than in Python.
See: http://www.ultimatepp.org/www$uppweb$overview$en-u s.html
(Disclaimer: I am biased member of team).
(Unfortunately, there is too many "experts" in the field to get such simple solution of the problem of "programming" widely accepted fast :)
While I do not think "buffers" are the real problem of C++, I have to agree with "boost-cult" part.
I think the whole think started to sink when Bjarne hastily forced STL to become the part of language standard. STL looks very nice at first, but fails to solve the problem in real world.
In any case, it is a little but stupid to have container library unable to store objects in object oriented language (I know, C++ is called "multiparadigm", but objects are dominant part of language in many problem domains).
This in long term causes all these nice troubles and people wanting garbage collection in language, thousands of attempts to provide reference counted smart for various scenarious etc...
And then of course for some reason many "guru" C++ programmers found a new toy in templates and started all that lambda fun (which can be described as contest of writing better for_each loop).
What a pity. C++ is excellent (core) language, but it is seriously misused. And "C++ experts" live in sort of self-denial, solving problems nobody is really interested in.
If you are looking for alternatives, do not forget about Ultimate++ - www.ultimatepp.org, BSD licensed C++ platform, including IDE. IMHO, Ultimate++ completely dominates not only other C++ development options, but is on par with scripting languages - with C/C++ exection speed. Unfortunately, that "HO" is biased, as I am the member of U++ project team :-) Nevertheless, you can still try it to find out.
An introduction to U++ is here:
http://www.codeproject.com/useritems/IntroUpp.asp
and library overview here:
http://www.ultimatepp.org/www$uppweb$overview$en-u s.html
Ah, not, that is misunderstanding - by emulated it is meant that the platform code for widgets (like managing mouse events) is not used. Theming widgets is another thing. In reality, as long as there is not difference to the end user, why not. But for clarity of terms, Qt widgets indeed are emulated.
Oh.. and Qt does use native (not emulated) widgets for win/osx. No, this is not quite true. It has own non-native implementation, but uses platform theming API to make them look native. In the end, of course, there is little difference, as long as trolltech does it right. (And they do, otherwise people would not claim widgets are native ;)
Incidentally, the best development platform for large projects in Linux/Windows is Ultimate++ (PocketPC in beta testing, MacOS support in development). BSD licensed, fast executables, very productive. It contains TheIDE environment, which is specifically designed for large projects. See http://upp.sourceforge.net/ Mirek
The reason is that C++ standard library clearly sucks...
Yes, because it is basically superscalar CISC design. RISC is not technical label anymore, just marketing thing.
Well, that is one interpretation, but I believe this is not correct.
:).
:)
Traditional CISC was using microcode and decoder that converted each CISC instruction into series of microcode operations.
The cornerstone of RISC architecture is that you make microcode your "public" ISA - that avoids CPU decoder and performs all or most instructions is single cycle.
Now see what modern CPU do: they convert input stream of "public" ISA instructions into internal microcode. Unlike old-time CISCs, they convert a couple of ISA instructions into single microcode instruction (while old CISCs converted single ISA instruction into many microcode instructions). Anyway, this is still closer to original CISC design than to RISC.
If you would like to call internal microcode machine a RISC, ok, but keep in mind that those instructions are specifically designed for its purpose and could not be used as external ISA for any CPU (ok, transmeta excluded
In other word, if your public ISA is not reduced and equivalent to microcode, it is not RISC CPU.
And then, on top of that, there is PowerPC G5 that interprets RISC ISA as if it was CISC ISA
> To be fair, CISC and moreover, RISC/CISC architectures "won" more due to > marketing spin and the like. RISC is still superior technology, so logically > it should have superceeded CISC and RISC/CISC. To be really fair, RISC was made obsolete by superscalar architectures. The main advantage of RISC - simple decoder - is no longer important. Meanwhile, main disadvantage of some RISC architectures - bulky code - has bad impact on performance as it screws cache. Note also that recent PowerPC designs (G5) mark the end of RISC era, as its superscalar architecture has quite complicated decored that converts ISA "RISC" instructions into internal "RISC" instructions, which makes it quite similar architecture to current x86 designs.
> And as the old Luna Lander had computer power equivalent to a modern average > car, I'll expect the new ones will be far more advanced. Actually, it had computer power equivalent to a 15 years old car. Computer equivalent of modern car were those IBM360 mainfraimes that were used down on the Earth to support the mission.
What about following that link to see some screenshots? :) Or, better, download and try.
Add 2. - I believe that development using U++ is as fast as with Python or Ruby, or even faster. At least, that is our goal.
The thing is that it is really hard to find good code that can be "translated" to "prove something". And even if you do try hard, you are always accused for not being fair anyway...
As we can hardly force Qt programmers to rewrite some of U++ code, the only option left is to rewrite some Qt code by us.
There are three layouts for the example - two are used as content for TabCtrl (Tab widget), third defines layout of dialog. As for not being fair, well at least we have tried and separated Qt code that can be designed using visual tool.
Designed using visual tool, but resizable (you can define resizing behaviour of layout).
Ultimate++
It is BSD licensed, it comes with IDE on both Linux and Win32, and it kicks ass for productivity.
See comparison with Qt.