std::string insert method has ambiguous overloads?

Environment: VS2005 C++ using STLPort 5.1.4.

Com开发者_运维知识库piling the following code snippet:

std::string copied = "asdf";
char ch = 's';
copied.insert(0,1,ch);

I receive an error:

Error   1   error C2668: 'stlpx_std::basic_string<_CharT,_Traits,_Alloc>::insert' : ambiguous call to overloaded function   

It appears that the problem is the insert method call on the string object.

The two defined overloads are

void insert ( iterator p, size_t n, char c );
string& insert ( size_t pos1, size_t n, char c );

But given that STLPort uses a simple char* as its iterator, the literal zero in the insert method in my code is ambiguous.

So while I can easily overcome the problem by hinting such as

copied.insert(size_t(0),1,ch);

My question is: is this overloading and possible ambiguity intentional in the specification? Or more likely an unintended side-effect of the specific STLPort implementation?

(Note that the Microsoft-supplied STL does not have this problem as it has a class for the iterator, instead of a naked pointer)

Known issue, ruled "Not A Defect". http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#84

If you differentiate the differents integers type, there is no ambiguity at all.

Good practices commands to store buffer sizes in size_t (or ssize_t) types, not int.

If you agree with that, calling insert(int, int, char) makes no sense since the two first arguments are supposed to be a "buffer sizes".

If there was no implicit conversion from int to size_t, you couldn't even call insert() that way.

Intentional or not, the problem has more to do with the semantics of 0 than the member functions in question. Perhaps the Microsoft library's designers (they used Dinkumware last time I checked) were more cautious in this respect.