2 ms·

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 sys

by simias 9y ago

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

humanrebar 9y ago
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).

by simias 9y ago

humanrebar 9y ago

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