Originally posted by AnonymousCoward
View Post
Announcement
Collapse
No announcement yet.
Approved: C++0x Will Be An International Standard
Collapse
X
-
AnonymousCoward,
Let me chime in.
You really need to understand that even if STL is just as fast as hand written C implementation (and in my experience, implementation performance and usage cases tend to vary, a-lot, across different platforms and compilers), the lack of control over what the compiler is doing one one hand, and the inability to debug STL application when something really-really-really-nasty happens make it a deal break in many C++ projects.
If your code heavily relays on vectors, and you experience a crash in release mode deep within the vector implementation, you're more or less done for. An STL code is extremely hard to understand / debug by reading the code due to the excessive use of... well... templates.
E.g. If you get a trace of you code, the crashed in a line deep within STL, that says A = B + C(X), and A, B, C are templates... you are screwed.
- GilboaoVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.
Comment
-
I don't buy that argument. Common STL implementation tend to be very well optimized, debugged and tested, simply because they're used to much all around the world, so you're extremely unlikely to hit a bug in them. Of course, you may be using it the wrong way (i. e. accessing invalid iterators etc.), but good STL implementations offer a debug mode that will check for such errors. And if you actually run into Heisenbugs that disappear when you enable these things, well, that's life. Programming is hard, get used to it.
Besides, what would be the alternative? Using non-template containers such as those from glib? There's no way in hell I'll give up type safety for my containers. Rolling your own template containers? There's no doubt it'll be slow and riddled with bugs compared to the STL. It may make sense to use other template containers like those from Q which offer different tradeoffs than the STL ones, but if you think that templates are generally hard to debug (which, by the way, I also don't buy, as long as no template metaprogramming is involved), they won't be any easier to debug than those from the STL.
Comment
-
Originally posted by AnonymousCoward View PostI don't buy that argument. Common STL implementation tend to be very well optimized, debugged and tested, simply because they're used to much all around the world, so you're extremely unlikely to hit a bug in them. Of course, you may be using it the wrong way (i. e. accessing invalid iterators etc.), but good STL implementations offer a debug mode that will check for such errors. And if you actually run into Heisenbugs that disappear when you enable these things, well, that's life. Programming is hard, get used to it.
Besides, what would be the alternative? Using non-template containers such as those from glib? There's no way in hell I'll give up type safety for my containers. Rolling your own template containers? There's no doubt it'll be slow and riddled with bugs compared to the STL. It may make sense to use other template containers like those from Q which offer different tradeoffs than the STL ones, but if you think that templates are generally hard to debug (which, by the way, I also don't buy, as long as no template metaprogramming is involved), they won't be any easier to debug than those from the STL.
In general, I'm not saying the STL is bad or should be avoided, but I would suggest anyone that plans on using STL to well aware of the issues and possible pit-falls.
- GilboaoVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.
Comment
-
Originally posted by gilboa View PostI didn't imply that STL is buggy, I *did* imply the user generated bugs (E.g. memory overruns, deleted object access, etc) are -very- hard to debug, once the crash happens inside STL due to the excessive use of templates.
Also, I think that the debugging modes modern STL implementations generally offer are actually much more helpful in detecting bugs than having you own containers that don't have such facilities, at least not with the degree of maturity common STL implementations provide.
Originally posted by gilboa View PostI'm a strong believer in developing your own containers, but that's personal preference
Comment
-
Originally posted by AnonymousCoward View PostThe STL doesn't use templates "excessively", it uses them in just the way they were meant to be used. And really, what's so hard about template code? The hard things to understand about containers are the underlying data structures like Hash Tables, Balanced Trees, Heaps etc., and they're just as hard as in non-generic code.
Sorry for being blunt, but it's not just personal preference, it's also a pretty dumb idea in the vast majority of cases. There's no reason at all to reinvent the wheel, when you have a fast, flexible, well-known and debugged wheel at your disposal for free. Or actually multiple such wheels. After all, the STL isn't the only generic container library around.
Comment
-
Originally posted by AnonymousCoward View PostSorry for being blunt, but it's not just personal preference, it's also a pretty dumb idea in the vast majority of cases. There's no reason at all to reinvent the wheel, when you have a fast, flexible, well-known and debugged wheel at your disposal for free. Or actually multiple such wheels. After all, the STL isn't the only generic container library around.
Comment
-
Originally posted by Cyborg16 View PostAbout the containers: sure. But about templates: have you ever tried using boost::spirit and seen the kind of errors gcc spits out if you make a little mistake in the parser code? Have you noticed the enormous compile-times and memory usage (1GB+) during compilation?
Originally posted by mirv View PostYou might want to check who you were talking to; he's got a fair bit of experience to back up his statements. His ending statement was pretty much: know your tool. Know what it does well, what it doesn't do well, and then decide if you're going to use it or not. It's a dumb idea to use STL blindly - this is absolutely nothing to do with STL, it just means you haven't looked at the problem at hand properly.
Comment
-
Originally posted by AnonymousCoward View PostWell, duh. Doesn't that apply to any tool? Of course, if you have a good reason to not use the STL, fine, go ahead and use something else. But my experience is that more often than not, the reasons that people cite are based on ignorance and superstition.
Comment
Comment