Damien Katz

Simple containers are a huge win. I faint when I imagine all the C code I'd have to write just to accomplish this:

struct Contact
{
string name;
vector addresses;
int age;
};

vector contacts;
Contact myContact;
contacts.insert(contacts.begin() + 5, myContact);

But I think you're talking more about the "advanced" capabilities of the STL, which involve functors and algorithms and, for the most part, I can give them a miss. Iterators don't scare me much (if you really think the syntax is bad, typedef it away so you only have to write the ugliness once). But I still would rather write a loop rather than call foreach.

Hey, I'm with you, I use vector and map all the time, they are useful and save time. Well, compared to hand-writing your own containers.

The typedef works fine for a commonly used container class, but for those one-off usages of a container it just becomes another layer of indirection and noise.

Something jumped out at me in your example:

contacts.insert(contacts.begin() + 5, myContact);

zoomed closer:

contacts.begin() + 5

GAHHHHH!!! What is that?!? Actually, I know exactly what that is, and I still remember how it looked the first time I saw it because I vomit a little bit in the back of my throat every time I see it again. It that weird iterator madness where you can just add numbers, positive and negative, and it works because they are like psuedo pointers, but not really (except that they are and they have many of the same problems as pointers). And indeed it's all done this way to be compatiple with C pointer arithmetic, so that they too can be plugged into the same "generic" algorithms.

Anyway sorry for the mini rant, I'm actually agreeing with you, the STL containers are a good thing. But only because they are better than nothing at all. The problem is they are designed to work in some grand generic algorithm/meta programming universe that nobody can quite get their heads completely around. If instead they were just designed to be simple and pragmatic, they'd be far more useful in the common case.

So was the "i++" intentionally left out?

I love the new Java 5 For..Each loop:

void cancelAll(Collection<TimerTask> c) {
for (Iterator<TimerTask> i = c.iterator(); i.hasNext(); )
i.next().cancel();
}

No, something swallowed the pluses in the original posting. Thanks for the heads up, I've added them back.

Yeah, specifically in the case of vector::insert, I wish I could just pass in 5 and have it understood as begin() + 5. That would have gone a long way with usability.

But I made my peace with iterators a long time ago. I think they're pretty slick, really they're no more than a generalization of the concept of a pointer. Vector iterators are either bare pointers, or classes that look JUST LIKE pointers but do additional debug validation. And list iterators are classes that again, look JUST LIKE pointers but have special magic so that ++it follows through the pNode->pNext pointer. If you can get over the whole "operator overloading is an abomination unto the LORD" mindset, and just relax and accept it, it is pretty elegant way of expressing the underly basic concept of "go to the next item".

But okay, as far as algorithms go, sure I understand that if I just invoke a function the compiler has the ability to outline it (or inline it). But that's really a micro-optimization, and one that comes at the sake of readability. Other than that I can see no real reason to use algorithms. (Well, except for maybe std::sort; that one has a special place in my heart). But stuff like bind2nd ... if I ever have to use it again in my life, it'll be too soon ...

I agree that highly generic templates can add a lot of unnecessary noise to code (or a lot of unneccessary typedefs) but it's really the fault of C++ for not supporting either:

for (typeof(foo)::iterator it = foo.begin(); ...

or even better,

for (foo::iterator it = foo.begin(); ...

There's no actual reason for this syntax not being supported in C++, it just isn't :(

Dude, STL coding is sooo nineties...

You really should have taken up modern languages by now:

foreach ($obj as $val) { ... }

there you have it: clean, concise and understandable. works on objects, arrays and hash maps alike.

Jokes aside, I really am sorry of the tons of cruft and boilerplate code that coders have to endure daily because of the limitations of the platform they have to use. Luckily we have better tools today, and that includes languages, too.

A little precious gem of coding wisdom I stumbled upon recently read something like: "many coders are fond of design patterns, but every widely-used design pattern is in fact a deficiency of the language itself". Makes a lot more sense when you realize subroutines where 'design patterns' too, in a not-too-distant past...

container.each do |element|
stuff
end

Sigh! Woe is me. I see nothing wrong with the original code (I use stuff like that all over the place), don't even know what STL is, and yet I have over a 1,100,000 licensed users of my software, customers in 46 countries and do business with 7 out of 10 of the largest companies in the world, along with the governments of at least ten countries. Imagine what I will accomplish if I ever learn modern programming!

The container.each do |a| ... end is Ruby code, although for a in container ... end also works in Ruby. Python uses indentation to lose a few characters:

for a in container:
  ...

The point is that it's really hard to think in statically typed languages like the "industrial" languages C, C++, Java, C#, etc. Ideally one would use a dynamically typed language with optional static type declarations for speed and ability to think, but the only language I'm aware of that can do this is Lisp. Are there others?