std::string 插入方法有不明确的重载？
环境：VS2005 C++，使用STLPort 5.1.4。
编译以下代码片段：
std::string copied = "asdf";
char ch = 's';
copied.insert(0,1,ch);
我收到错误：
Error 1 error C2668: 'stlpx_std::basic_string<_CharT,_Traits,_Alloc>::insert' : ambiguous call to overloaded function
问题似乎出在字符串对象上的插入方法调用。
两个定义的重载是
void insert ( iterator p, size_t n, char c );
string& insert ( size_t pos1, size_t n, char c );
但是考虑到 STLPort 使用简单的 char* 作为其迭代器，我的代码中 insert 方法中的文字零是不明确的。
因此，虽然我可以通过暗示轻松克服问题，例如
copied.insert(size_t(0),1,ch);
我的问题是：规范中的这种重载和可能的歧义是否是故意的？或者更可能是特定 STLPort 实现的意外副作用？
（请注意，Microsoft 提供的 STL 不存在此问题，因为它有一个迭代器类，而不是裸指针）
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)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
已知问题，被裁定为“不是缺陷”。 http://std.dkuug.dk/jtc1/ sc22/wg21/docs/lwg-close.html#84
Known issue, ruled "Not A Defect". http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#84
如果区分不同的整数类型，则根本不存在歧义。。
良好实践命令以
size_t（或ssize_t）类型存储缓冲区大小，而不是int。如果您同意这一点，则调用
insert(int, int, char)没有任何意义，因为前两个参数应该是“缓冲区大小”。如果没有从
int到size_t的隐式转换，您甚至无法以这种方式调用insert()。If you differentiate the differents integers type, there is no ambiguity at all.
Good practices commands to store buffer sizes in
size_t(orssize_t) types, notint.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
inttosize_t, you couldn't even callinsert()that way.不管是有意还是无意，这个问题更多地与
0的语义有关，而不是与所讨论的成员函数有关。也许微软图书馆的设计者（我上次检查时他们使用了Dinkumware）在这方面更加谨慎。Intentional or not, the problem has more to do with the semantics of
0than the member functions in question. Perhaps the Microsoft library's designers (they used Dinkumware last time I checked) were more cautious in this respect.