4 ms·

C++ is pretty close to treating unqualified string literals the same as native pointers. That is, there for backwards compatibility and for rare edge cases, but

C++ is pretty close to treating unqualified string literals the same as native pointers. That is, there for backwards compatibility and for rare edge cases, but generally discouraged. I predict that, given a few years, we'll start adding checks to linters and static analyzers to warn about using them because of the ambiguity and implicit conversion issues. There is already a std::string liberal. Better: MyVariant mySetting = "Hello!"s; But std::string_view more closely models a string literal. std::string is more of a string buffer. So even better: MyVariant mySetting = "Hello!"sv;

simias 9y ago
That's good to know but it kind of proves my point, doesn't it? Do you know many languages where literal strings come with a big warning sign saying "probably not what you want, use this (rather opaque) alternative syntax instead"? The fact that pointers automatically coerce into bools makes some sense in C but is an aberration for modern C++. It's just an example of a legacy "feature" pointing its ugly head to sabotage a modern C++ construct. If you look at C++ guidelines out there a lot of it is about what par of C++ not to use. Don't use raw pointers, don't use raw arrays, use exceptions, don't use exceptions, maybe use exceptions but only in some cases... And a lot of the time the most intuitive notation, the one that goes all the way back to C, is also the one you don't want to use. Don't use "Hello, world!", use "Hello, world!"sv. What does the sv do exactly? Uh, we'll talk about that in chapter 27 when we talk about user-defined literals. This is right between the chapter about suffix return types and the one about variadic templates.
- smitherfield 9y ago
  > Do you know many languages where literal strings come with a big warning sign saying "probably not what you want, use this (rather opaque) alternative syntax instead"? Haskell? Python 2? (Also, C/C++ string literals are perfectly safe to use — they're guaranteed-null-terminated immutable arrays that implicitly convert to `string` and `string_view`; it's more that its safer in modern C++ for function parameters to be `string_view`/`string`/`const char(&)[N]` instead of `const char*`).
  - nh2 9y ago
    In Haskell there is only one form of string literal. It looks like "this".
    - smitherfield 9y ago
      Yes, but to get a reasonable string implementation you need {-# LANGUAGE OverloadedStrings #-} plus lots of other ceremony. (There's only one form of string literal in C++ too; the "s" and "sv" suffixes shown above are operators, not part of the literal).
      - fusiongyro 9y ago
        Adding to your point, there are two string types you should use in Haskell (ByteString and Text) and neither of them are the type you get from an unadorned string literal (absent OverloadedStrings and some expectations).
      - lomnakkus 9y ago
        What do you mean by "lots of other ceremony"?
- smitherfield 9y ago
  > The fact that pointers automatically coerce into bools makes some sense in C but is an aberration for modern C++. It's just an example of a legacy "feature" pointing its ugly head to sabotage a modern C++ construct. This is a rather odd complaint; I can't think of any programming language which has first-class support for nullable types, and where they aren't truthy/falsy, at least in conditional contexts. It's a pretty straightforward boilerplate-reducing idiom. Did you mean to say builtin arrays coercing to pointers? (I'd agree that's probably the biggest problem with C and, by extension, C++). Or did you mean `NULL` being an `intptr_t` in C++? That's the very rare C++ misfeature that doesn't come from C (where it's a `void*`), but at least C++11 `nullptr` fixes that.
  - kibwen 9y ago
    Java is a language where nullable types aren't truthy/falsy. The following code won't compile: String foo = null; if (foo) { // error: incompatible types: String cannot be converted to boolean System.out.println("was true"); } else { System.out.println("was false"); } If one changes `if (foo)` to `if (foo != null)`, then the code will compile.
    - smitherfield 9y ago
      Right. I haven't written any Java in a while so it slipped my mind.
      - pjmlp 9y ago
        Same applies to any language derived from Algol linage.
  - Y_Y 9y ago
    Haskell has this with `Maybe`, although you could write the Bool instance yourself pretty easily if you liked.
- pjmlp 9y ago
  I agree with you, but as Bjarne points out in "Design and Evolution of C++", without its 99% copy-paste compatibility with C, C with Classes would never had taken off inside AT&T. It was his solution for not having to touch such a low level language, after being forced to exchange Simula for BCPL. So yeah C++ is plagued with C compatibility, but it does provide enough tooling for anyone that cares about strong typing and safety. Better alternatives are needed, but they will only get wide scale adoption like Apple is doing with Swift, pushing full speed ahead regardless of what devs think. Hence why for me, even if it isn't ideal, Java / .NET languages + C++ for low level stuff is already kind of sweet spot.
- RotsiserMho 9y ago
  I'd say for strings it's entirely domain dependent. Many problem domain's won't ever use `std::variant` but may require that all strings live in ROM, so for those domains the default behavior makes perfect sense. If you want to compare C++ to modern languages, I get it, it's obtuse, but C++ is also used in instances where other languages can't be and so has to at least support doing things that may be unintuitive in other domains. That being said it would be nice if we could deprecate things with wholly better replacements like raw pointers, raw arrays, etc.

simias 9y ago

That's good to know but it kind of proves my point, doesn't it? Do you know many languages where literal strings come with a big warning sign saying "probably not what you want, use this (rather opaque) alternative syntax instead"? The fact that pointers automatically coerce into bools makes some sense in C but is an aberration for modern C++. It's just an example of a legacy "feature" pointing its ugly head to sabotage a modern C++ construct. If you look at C++ guidelines out there a lot of it is about what par of C++ not to use. Don't use raw pointers, don't use raw arrays, use exceptions, don't use exceptions, maybe use exceptions but only in some cases... And a lot of the time the most intuitive notation, the one that goes all the way back to C, is also the one you don't want to use. Don't use "Hello, world!", use "Hello, world!"sv. What does the sv do exactly? Uh, we'll talk about that in chapter 27 when we talk about user-defined literals. This is right between the chapter about suffix return types and the one about variadic templates.

smitherfield 9y ago
> Do you know many languages where literal strings come with a big warning sign saying "probably not what you want, use this (rather opaque) alternative syntax instead"? Haskell? Python 2? (Also, C/C++ string literals are perfectly safe to use — they're guaranteed-null-terminated immutable arrays that implicitly convert to `string` and `string_view`; it's more that its safer in modern C++ for function parameters to be `string_view`/`string`/`const char(&)[N]` instead of `const char*`).
- nh2 9y ago
  In Haskell there is only one form of string literal. It looks like "this".
  - smitherfield 9y ago
    Yes, but to get a reasonable string implementation you need {-# LANGUAGE OverloadedStrings #-} plus lots of other ceremony. (There's only one form of string literal in C++ too; the "s" and "sv" suffixes shown above are operators, not part of the literal).
    - fusiongyro 9y ago
      Adding to your point, there are two string types you should use in Haskell (ByteString and Text) and neither of them are the type you get from an unadorned string literal (absent OverloadedStrings and some expectations).
    - lomnakkus 9y ago
      What do you mean by "lots of other ceremony"?
smitherfield 9y ago
> The fact that pointers automatically coerce into bools makes some sense in C but is an aberration for modern C++. It's just an example of a legacy "feature" pointing its ugly head to sabotage a modern C++ construct. This is a rather odd complaint; I can't think of any programming language which has first-class support for nullable types, and where they aren't truthy/falsy, at least in conditional contexts. It's a pretty straightforward boilerplate-reducing idiom. Did you mean to say builtin arrays coercing to pointers? (I'd agree that's probably the biggest problem with C and, by extension, C++). Or did you mean `NULL` being an `intptr_t` in C++? That's the very rare C++ misfeature that doesn't come from C (where it's a `void*`), but at least C++11 `nullptr` fixes that.
- kibwen 9y ago
  Java is a language where nullable types aren't truthy/falsy. The following code won't compile: String foo = null; if (foo) { // error: incompatible types: String cannot be converted to boolean System.out.println("was true"); } else { System.out.println("was false"); } If one changes `if (foo)` to `if (foo != null)`, then the code will compile.
  - smitherfield 9y ago
    Right. I haven't written any Java in a while so it slipped my mind.
    - pjmlp 9y ago
      Same applies to any language derived from Algol linage.
- Y_Y 9y ago
  Haskell has this with `Maybe`, although you could write the Bool instance yourself pretty easily if you liked.
pjmlp 9y ago
I agree with you, but as Bjarne points out in "Design and Evolution of C++", without its 99% copy-paste compatibility with C, C with Classes would never had taken off inside AT&T. It was his solution for not having to touch such a low level language, after being forced to exchange Simula for BCPL. So yeah C++ is plagued with C compatibility, but it does provide enough tooling for anyone that cares about strong typing and safety. Better alternatives are needed, but they will only get wide scale adoption like Apple is doing with Swift, pushing full speed ahead regardless of what devs think. Hence why for me, even if it isn't ideal, Java / .NET languages + C++ for low level stuff is already kind of sweet spot.
RotsiserMho 9y ago
I'd say for strings it's entirely domain dependent. Many problem domain's won't ever use `std::variant` but may require that all strings live in ROM, so for those domains the default behavior makes perfect sense. If you want to compare C++ to modern languages, I get it, it's obtuse, but C++ is also used in instances where other languages can't be and so has to at least support doing things that may be unintuitive in other domains. That being said it would be nice if we could deprecate things with wholly better replacements like raw pointers, raw arrays, etc.