6 ms·

I've worked on a project that used all of these: std::string, QString, OString, char*. All were required by a different library that we needed. This is why a g

by ajuc 12y ago

I've worked on a project that used all of these: std::string, QString, OString, char*. All were required by a different library that we needed. This is why a good string type should be in core language.

raverbashing 12y ago
This is the problem with C++ (and in a certain part, with C) "Everybody" has their own C++ string (MFC, QT, several libraries, heck, even GObject library has their strings) Same with C Now, you won't see anybody reimplementing strings in Java. C#, Python, JS, etc Lessons learned, their strings work std:string is certainly a step forward and should be used for most projects today
- csl 12y ago
  I guess the underlying problem is that C++ doesn't have a standardized ABI. So you get things like QStrings, etc.
  - pjmlp 12y ago
    It is a standardization problem. When C++ got introduced, it used only C standard library, so everyone wrote their own library. C++ was already 10 years old when C++98 was a thing and compilers still needed to catch up. You don't re-write old code just because, so this cruft shows everywhere.
  - ajuc 12y ago
    It's not a matter of ABI. Even source code level compatibility would solve most of the problems. I am happy to recompile as long as I don't need to convert on every api boundary.
- pjmlp 12y ago
  > Lessons learned, their strings work It is worse than that, because the other alternative systems programming languages that eventually lost to C and C++ also had their string type. Just C did not, and C++ followed along due to its compatibility story.
  - angersock 12y ago
    And here is where C shines compared to C++: At least in C you know that strings are garbage, and you never pretend for a second that everything will be fine. C++ will claim "oh ho ho, we have a string type, don't worry!" and then people will get burned.
    - pjmlp 12y ago
      If you read the discussion, you would that people are getting burned by converting all the time between char* and std::string, because Google isn't using the same string types across all APIs. I rather have secure strings, even if every now and then they require some attention to.
- roel_v 12y ago
  "Lessons learned, their strings work" Except that they don't. Either they are 'complete' but massive and thus slow, or they start as 'array of byte' and then their designers spend 10 years implementing a more 'complete' string type that is still fast enough and end up as #1 anyway. Of course the C++ way where there is no string type that everyone uses sucks too, it's just that strings are almost impossible to get 'right' because there is no real 'right' and so many special cases that aren't apparent at first sight.
  - kibwen 12y ago
    I think this bears trumpeting: strings are hard! It's easy to gloss over their issues via garbage collection and pervasive heap allocation, but once you're in a domain where you care about stack allocation and avoiding copies you start running into difficult tradeoffs (above and beyond even the question of string encoding, which is a different beast altogether). Speaking as a dynamic language programmer who's trying to break into systems programming, it took a long time for me to fully appreciate the difficulties around strings. And now that I do, I'm perpetually paranoid about how many allocations my Python programs are doing behind the scenes...
    - rwmj 12y ago
      Chrome is a web browser, not a real time operating system.
    - ajuc 12y ago
      If you care about performance use std::performant_but_tricky_string. 99% of code doesn't care about string-related performance, but needs string anyway.
      - crpatino 12y ago
        If you care about performance at all, strings are going to slow you down in unexpected and counter-intuitive ways. Far better if you pass around text data as binary buffers (with metadata describing encoding, please), and only convert those to strings once they are ready to be consumed by the user (which is typically not where performance bottlenecks show up anyways)
- fleitz 12y ago
  So in C# (on the .NET VM) when you allocate a string that's more than 65K when does it get freed? I wouldn't call that 'working'.
agumonkey 12y ago
reminds me of the 100 functions perlism http://stackoverflow.com/questions/6016271/why-is-it-better-to-have-100-functions-operate-on-one-data-structure-than-10-fun http://stackoverflow.com/questions/6016271/why-is-it-better-...
bodyfour 12y ago
The real language problem is that classes are closed -- you can't add your own methods to std::string (other than operators) As a C++ program grows it's more and more tempting to make your own private string class (either by inheriting from std::string, encapsulating it, or reimplementing it) that interacts more naturally with your program's other types. I've done this myself. Of course this works great until you need to link to some other C++ library which has its own different string type. Honestly, if C++ added just allow classes to be reopened (even if they weren't granted access to private methods) a lot of the pressure to roll your own string would be diminished.
- deleted 12y ago
  [deleted]
- pubby 12y ago
  What's wrong with free functions?
  - bodyfour 12y ago
    Nothing really, but it mean your extensions aren't really first class syntactically. A developer has to remember that they write s.size() but not s.count_utf8_codepoints(). Bjarne Stroustrup actually has an interesting proposal to fix this by unifying free functions and method call syntax in C++17 although the proposal sounds pretty aggressive to me: http://isocpp.org/files/papers/N4174.pdf http://isocpp.org/files/papers/N4174.pdf Would be an interesting change.
- dragonwriter 12y ago
  > Honestly, if C++ added just allow classes to be reopened (even if they weren't granted access to private methods) a lot of the pressure to roll your own string would be diminished. But then you'd have the problem with different extensions to the same base class used in different libraries used in the same project conflicting, so you'd also need to make a way to scope the extensions to prevent that.
  - 12y ago

by ajuc 12y ago

raverbashing 12y ago

This is the problem with C++ (and in a certain part, with C) "Everybody" has their own C++ string (MFC, QT, several libraries, heck, even GObject library has their strings) Same with C Now, you won't see anybody reimplementing strings in Java. C#, Python, JS, etc Lessons learned, their strings work std:string is certainly a step forward and should be used for most projects today

csl 12y ago
I guess the underlying problem is that C++ doesn't have a standardized ABI. So you get things like QStrings, etc.
- pjmlp 12y ago
  It is a standardization problem. When C++ got introduced, it used only C standard library, so everyone wrote their own library. C++ was already 10 years old when C++98 was a thing and compilers still needed to catch up. You don't re-write old code just because, so this cruft shows everywhere.
- ajuc 12y ago
  It's not a matter of ABI. Even source code level compatibility would solve most of the problems. I am happy to recompile as long as I don't need to convert on every api boundary.
pjmlp 12y ago
> Lessons learned, their strings work It is worse than that, because the other alternative systems programming languages that eventually lost to C and C++ also had their string type. Just C did not, and C++ followed along due to its compatibility story.
- angersock 12y ago
  And here is where C shines compared to C++: At least in C you know that strings are garbage, and you never pretend for a second that everything will be fine. C++ will claim "oh ho ho, we have a string type, don't worry!" and then people will get burned.
  - pjmlp 12y ago
    If you read the discussion, you would that people are getting burned by converting all the time between char* and std::string, because Google isn't using the same string types across all APIs. I rather have secure strings, even if every now and then they require some attention to.
roel_v 12y ago
"Lessons learned, their strings work" Except that they don't. Either they are 'complete' but massive and thus slow, or they start as 'array of byte' and then their designers spend 10 years implementing a more 'complete' string type that is still fast enough and end up as #1 anyway. Of course the C++ way where there is no string type that everyone uses sucks too, it's just that strings are almost impossible to get 'right' because there is no real 'right' and so many special cases that aren't apparent at first sight.
- kibwen 12y ago
  I think this bears trumpeting: strings are hard! It's easy to gloss over their issues via garbage collection and pervasive heap allocation, but once you're in a domain where you care about stack allocation and avoiding copies you start running into difficult tradeoffs (above and beyond even the question of string encoding, which is a different beast altogether). Speaking as a dynamic language programmer who's trying to break into systems programming, it took a long time for me to fully appreciate the difficulties around strings. And now that I do, I'm perpetually paranoid about how many allocations my Python programs are doing behind the scenes...
  - rwmj 12y ago
    Chrome is a web browser, not a real time operating system.
  - ajuc 12y ago
    If you care about performance use std::performant_but_tricky_string. 99% of code doesn't care about string-related performance, but needs string anyway.
    - crpatino 12y ago
      If you care about performance at all, strings are going to slow you down in unexpected and counter-intuitive ways. Far better if you pass around text data as binary buffers (with metadata describing encoding, please), and only convert those to strings once they are ready to be consumed by the user (which is typically not where performance bottlenecks show up anyways)
fleitz 12y ago
So in C# (on the .NET VM) when you allocate a string that's more than 65K when does it get freed? I wouldn't call that 'working'.

agumonkey 12y ago

reminds me of the 100 functions perlism http://stackoverflow.com/questions/6016271/why-is-it-better-to-have-100-functions-operate-on-one-data-structure-than-10-fun http://stackoverflow.com/questions/6016271/why-is-it-better-...

bodyfour 12y ago

The real language problem is that classes are closed -- you can't add your own methods to std::string (other than operators) As a C++ program grows it's more and more tempting to make your own private string class (either by inheriting from std::string, encapsulating it, or reimplementing it) that interacts more naturally with your program's other types. I've done this myself. Of course this works great until you need to link to some other C++ library which has its own different string type. Honestly, if C++ added just allow classes to be reopened (even if they weren't granted access to private methods) a lot of the pressure to roll your own string would be diminished.

deleted 12y ago
[deleted]
pubby 12y ago
What's wrong with free functions?
- bodyfour 12y ago
  Nothing really, but it mean your extensions aren't really first class syntactically. A developer has to remember that they write s.size() but not s.count_utf8_codepoints(). Bjarne Stroustrup actually has an interesting proposal to fix this by unifying free functions and method call syntax in C++17 although the proposal sounds pretty aggressive to me: http://isocpp.org/files/papers/N4174.pdf http://isocpp.org/files/papers/N4174.pdf Would be an interesting change.
dragonwriter 12y ago
> Honestly, if C++ added just allow classes to be reopened (even if they weren't granted access to private methods) a lot of the pressure to roll your own string would be diminished. But then you'd have the problem with different extensions to the same base class used in different libraries used in the same project conflicting, so you'd also need to make a way to scope the extensions to prevent that.
- 12y ago