Approved: C++0x Will Be An International Standard

[curaga]

#include <stdint.h>
#include <stdbool.h>
enum { NUM_BITS = 42 };
struct bitset {
  uint32_t bits[NUM_BITS/32];
};
bool get_bit(struct bitset *bits, unsigned n) {
  return bits->bits[n/32] & (1 << (n%32));
}

All this talk, and nobody noticed the bug? You're only getting 32 bits yet asking for 42.

[AnonymousCoward]

Good point. It should be uint32_t bits[NUM_BITS/32 + (NUM_BITS%32 != 0)];

[gilboa]

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.

- Gilboa

[AnonymousCoward]

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.

[gilboa]

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.

I 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.

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.

I'm a strong believer in developing your own containers, but that's personal preference (Plus, I need code that's portable across different environments and/or execution modes that not necessarily support STL or C++).
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.

- Gilboa

[AnonymousCoward]

I 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.

The 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.
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.

I'm a strong believer in developing your own containers, but that's personal preference

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.

[Cyborg16]

The 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.

About 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?

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.

Agreed. If you're writing the code from-scratch containers are extra work and an extra opportunity for bugs. If someone else is trying to read your code it's extra wheels he/she has to get his/her head around.

[mirv]

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.

You 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.

[AnonymousCoward]

About 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?

This is why I said "as long as no template metaprogramming is involved".

You 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.

Well, 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.

[mirv]

Well, 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.

Sadly, I've just as often seen people use STL where something else would be much more suitable - for much the same reason.