std::string insert method has ambiguous overloads?

Question

Environment: VS2005 C++ using STLPort 5.1.4.

Compiling 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)

To be any more strict: it should be `copied.insert(static_cast(0), static_cast(1), ch)` — ereOn, May 12 '10 at 14:22
@ereOn: The second `static_cast` is unnecessary since both overloads take a `size_t` as the second parameter. — James McNellis, May 12 '10 at 14:54
Not unnecessary because of possible future overloads and the uncertain integral type of '1'. — Marius, May 12 '10 at 15:33

score 1 · Accepted Answer · answered May 12 '10 at 14:21

1

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

answered May 12 '10 at 14:21

MSalters

173,980
10
155
350

score 0 · Answer 2 · answered May 12 '10 at 14:21

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.

score 0 · Answer 3 · answered May 12 '10 at 14:21

0

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.

answered May 12 '10 at 14:21

Marcelo Cantos

181,030
38
327
365

Dinkumware would probably not have this issue: using real iterators alleviate the ambiguity. – Matthieu M. May 12 '10 at 16:04

std::string insert method has ambiguous overloads?

3 Answers3