[prewett]

STL strings are also next to useless. startsWith(), endsWith(), split(), case-insensitive find, stringify a number, numericify a string, easily construct a formated string, properly handles unicode (wstring does not), all require extra code. QString has a function for each of those.

And the STL data structures are sometimes kind of unwieldy:

   if (dict.find(key) != dict.end()) { ... }

is lame compared to the easily understood:

   if (dict.contains(key)) { ... }

Not to mention all the stupid inconsistencies:

    // std::vector has no sort function, haha!

    std::sort(std_vector.begin(), std_vector.end());

    // std::sort doesn't work on std::list, haha!

    std_list.sort();

And my favorite annoyance, the fact that std::vector::size() returns unsigned int, despite the fact that for practical purposes you aren't going to get anywhere near even 2 billion elements without running out of memory (or other performance problems), so I'm stuck writing

   for (unsigned int idx = 0;  idx < v.size();  ++idx) {...}

or omitting the "unsigned" and getting lots of compiler warnings. I get why they would have done it; I would have done it too. Until I used Qt, then I like how everything is simply int. I suppose if you are doing physics simulations or something you might need something different, but it's the rare GUI program that needs unsigned int for size.

[eps]

vector::size() actually returns size_t, which is exactly the right way to go about, because why should a size() function be able to ever return negative numbers?

[prewett]

Good point about size_t, although technically it's std::size_t.

I agree, STL has done the "right" thing with sizes; of course negative sizes are meaningless. The problem is, Qt's way is so much nicer to use, even though it is obviously "wrong." Type three characters, done. Putting "int" in your headers, it's obvious what's going on--you're getting a number back. I suppose std::size_t is obvious, but it's hard to read, and I hate typing underscores. Again, more correct, but I hate doing it, which is just another reason why Qt is such fun to use compare to STL.

[to3m]

std::sort requires random-access iterators, which std::list - being a list - can't supply.

std::list's iterator type: http://en.cppreference.com/w/cpp/container/list

std::sort's iterator requirements: http://en.cppreference.com/w/cpp/algorithm/sort

All the different types of iterator: http://en.cppreference.com/w/cpp/iterator

(This might seem like needless nitpicking to some; to me, it's more like knowing why you can't, say, seek on a socket.)

[prewett]

Yeah, I know why. Problem is, it is a bad design. I don't work for the API, the API works for me. Conceptually sorting a list is the same as sorting a vector, so it should look the same in the code. The fact that it may require a different algorithm underneath is what the API is there to figure out for me. Other languages and APIs (including Qt) don't have problems like this, hence my complaint.

[okasaki]

2 billion chars = 2G of data, so not that big.

[imron]

You're unlikely to have a std::vector containing 2 billion single byte elements however.

Even being conservative, say you had a struct of size 24 bytes (e.g. 3 doubles x, y and z) then now you're up to 48G.

So yes, there are very few situations where you'll have meaningful data that would fill a vector indexed by signed ints without running out of memory first.

[blt]

But... Sometimes you do.

Can you imagine how stupid it would feel if you had to abandon all your std::vector-using code the moment you need to deal with an array bigger than 2 billion elements?

[imron]

Actually, thinking about it a bit more, the only thing you could store in a std::vector indexed by signed ints where you would have a problem would be single bytes.

If you have 2 billion 2 byte elements then that's 4gb which is the total addressable space on a 32-bit system - leaving no room for program code or any other data meaning you couldn't run anything.

You could go 64bit, but then signed ints go up to (2^63)-1 and you have the same problem - elements more than a single byte in size will cause you to run out of addressable memory before you exhaust available signed ints.

[okasaki]

Vector<bool> is often specialized to take 1 bit per element, so that's another one.

[imron]

Yes, and like a vector containing > 2 billion single byte elements it's still delving in to a very peculiar use case.

Compared to the majority of other uses of std::vector which will never be able to overflow signed ints.

I get from a logical point of view that size() would never be < 0 therefore it makes sense to use an unsigned int, however from a practical point of view it also makes programs more susceptible to a number of pernicious bugs that can catch out unsuspecting programmers, e.g. things like

   for ( size_t i = v.size(); i >= 0; --i )
   {
      ...
   }

Which would work fine with a signed int, but here it will just loop infinitely.