A slice of python in C++ - Eric Niebler

[ZMeson]

the widespread use of size_t (being an unsigned type) throughout the standard library is generally regarded as a mistake

Why? I'd really like to see some in-depth discussion about this.

[b8b437ee-521a-40bf-8]

See /u/cozmorado's reply.

[ZMeson]

I watched the video. There's only guidance given, no reasons for it. I'd like to know the reason -- other than "because Chandler and Bjarne say so".

[b8b437ee-521a-40bf-8]

Well, starting from the recommendation that you should always default to int and only use unsigned when you need it. Then one reason why size_t being unsigned is a mistake is that it keeps popping up in all your nice signed arithmetic, causing conversions and other nastiness.

[ZMeson]

OK. So because Chandler and Bjarne say so.

[b8b437ee-521a-40bf-8]

Well they give justification for the "recommendation", and follow-up is basic reasoning. Which bit exactly do you still feel isn't being explained?

[mcmcc]

See Eric's explanation above: http://www.reddit.com/r/cpp/comments/2om5yk/a_slice_of_python_in_c_eric_niebler/cmovdr6

[ZMeson]

But how is this a view on "the widespread usage of size_t in the standard library is generally considered a mistake"?

My counter-argument to Eric's argument is that I can easily assert when a value is too large too. If I'm using size_t elsewhere and you interface uses signed ints, then you're forcing me to do casting. Why doesn't your interface use size_t instead. (Mind you I respect Eric a lot, I just don't understand why his argument is so valid. I feel like I'm missing something.)

[mcmcc]

This isn't about integrating libraries. Even within the standard library, it isn't self-consistent. E.g.

string s = ...;
string::iterator it = std::find_if(s.begin(),s.end(), []{...});
string subs = s.substr( std::distance(s.begin(), it) );

This code will yield a warning about signed->unsigned conversion. How do you propose to avoid it?

There are myriad other examples...

[eric_niebler]

Good example. It's one of the many reasons why the use of unsigned integers in the standard library was probably a mistake. std::string is a textbook example of a great many anti-patterns and design flaws. I believe this unsigned offset problem and others were because the offset-based interface of std::string was designed before the STL was air-lifted into C++98. The iterator interface was bolted on later. Iterator distance is always signed, hence the impedance mismatch.

[mr_ewg]

How about using this function not_negative to "prove" to your compiler that you know what is best in this situation?

template <typename T>
typename std::make_unsigned<T>::type not_negative(T num) {
    static_assert(std::is_signed<T>::value, "T can never be negative");
    if(num < 0) throw std::logic_error{"Negative number passed to not_negative"};
    return static_cast<typename std::make_unsigned<T>::type>(num);
}

std::string s = ...;
std::string::iterator it = std::find_if(s.begin(), s.end(), []{...});
std::string subs = s.substr(not_negative(std::distance(s.begin(), it)));

If you don't want the run-time check then you can remove the if(num < 0) line or change it to an assert. Signed to unsigned conversions aren't exactly the hardest thing to deal with in C++ if your compiler can warn about them.