8 ms·

I'm curious why std::string is badly designed?

Aeolos 11y ago
I'm also curious why. I wonder if any of the original designers ever shared any insight into their design process. As for what is wrong with it, multiple things. My personal pet peeves are: 1. the lack of formatting or interpolation support (i.e. QString::number(3.14, 'f', 2) or QString("Hello, %d!").arg("world") 2. the utter lack of Unicode support I've seen other people complain about how it interacts with <algorithm>, inefficient support for common operations (join, split, copy) and mutability. I don't particularly care about these, given that its lack of Unicode support pretty much relegates it to a glorified std::vector<char> implementation for me.
- pjmlp 11y ago
  Yes, you can read "The Design and Evolution of C++" and the "The Annotated C++ Reference Manual" aka C++ ARM. There you will understand why C++ is the way it is, when you are trying to sell a safer language with higher level abstractions to hardcore C developers at AT&T, with zero friction with existing C toolchains. Many like me hate the C underpinnings of C++, but if it wasn't for them, most likely no C vendor would ever have adopted it.
  - reality_czech 11y ago
    I'm tired of people blaming the bad things in C++ on C. Most of the bad things in C++ came from C++ itself, not from anywhere else. The Modula-3 type system with its inheritance anti-patterns can't be found anywhere in C. "Guru meditation" template error messages can't be found anywhere in C, nor do C programs typically take hours to compile. In C, functions and types that are "static" to a file don't appear in header files... C++ "improved" that so that private types and functions must appear in header files, greatly extending compile times. Global constructors are not in C... you know what order your program will run in when using C. The set of things in C that were "fixed" by C++ is very small, possibly even the empty set for reasonably modern dialects of C. For example, having the compiler implicitly declare functions as returning "int" was on its way out with or without C++. Probably the worst thing about C was all the implicit type conversions-- between long and int, and char* and boolean. Of course C++ didn't fix this. They even made it worse by declaring that any C++ constructor that took one argument would be a candidate for implicit type conversion. So if you declared Foo::Foo(int i), in the future any time you have an int the compiler would consider promoting it to a Foo. Later they realized their mistake and added the "explicit" keyword so C++ gurus can avoid this error most of the time (when they remember).
    - hellofunk 11y ago
      The new syntax using curly braces to initialize a variable disallows type conversion and is the recommended method now iirc.
      - reality_czech 11y ago
        OK, so C++ came out in 1984, and it only took them 30 years to add a way to bypass the implicit conversions they added to the language. Just once, I'd like to hear a C++ advocate say "we made a mistake." Of course it won't happen, so it's time to deny, obfuscate, and redirect blame.
        hellofunk 11y ago
        Bjarne has been very open over the years about mistakes he thinks affected parts of c++'s development. There is no perfect language but c++ does keep trying to improve.
        unscaled 11y ago
        Hey, C came earlier and strcat is still in the standard, as well as non-prototyped function calls. Someone told me FORTRAN still maintains backward compatibility with arithmetic ifs, and it's been like, what, 60 years? Strange that.
        reality_czech 11y ago
        You are comparing apples and oranges. strcat is a library function which is easy to avoid, whereas the implicit type conversion behavior is part of the core C++ language and very difficult to escape. Non-prototyped function calls are there, but they trigger warnings on any compiler from the last 3 decades. Anyway, thanks for playing the "deny, obfuscate, shift blame for broken C++ design decisions" game.
    - nickpsecurity 11y ago
      You're saying directly, C-level style and compatibility at a language-level in early C++ couldn't negatively impact its safety or maintainability vs Modula-2/3, etc? I highly doubt that given most crashes early on were C++ being done in a C-like style, using C runtimes, or calling C OS functions. The C++ style modernists here advocate greatly reduces problems outside compile times. So, I'm a C++ opponent but it's still obvious C dragged it down a lot. Stroustrup's writings on its origins and why he made specific tradeoffs shows it's a fact. There were often more ideal stuff, from high-level perspective, that wouldn't fit with C, would break legacy, or would take a performance hit C developers would reject. None was allowed as C developer adoption was main goal. We failed to convince them to use lots of other low-level languages, too. C developers are picky. So, their foundation of quicksand remains a the bottom.

I'm also curious why. I wonder if any of the original designers ever shared any insight into their design process. As for what is wrong with it, multiple things. My personal pet peeves are: 1. the lack of formatting or interpolation support (i.e. QString::number(3.14, 'f', 2) or QString("Hello, %d!").arg("world") 2. the utter lack of Unicode support I've seen other people complain about how it interacts with <algorithm>, inefficient support for common operations (join, split, copy) and mutability. I don't particularly care about these, given that its lack of Unicode support pretty much relegates it to a glorified std::vector<char> implementation for me.

pjmlp 11y ago
Yes, you can read "The Design and Evolution of C++" and the "The Annotated C++ Reference Manual" aka C++ ARM. There you will understand why C++ is the way it is, when you are trying to sell a safer language with higher level abstractions to hardcore C developers at AT&T, with zero friction with existing C toolchains. Many like me hate the C underpinnings of C++, but if it wasn't for them, most likely no C vendor would ever have adopted it.
- reality_czech 11y ago
  I'm tired of people blaming the bad things in C++ on C. Most of the bad things in C++ came from C++ itself, not from anywhere else. The Modula-3 type system with its inheritance anti-patterns can't be found anywhere in C. "Guru meditation" template error messages can't be found anywhere in C, nor do C programs typically take hours to compile. In C, functions and types that are "static" to a file don't appear in header files... C++ "improved" that so that private types and functions must appear in header files, greatly extending compile times. Global constructors are not in C... you know what order your program will run in when using C. The set of things in C that were "fixed" by C++ is very small, possibly even the empty set for reasonably modern dialects of C. For example, having the compiler implicitly declare functions as returning "int" was on its way out with or without C++. Probably the worst thing about C was all the implicit type conversions-- between long and int, and char* and boolean. Of course C++ didn't fix this. They even made it worse by declaring that any C++ constructor that took one argument would be a candidate for implicit type conversion. So if you declared Foo::Foo(int i), in the future any time you have an int the compiler would consider promoting it to a Foo. Later they realized their mistake and added the "explicit" keyword so C++ gurus can avoid this error most of the time (when they remember).
  - hellofunk 11y ago
    The new syntax using curly braces to initialize a variable disallows type conversion and is the recommended method now iirc.
    - reality_czech 11y ago
      OK, so C++ came out in 1984, and it only took them 30 years to add a way to bypass the implicit conversions they added to the language. Just once, I'd like to hear a C++ advocate say "we made a mistake." Of course it won't happen, so it's time to deny, obfuscate, and redirect blame.
      - hellofunk 11y ago
        Bjarne has been very open over the years about mistakes he thinks affected parts of c++'s development. There is no perfect language but c++ does keep trying to improve.
      - unscaled 11y ago
        Hey, C came earlier and strcat is still in the standard, as well as non-prototyped function calls. Someone told me FORTRAN still maintains backward compatibility with arithmetic ifs, and it's been like, what, 60 years? Strange that.
        reality_czech 11y ago
        You are comparing apples and oranges. strcat is a library function which is easy to avoid, whereas the implicit type conversion behavior is part of the core C++ language and very difficult to escape. Non-prototyped function calls are there, but they trigger warnings on any compiler from the last 3 decades. Anyway, thanks for playing the "deny, obfuscate, shift blame for broken C++ design decisions" game.
  - nickpsecurity 11y ago
    You're saying directly, C-level style and compatibility at a language-level in early C++ couldn't negatively impact its safety or maintainability vs Modula-2/3, etc? I highly doubt that given most crashes early on were C++ being done in a C-like style, using C runtimes, or calling C OS functions. The C++ style modernists here advocate greatly reduces problems outside compile times. So, I'm a C++ opponent but it's still obvious C dragged it down a lot. Stroustrup's writings on its origins and why he made specific tradeoffs shows it's a fact. There were often more ideal stuff, from high-level perspective, that wouldn't fit with C, would break legacy, or would take a performance hit C developers would reject. None was allowed as C developer adoption was main goal. We failed to convince them to use lots of other low-level languages, too. C developers are picky. So, their foundation of quicksand remains a the bottom.