Comment by simias | Hacker News Reader

Comment by simias | Hacker News Reader

I wonder if C++ is headed for COBOL-ification. This article is very interesting but doesn't really give any hope for success in implementing a modern module system in C++.

I feel like the only way to have truly useful, simple and intuitive modules in C++ would involve breaking a certain amount of backward compatibility and force a few constraints (project layout, file naming scheme, build system, ...) on the user. But clearly that's not really in C++'s DNA and you risk ending up with something that's not quite C++ while at the same time not having the simplicity and elegance of modern languages that have been designed from scratch without all the baggage C++ carries.

C++ won't go away any time soon, that's for sure. But when I read articles like TFA or for instance https://bitbashing.io/std-visit.html my gut reaction is always that maybe if you get frustrated with C++'s extreme complexity, historical baggage and user-unfriendliness you should consider moving to something else instead of trying to bolt on even more exotic features on a language which is already crumbling under the weight of all the features and programing styles it already supports. I know I did.

As an example I stumbled upon this std::visit link by perusing the top posts of reddit's /c/cpp (linked by TFA), here's the discussion: https://www.reddit.com/r/cpp/comments/703k9k/stdvisit_is_eve...

There's an interesting thread about how:

    variant<string, int, bool> mySetting = "Hello!";

Doesn't do what one might thing it should do. The variant ends up holding a `true` boolean instead of a string. Why?

>char const* to bool is a standard conversion, but to std::string is a user-defined conversion. Standard conversion wins.

If you know C++'s history and its C heritage it makes sense but it sure as hell doesn't make me want to use C++ for my next project.

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;

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