Quote:
It's actually a pretty rare programmer whose hand-rolled last-year's technology can beat this year's compiler optimisations.
I'd say this is a big misconception, too. People think that the compiler has some magic ability to go in and do wonders and that somehow with the stl that it's even better and these super advanced programmers (who mainly wrote this code 15+ years ago) have some secret mojo no one else does.
But the reality is the compiler is generally good at inlining, and good at return value optimization and good at rearranging order for pipeline execution. You might get a little better if you mess with compiler specific directives but to get simd generated out for example you need to do it yourself.
Quote:
It's certainly not possible without having a profiler
Profiler is another misconception, it's like saying you need a debugger to figure out bugs. It's just raw data, it catches things that amount to mistakes but it really tells you very little. Like the debugger, it is easy to misuse as a crutch that negates actual thought - it's not there to debug logic, but to catch simple mistakes and that's it.
Quote:
and it's amazing how many people who haven't written line 1 of their software are spending their time thinking about how to optimise things. People who haven't ever written a game, haven't ever finished a bit of software are fretting that their game is SO special that it will put SUCH stress on machines that they need to START writing in assembly or without
Well sure, it is always the case you can preoptimize things.
It's also easy to assume everyone on a site like this is a 15 year old game enthusiast or a college student but that's not necessarily the case and I'd bet there are also some of the best programmers in the world hanging around.
@Rydinare
This is sort of disjoint since I won't go through and edit everything for nine hours just to make a message board post.
But, just because you don't see something doesn't make it not so.
Most programs don't need to worry a lot about code size or performance, but most programs don't need to be written in C++. It's easy to get gigabytes of object files in C++, though.
The point of macros is metaprogramming, too. Templates were introduced as a replacement, because they work ok for little stuff but they are hard to deal with when making something large. I don't say anyone who uses macros is incompetent, but a template library programmed almost entirely in macros is pretty ironic and shows that it's probably not someone who should be listened to much. But, free has a big appeal.
Yes, other languages did learn from C++ mistakes. That's why they don't use C++ templates at all, but what does that have to do with anything? My point is not to bash on anybody, just to point out reality. The fact C++ has been left in the dust should say a lot about many of C++'s features.
I know templates are not OO, I'm the one who said it. Most people who talk about stl, design patterns, and OOP in C++ are pretty vague on what OOP is and how templates work. Or more likely, simply dead wrong. But, it's unsurprising because the way templates and C++ in general work is beyond mindboggling if you really look at it in detail.
People drop to c array because of performance, not size. I said nothing about resizing. You can also preallocate a vector, but that's not the real issue.
Sure you can trace through anything, but good luck with that using stlport or dinkumware, or probably any other big template library. But more important, what assembly gets generated? The point is not to look for mistakes but to find out why things slow down. This is possible but much harder with templates, almost impossible when you have complicated things going on (which almost anything in the stl qualifies as).
Who said I microoptimized anything? How would ten years passing have changed how stl works? Most of stlport was written 15+ years ago and has not changed a whit as far as I can tell in that time, whereas what qualifies as optimal code today has changed dramatically because hardware has changed dramatically. Sure computers can perform most tasks faster than ever, but again it comes to why are you using C++ if you don't care about performance? For some things you basically get paid in direct proportion to how much of x you can do, or even in exponential proportion. If Modo could handle 20 billion poly models would they be languishing in obscurity while zbrush has a dozen times the customers? Modo is certainly easier to use and it has all the same basic features, but bottom line is it's useless for most of what zbrush does so well simply due to not having the raw firepower.
How does stl solve almost anything? This came up as a discussion about data structures, if you remember. You (and I) are only talking about vectors because that's about all there is worth noting in stl. If that's all you need for data structures, you probably are mistaken to use C++ at all. I'd almost say the entire reason to use C++ at all compared to say Java is to be able to make specialized APIs. Of course if there is some API you need that's only in C++ then you are stuck with C++, but the real point is so that the people writing the API can have performance and flexibility and in turn use other low level APIs. Say you want to make something akin to Oracle or a game engine. Do you really think STL will cover your data structure needs? Well, it won't even scratch the surface. However if you are just some guy who uses Oracle or a game engine's built in stuff and make GUIs on top of it, by all means don't worry about data structures they use at all, because it's out of your hands anyway. If that's the case, drop C++ completely if you can and use C# or mono or python or Java to call on their API to do the actual work. But you can be pretty sure that somewhere in those programs there's a lot of work that went into various data structures.
If you want to convince yourself stl is a joke, just make a class with a vector of ints and a couple other primitive members, basically a typical object of some kind. Then make a vector of these classes, each with a dozen ints in the child vector. Add about a million to the vector, then sort it and see how long that takes to complete(for comparison, I can run the same code with my own implementation in about 150ms). Also note how awkward this is, syntactically speaking. Sure, you can blame the implementation, but the implementation is going to be different on each platform and yet tend to universally suck because. Also check the difference between what you get with a static array and a vector, I know that put a sad frown on my face.
[Edited by - phantom on February 25, 2010 3:42:16 AM]
