Do any of the standard's people read HN, or is there a way of submitting requests? The STL could seriously use some improvements. std::string doesn't do most of the stuff you want with a string; updating it to an interface like Python's string would be nice. Having a std::vector::append() would be really nice, so I don't have to remember that C++ uses something completely different from every other language. Convenience things like std::set::contains() would be nice because s.find() != s.end() is not very readable compared to contains().
I'm really impressed at what the standards committee has done, but I'm wondering if we ought to start thinking about a C++2.0 where we can write the C++ that we've learned we want. The poor young-uns learning C++ still have to learn all the old stuff, because otherwise it will bite them sooner or later.
Some do. More are active on Reddit. But new proposals can come from anyone. Though, before writing and submitting any, check on the public std-proposals mailinglist if your idea would get any traction. See https://isocpp.org/std/submit-a-proposal
> The STL could seriously use some improvements. std::string doesn't do most of the stuff you want with a string
std::string predates the STL and most of unicodes history. It was supposed to a be an alternative for using C functions for manipulating NTBS's, nothing more. Since then we've only really had 3 standard revisions, and most languages that see constant evolution still haven't got unicode right...
> Having a std::vector::append() would be really nice, so I don't have to remember that C++ uses something completely different from every other language
I can think of a bunch of languages that don't use "append" for pushing on to the back of a dynamic array. JavaScript for instance, which uses "push"
> I'm wondering if we ought to start thinking about a C++2.0 where we can write the C++ that we've learned we want.
The Ranges proposal/TS goes quite far in this direction. See Eric Nieblers range-v3 library as a testing ground.
Why Python string class? The Python 2 one or the Python 3 one? ;-)
String classes are fickle things. It's very hard to get them right. Still, std::string, for all of its age, does let you do a lot of what Python does with manipulation of bytes, particularly when combined with locales (admittedly painful to use) and iostreams (also a bit painful at times).
Python does have a LOT of other functionality tied into strings, but there's a legit design question as to whether that's really a good idea or not. What particular functionality do you think ought to be there?
Python only because it's the string class that I've used that always has everything I need. QString from Qt is pretty good, too. std::string is, like you say, painful. Since QString exists, works great with a long history, so why is std::string so limited? Design-wise, I'd say the few changes which QString has had demonstrates the solidity of the design.
Off the top of my head, what I use frequently (and which is unavailable in std::String) is:
- replace(search, new). std::string can do it, but first you have to find the index of the start, then you call replace() to replace a set of bytes. Too low level.
- endswith() and beginswith() are surprisingly helpful. endswith() in particular. s.index("prefix") == 0 is pretty clear, but s.index("suffix") == s.size() - "suffix".size() is not very clear.
- toupper()/tolower()/isspace()/isslanum()/isupper()/etc. are not something you use every day, but you really don't want to have to write proper handling of every language's idiosyncracies yourself, and it's not worth it to find a library, so probably only European languages will work initially.
- proper unicode handling. std::wstring (UTF16) is not it (to be fair, that wasn't clear at the time of design), plus I don't think it works well with either Microsoft's or Apple's UTF16
- making a string from a number. QString does this well, Python 2's str(num) is not really flexible enough. I don't want to have to create a stringstream just because I need a numeric string.
- create a string from a printf list. I know stringstream is supposed to do that, but I never seem to be able to do exactly what I want (e.g. %.3f), and regardless, I never can remember the correct syntax for the modifiers (e.g. hex(), precision()), despite it appearing like it ought to be obvious.
I pretty much expect all the above in a string. std::string is basically a veneer over an array of bytes. Maybe that was okay in 1998 when it was designed, but the first thing I have to do is add all that in now, every time I do anything UI-related with text.
I also would like split(), it makes simple parsing a lot easier.
I live in a "fast languages only when necessary, and with restraint" shop. Our C++ is not idiomatic, it is meant for programmers from other languages. Anything with iterators is a bit sketchy. It tends to look more like C than C++, and now that I'm an old person I am perfectly happy with that.
We use `s.count(i) == 1`. It's ok -- clear, readable etc. Doesn't give you an iterator if you want to delete the thing too, but most of the time you don't.
Well, since D is garbage collected, it really exists in a different world from C++, so I'd say that no, it is not qualified to be in the running for a C++ 2.0.
I don't use D myself, but I'm curious how often someone actually does that. Is it about the same as how C++ can technically be connected with a GC? Because no one does that, despite that it is possible.
> but I'm wondering if we ought to start thinking about a C++2.0 where we can write the C++ that we've learned we want
or... you could just use any of the dozens of libraries that already has the API you want (append, contains... they are all in Qt for instance). Why wait for it to standardize ? it's already here and you can use it.
I'm really impressed at what the standards committee has done, but I'm wondering if we ought to start thinking about a C++2.0 where we can write the C++ that we've learned we want. The poor young-uns learning C++ still have to learn all the old stuff, because otherwise it will bite them sooner or later.