Hacker News Reader

Comment by humanrebar | Hacker News Reader

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;

View on HN

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.

> 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*`).

In Haskell there is only one form of string literal. It looks like "this".

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).

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).

What do you mean by "lots of other ceremony"?

> 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.

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.

Right. I haven't written any Java in a while so it slipped my mind.

Same applies to any language derived from Algol linage.

Haskell has this with `Maybe`, although you could write the Bool instance yourself pretty easily if you liked.

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.

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.

Reply on news.ycombinator.com