Geeking out with STL?

[dswigger]

You know I was looking at some other code, and wondered the same question. Some stuff I have seen does not even lend itself to stl...I keep thinking that in C++ we have classes,virtual functions,inheritence, and polymorphism for a reason. Some stuff I have seen written using STL was twice as much work to incorporate than if it had been done using abstract classes. I actually feel the same way about what is happening to XML...I (for the life of me) can not figure out why they changed it from being an incredibly cross platform data transport mechanism into a templeted html/macro language...:confused:

[CodeGuy]

I've just finished up a program that uses both STL and Boost quite heavily. After trying to use Boost's random library, it gets my vote for dumbest implementation. I really don't want to trash it either, because it has the potential to be so useful. (It incorporates four or five different really good random number generators like Mersenne Twister.) The thing is that it's so freakin' hard to use and remember. I just gave up and went back to rand(). On the other hand, boost's shared_ptr (the container-safe equivalent of auto_ptr) has a nice, simple implementation, which almost guarantees widespread use. You have to remember that Boost's libraries are only _potential_ candidates for inclusion into the next C++ STL standard. By no means do they all have the same degree of usefulness to a wide audience. My own hated STL item is proliferating iterators. Algorithms should have been given default parameters of begin() and end() to span the entire container, to avoid all the code clutter that people detest. STL is a tool -- use it as long as you benefit. If some element of it doesn't work for you, drop that usage of it. CodeGuy The WTL newsgroup: 870 members and growing ... http://groups.yahoo.com/group/wtl

[Henry Jacobs]

The smart pointers are the only boost classes I use frequently.

[Stan Shannon]

Unfortunantly, I think it is the nature of the typical programmer to over use any technology they have invested the time to learn. That is understandable when one considers the learning curve on some of this stuff compared to the actual need to use it on an average day, but if you don't use it, you forget it, so when you do really need it,you have to go back and learn it all over again. Thats been my experience with COM - learned it, didn't need it, forgot it, needed it, learned it again, used it for about 6 monghts, didn't need it after that, forgot it, ... :eek:

[Tim Smith]

To me it isn't a question of usefulness to a wide audience, but a question of 'is this the best solution for a problem'. In our desire for this STL nirvana, have we started becoming more interested in the process (STLifying code) rather than the results (nice simple maintainable software)? Tim Smith Descartes Systems Sciences, Inc.

[Giles]

I agree about the XML thing. I work in finance, and am amazed at what they have done with the new SWIFT messages used by banks, brokers and the like. Its totaly missed the point with what they have implemented. They might as well have used csv files. You've got files that will come out at 50k for each transaction, yet if they had been structured correctly would have been only 2k, and much easier to understand. You get monkeys that jump on a bandwagon to use something that is 'in', yet not fully understand why they should be using it. Giles

[CodeGuy]

I'm agreeing with you ... if a tool gets beyond the level of complexity for anyone to reasonably understand it, doesn't it become useless? I find this to be true with some of the Boost libraries. I hope others don't find this with my own code because I try to be pragmatic about template usage. CodeGuy The WTL newsgroup: 860 members and growing ... http://groups.yahoo.com/group/wtl

[Jonathan Gilligan]

The length of crc.hpp seems to have little to do with STL and more to do with the dictates of platform independence. It deals with the fact that different processors have different word lengths (#if ULONG_MAX > UINT_MAX tests true for MSVC targeting i86 architecture and false for MSVC targeting IA64), with flaws in various compilers (see #ifdef BOOST_MSVC, etc.), etc. You can quick-code a 10-line CRC routine and forget about it, but if you're not careful it could start malfunctioning when you recompile it under a different compiler or processor architecture. There is some merit to designing an industrial-strength library that attempts to be as platform-independent as possible. After all, how many products undergo a complete head-to-tail line-by-line code review when moved to a new compiler version or a new processor architecture. Ideally they all would be, but it's not done in practice, which is why it can be advantageous for mission-critical code (expecially stuff that's not intuitive, such as CRC, arithmetic coding, etc.) to design the hell out of a platform-independent implementation. Weigh the extra time to understand all the platform-specific issues up front against the potential disasters if your CRC code fails silently at run-time in a future revision. For some applications, the potential-disaster cost is minimal, in which case the 10-line solution would be adequate. In other applications (e.g., security and cryptography), there could be tremendous cost to silent failures and it's worth overdesigning the code. If an error caused a compression or encryption program to throw intermittent silent errors on a particular platform, the compressed/encrypted data would be irrecoverable. If the errors were sufficiently intermittent, they might not show up in testing. You have to decide these kind of design issues for yourself based on what you will use the code for. Another potential danger zone is the risk of errors in the source code (there's much more room for off-by-one errors in 1000 lines of code with many special cases for different architectures than in the simple 10-line solution). Similarly, if you use Boost without carefully reading the code for yourself and making sure you understand and trust it, you may be taking greater chances than coding your own 10-line solution. There's no one right answer. It all depends on what you need for your own development situation. I continue to like Knuth's "The Errors of TeX" for an account of how to plan and execute the devel

[Christian Graus]

I think as head STL geek at work I can speak with some authority here ;) I think the potential problem here is that when we learn something new, we can fall into the trap of using it any chance we get, because it's the *next big thing*, or becomes regarded as a cure all. For example, I always push people towards STL in favour of CArray ( I think no-one has used CArray for a long time, or they keep it a secret from me ). But then when someone had to use an array instead of a vector because of performance ( sorting objects in 3D, lots of heavy use per frame ) they expected me to object. In this case vector clearly hurt performance, and from my POV if it's the wrong tool for the job, it should not be used. Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.

[CodeGuy]

Christian, One of the main design issues that Stroustrup said he faced was that people perceived vector to be slower than a real array and wouldn't use it for speed-critical sections. I'm interested to know if you have done some profiling to say vector is X% slower than a normal array? I don't doubt you; I'm just curious to know that info myself. Thanks, CodeGuy The WTL newsgroup: 880 members and growing ... http://groups.yahoo.com/group/wtl

[Christian Graus]

It was actually someone else at work, who was using vector to store pointers to vertices for 3D rendering. Fair size list, being iterated through as many times as possible ( which equated to the FPS ) and he got a serious FPS increase by removing vector and replacing it with an array. I've never had to push vector that hard, so I pretty much have taken his word for it. As to the difference as a percentage, I couldn't tell you. I still use vector everywhere I need an array, and have no problems, but as I say, I never push it as hard. I am still using the VC++ standard implimentation - I'm sure I'll install the stlPort one of these days... Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.

[CodeGuy]

Thanks, Christian. In case you run into a similar situation in the future, you might tell your coworker to try valarray. It's designed for matrix manipulation but still has an easier interface than dealing with pure arrays. http://www.dinkumware.com/htm\_cpl/valarray.html Also, interestingly, despite the fact that vector was intended to be the fastest general-purpose container, Herb Sutter found that deque was faster than vector with VC++ 6. The nice thing too is that the member functions for deque are the same as for vector. http://www.gotw.ca/gotw/054.htm CodeGuy The WTL newsgroup: 880 members and growing ... http://groups.yahoo.com/group/wtl

[Tomasz Sowinski]

Fair size list, being iterated through as many times as possible ( which equated to the FPS ) and he got a serious FPS increase by removing vector and replacing it with an array. But the pointers were only read from the vector? No inserts, erases, etc? Tomasz Sowinski -- http://www.shooltz.com

[Christian Graus]

I didn't see the code, but I believe the array was being recreated, or at least changed. Christian As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet. Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.