6 ms·

More features, more libraries, but is there a working group that looks back at C++98 and tries to reduce complexity by removing mistakes from the language? My

More features, more libraries, but is there a working group that looks back at C++98 and tries to reduce complexity by removing mistakes from the language? My pet peeve is Argument-Dependent Lookup. It's a hack that breaks the encapsulation of namespaces, increases compile times and still makes it harder to write code - try swap()ing two values of type T in a template function. But like any of C++'s warts, it will be with us forever.

rl3 10y ago
>More features, more libraries, but is there a working group that looks back at C++98 and tries to reduce complexity by removing mistakes from the language? Then you break backwards compatibility. What about static analysis to enforce a particular subset of features deemed idiomatic or otherwise best practice? Granted, reducing complexity does make the job of future compiler authors far less miserable.
- ktRolster 10y ago
  What about static analysis to enforce a particular subset of features deemed idiomatic or otherwise best practice? I like that idea.
  - koja86 10y ago
    You might find this project kind of interesting: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... As a day-to-day C++ practitioner I like it. ...Yet I am not fully convinced that the general idea of language evolution implemented as ruleset outside of the language itself is the way to go. Seems more like band-aid to me and made me start to think about concept of programming language's life cycle in context of Darwinian evolution - once either legacy compatibility burden is too big or that particular biotope of specific problems the language solves better than others vanishes/changes the language dies out. My particular issue with C++ is that it's complexity, longevity and evolution made possible for widespread bad-practices as not every C++ developer evolved as much as the language itself and it's general public understanding. (Some current best-practices were simply not always widely known or accepted.) I would even go as far to say that most of existing C++ code is crap (at least from standpoint of today "modern" C++). And that's why I am both eagerly looking to "next generation" being shaped up by people who has (hopefully) learnt from past mistakes and used by people who care (itching to give Rust a ride once it stabilizes just a bit more) and also occasionally digging in the history for possible gems that I might not able to see without my current experience (platonic weekends-only relationship with Haskell, Lisp being right there at top of my TODO list). EDIT: Removed the sir.
    - rl3 10y ago
      >Sir, ... You may want to take a quick gander at the profile of whom you're replying to. :) >... itching to give Rust a ride once it stabilizes just a bit more ... Likewise, though from my limited research it seems Rust has legacy baggage of its own already, and there's difficulty in coming to a consensus on what qualifies as idiomatic Rust. It seems that the same principle of cherry-picking a subset of features would apply just the same to Rust as it does to C++. The latter being far messier, of course.
      - koja86 10y ago
        Thank you in both cases sir/madam/whatever :-)
      - adelarsq 10y ago
        Some things still are on nightly builds, so will take some time to be perfect, at least for me. I have plans to use in production on next months =)
      - echelon 10y ago
        > it seems Rust has legacy baggage of its own already What is considered legacy cruft in Rust? The only change I'm aware of was the introduction of the `?` operator to replace the `try!` macro. That's easy to find/replace.
        rl3 10y ago
        The notion extends to official libraries, not just the language itself. That said, I'm not the best person to ask, but cursory research turns up a few examples.[0][1][2][3] Some of these aren't examples of legacy cruft per se. However, as complexity is added to a language at a rapid rate, there becomes more confusion over what best practice actually is. [0] https://www.reddit.com/r/rust/comments/2r7ttq/where_to_find_idiomatic_rust_code_for_reference/ https://www.reddit.com/r/rust/comments/2r7ttq/where_to_find_... [1] https://users.rust-lang.org/t/rust-version-support-in-library-crates-best-practices/4405 https://users.rust-lang.org/t/rust-version-support-in-librar... [2] https://gist.github.com/lifthrasiir/cedb5db8dbcd209c5957 https://gist.github.com/lifthrasiir/cedb5db8dbcd209c5957 [3] https://users.rust-lang.org/t/is-this-idiomatic-rust/2155 https://users.rust-lang.org/t/is-this-idiomatic-rust/2155
Arwill 10y ago
Thats is why i've given up on C++. The new features might be nice, but i don't want to deal with those old hacks.
- jjuhl 10y ago
  Nobody is forcing you to use the old stuff. You can stick to the new nice bits and mostly just ignore the fact that the old crud exists in the language.
  - pjmlp 10y ago
    Sadly that is only true for the code that is under our control, which is seldom the case in most companies.
  - mateuszf 10y ago
    Unless you use libraries which are written in different styles, and have to read / fix them. Then you still have to remember / understand all the complexity.
    - petters 10y ago
      But in that case you are in no position to give up on C++ anyway, as your grandparent commenter did.
  - loup-vaillant 10y ago
    What a wonderful world would it be… Not being forced to used legacy C++ style. Not being forced to mind the undefined minefield. Not being forced to even use C++ in the many many cases where garbage collection is obviously fine… Sadly these days, I'm not paid to "solve problems". I'm paid to solve them in C++ —sometimes for good reasons.
  - PopsiclePete 10y ago
    That only works if you're on a one-man project where you use the STL and implement everything else from scratch.
WalterBright 10y ago
The trouble with namespaces is they are not encapsulated (even without ADL). Any piece of code can open up any namespace and add symbols to it. Not being able to reliably determine what is the set of symbols being overloaded in a namespace, for example, makes it hard to reason about.
- gurkendoktor 10y ago
  When writing a container, I'd actually prefer to open namespace std and overload std::begin and std::end for my_namespace::container. That way, I'd be free to use my_namespace::begin for something else, which IMHO is the point of namespaces. But having ADL and being able to re-open other people's namespaces is definitely unfortunate. I love the Objective-C convention of just using three-letter prefixes for everything. I'll miss its pragmatic approach.
vl 10y ago
I know, ADL makes it impossible to refactor anything in company-scale codebase without extraordinary efforts. Google has a team and special toolset to do just that. Also, how to use swap correctly? (Now, with std::move is less relevant though): template bla-bla { using std::swap; swap(result, computed); } Sure, I could have guessed this is correct way of using it by myself...
- gurkendoktor 10y ago
  std::begin suffers from the same problem and will stay relevant for longer. The cppreference.com docs specifically mention the "using trick"[1], so it seems to be an established pattern now. It's still ridiculous - calling a function should be easy :( [1] http://en.cppreference.com/w/cpp/iterator/begin http://en.cppreference.com/w/cpp/iterator/begin

rl3 10y ago

>More features, more libraries, but is there a working group that looks back at C++98 and tries to reduce complexity by removing mistakes from the language? Then you break backwards compatibility. What about static analysis to enforce a particular subset of features deemed idiomatic or otherwise best practice? Granted, reducing complexity does make the job of future compiler authors far less miserable.

ktRolster 10y ago
What about static analysis to enforce a particular subset of features deemed idiomatic or otherwise best practice? I like that idea.
- koja86 10y ago
  You might find this project kind of interesting: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... As a day-to-day C++ practitioner I like it. ...Yet I am not fully convinced that the general idea of language evolution implemented as ruleset outside of the language itself is the way to go. Seems more like band-aid to me and made me start to think about concept of programming language's life cycle in context of Darwinian evolution - once either legacy compatibility burden is too big or that particular biotope of specific problems the language solves better than others vanishes/changes the language dies out. My particular issue with C++ is that it's complexity, longevity and evolution made possible for widespread bad-practices as not every C++ developer evolved as much as the language itself and it's general public understanding. (Some current best-practices were simply not always widely known or accepted.) I would even go as far to say that most of existing C++ code is crap (at least from standpoint of today "modern" C++). And that's why I am both eagerly looking to "next generation" being shaped up by people who has (hopefully) learnt from past mistakes and used by people who care (itching to give Rust a ride once it stabilizes just a bit more) and also occasionally digging in the history for possible gems that I might not able to see without my current experience (platonic weekends-only relationship with Haskell, Lisp being right there at top of my TODO list). EDIT: Removed the sir.
  - rl3 10y ago
    >Sir, ... You may want to take a quick gander at the profile of whom you're replying to. :) >... itching to give Rust a ride once it stabilizes just a bit more ... Likewise, though from my limited research it seems Rust has legacy baggage of its own already, and there's difficulty in coming to a consensus on what qualifies as idiomatic Rust. It seems that the same principle of cherry-picking a subset of features would apply just the same to Rust as it does to C++. The latter being far messier, of course.
    - koja86 10y ago
      Thank you in both cases sir/madam/whatever :-)
    - adelarsq 10y ago
      Some things still are on nightly builds, so will take some time to be perfect, at least for me. I have plans to use in production on next months =)
    - echelon 10y ago
      > it seems Rust has legacy baggage of its own already What is considered legacy cruft in Rust? The only change I'm aware of was the introduction of the `?` operator to replace the `try!` macro. That's easy to find/replace.
      - rl3 10y ago
        The notion extends to official libraries, not just the language itself. That said, I'm not the best person to ask, but cursory research turns up a few examples.[0][1][2][3] Some of these aren't examples of legacy cruft per se. However, as complexity is added to a language at a rapid rate, there becomes more confusion over what best practice actually is. [0] https://www.reddit.com/r/rust/comments/2r7ttq/where_to_find_idiomatic_rust_code_for_reference/ https://www.reddit.com/r/rust/comments/2r7ttq/where_to_find_... [1] https://users.rust-lang.org/t/rust-version-support-in-library-crates-best-practices/4405 https://users.rust-lang.org/t/rust-version-support-in-librar... [2] https://gist.github.com/lifthrasiir/cedb5db8dbcd209c5957 https://gist.github.com/lifthrasiir/cedb5db8dbcd209c5957 [3] https://users.rust-lang.org/t/is-this-idiomatic-rust/2155 https://users.rust-lang.org/t/is-this-idiomatic-rust/2155

Arwill 10y ago

Thats is why i've given up on C++. The new features might be nice, but i don't want to deal with those old hacks.

jjuhl 10y ago
Nobody is forcing you to use the old stuff. You can stick to the new nice bits and mostly just ignore the fact that the old crud exists in the language.
- pjmlp 10y ago
  Sadly that is only true for the code that is under our control, which is seldom the case in most companies.
- mateuszf 10y ago
  Unless you use libraries which are written in different styles, and have to read / fix them. Then you still have to remember / understand all the complexity.
  - petters 10y ago
    But in that case you are in no position to give up on C++ anyway, as your grandparent commenter did.
- loup-vaillant 10y ago
  What a wonderful world would it be… Not being forced to used legacy C++ style. Not being forced to mind the undefined minefield. Not being forced to even use C++ in the many many cases where garbage collection is obviously fine… Sadly these days, I'm not paid to "solve problems". I'm paid to solve them in C++ —sometimes for good reasons.
- PopsiclePete 10y ago
  That only works if you're on a one-man project where you use the STL and implement everything else from scratch.

WalterBright 10y ago

The trouble with namespaces is they are not encapsulated (even without ADL). Any piece of code can open up any namespace and add symbols to it. Not being able to reliably determine what is the set of symbols being overloaded in a namespace, for example, makes it hard to reason about.

gurkendoktor 10y ago
When writing a container, I'd actually prefer to open namespace std and overload std::begin and std::end for my_namespace::container. That way, I'd be free to use my_namespace::begin for something else, which IMHO is the point of namespaces. But having ADL and being able to re-open other people's namespaces is definitely unfortunate. I love the Objective-C convention of just using three-letter prefixes for everything. I'll miss its pragmatic approach.

vl 10y ago

I know, ADL makes it impossible to refactor anything in company-scale codebase without extraordinary efforts. Google has a team and special toolset to do just that. Also, how to use swap correctly? (Now, with std::move is less relevant though): template bla-bla { using std::swap; swap(result, computed); } Sure, I could have guessed this is correct way of using it by myself...

gurkendoktor 10y ago
std::begin suffers from the same problem and will stay relevant for longer. The cppreference.com docs specifically mention the "using trick"[1], so it seems to be an established pattern now. It's still ridiculous - calling a function should be easy :( [1] http://en.cppreference.com/w/cpp/iterator/begin http://en.cppreference.com/w/cpp/iterator/begin