I was working on porting someone else’s C++ code from Windows to Linux system. This code made heavy use of STL, no problem there. I have a good hand on STL (or so I thought). My engine also makes heavy use of STL. However this code was written using Microsoft’s version of STL. So what’s the problem? STL is STL right? It’s standard across platforms right? No, wrong! Apparently not entirely true. Microsoft’s version of STL is not 100% standards compliant. I had read this before, but didn’t actually come across a case where I found incompatibilities in code across STL libraries.

Until now that is. The code I was porting happens to have a lot of maps and multimaps, with deeply nested template code. A pain in the neck to debug I must say. The problem started with the compiler throwing some ridiculous errors, almost illegible which I traced back (, with some amount of difficulty) to map<>::erase() function. MS’ version of the function returns an iterator, the standards version doesn’t return anything! So I checked the one I use in my engine, STLPort, and it too doesn’t return an iterator for map<>::erase(). Googled around bit, and found that indeed there is no return value for that function.

Strange. I would generally agree with MS on this one. Most other containers like vector and list return an iterator on erase() so should map and multimap. I don’t understand the logic behind map<>::erase() not returning an iterator value. Maybe the standards committee got it wrong or maybe I haven’t fully understood the reasons why. A caveat to those who use MS STL; don’t. Though the erase() issue is to some extent trivial, debugging template code can be really difficult. I for one use standards compliant STLPort to avoid such issues. Though it may be a little difficult to setup, I would recommend people to use the same.