标签云

微信群

扫码加入我们

WeChat QR Code

C++11 added some new string conversion functions:http://en.cppreference.com/w/cpp/string/basic_string/stoulIt includes stoi (string to int), stol (string to long), stoll (string to long long), stoul (string to unsigned long), stoull (string to unsigned long long). Notable in its absence is a stou (string to unsigned) function. Is there some reason it is not needed but all of the others are?related: No "sto{short, unsigned short}" functions in C++11?


My question was intended to be more along the lines of "is there some non-obvious drawback of just using stoul". Obviously that will mess with template instantiation, but is there anything else that I'm not considering? Comments on why it was left out would be nice but secondary.

2019年06月26日03分00秒

NicolBolas I cannot see why this is not constructive. It is a perfectly valid question as I cannot see any reason for this inconsistency and anwers may give insights into some possibly existing valid but not that obvious reason for it.

2019年06月26日03分00秒

SethCarnegie Well, what your platform (and maybe the majority of platforms) does is just irrelevant, because an unsigned long just is no unsigned int.

2019年06月25日03分00秒

SethCarnegie: on my typical computer, unsigned long is 64 bits, and unsigned int 32. They are different types, and can't be assumed to be the same as each other.

2019年06月25日03分00秒

NicolBolas Like said, the OP (and me) doesn't know it is speculative, as there could just be a perfect valid reason for it burried deep in the language internals of C++. But since you say it's speculative I guess there is no such reason. But again, maybe a C++11-responsible person can still answer it. This is no "Wah wah, where is that damn stou"-question, but a question asking for a possibly definite reason for this obvious inconsistency. If you know there is no such reason, then well, post it as an answer.

2019年06月26日03分00秒

Do you know why the C++ Committee decided to go for such a C-ish approach? Something like boost::lexical_cast<>() seems like a more C++ way of doing things.

2019年06月26日03分00秒

Are these implementation details really standard-defined?

2019年06月25日03分00秒

LightnessRacesinOrbit: For sto*, C++11 21.5/1: Effects: the first two functions call strtol(str.c_str(), ptr, base), and the last three functions call strtoul(str.c_str(), ptr, base), strtoll(str.c_str(), ptr, base), and strtoull(str.c_str(), ptr, base), respectively.

2019年06月25日03分00秒

It doesn't matter whether the C++ standard says "must be implemented by calling ...", because the C++ standard still has the global as-if rule: if the standard says std::sto* must be implemented as wrappers for the C library functions, and a valid program cannot tell that they aren't secretly implemented differently, the implementation is valid.

2019年06月25日03分00秒

Completely off-topic, I think the practical reasons for not using iostreams like Boost/lexical_cast does is sheer performance; I believe iostreams lose out against strtoul etc. by a considerable margin.

2019年06月26日03分00秒

The difference between stoi and stol, or stol and stoll is also only a range check.

2019年06月25日03分00秒

Hossein: Between stoi and stol, yes.But stol and stoll do not differ only in range check, they call different library functions.

2019年06月26日03分00秒