7 ms·

This suggests you aren't aware of the many huge benefits that have come from introducing modern features that other languages have. C++ since 2011 is quite a di

This suggests you aren't aware of the many huge benefits that have come from introducing modern features that other languages have. C++ since 2011 is quite a different language to what it was before, and this is hardly a bad thing. So many of the challenges of writing C++ were significantly simplified with the introduction of lambdas, smart pointers, and threading primitives.

arcticbull 7y ago
The issue isn't that it gets new features it's that they're half-assed because you can't impose new restrictions on old code. The power of these features in modern languages comes from their ability to protect you from yourself. That has more to do with what you can't do than what you can. Bolting more legs onto C++ doesn't protect you from anything, it just increases the surface area of the language. They haven't introduced the features other language have, they've introduced poor rip-offs that fail to work as one might expect having worked in any of the other languages they're derived from. The problem is it's not different than it used to be, the cracked foundations are exactly the same as they've always been always been but there's a bigger and more complicated house on them. C++ is starting to feel like the Winchester mystery house.
- jdsully 7y ago
  The C++ philosophy is not about protecting you from yourself. Its about allowing you to express your idea in as low or high level terms as you require. This lets you write a highly optimized tight loop and then abstractly describe less performance sensitive parts. In the past it was thought that people would use safer high level languages and then drop down to C for performance. That vision just doesn’t seem to work out in practice - except at the cross process level. The trade off to this is language complexity. If you want a simple language C++ isn’t for you - and that’s OK.
  - marcosdumay 7y ago
    > That vision just doesn’t seem to work out in practice Well, about half of the Python ecosystem seems to disagree.
    - jdsully 7y ago
      Python is likely the best example of this working, however even in Python the boundaries between high and low performance sections are very formal. It's a lot simpler to go in and optimize a piece of code the profiler has pointed out with C++. I really don't understand the animosity non-C++ developers have towards the language. You can still use Python, Rust, etc if you want. Nobody wants to force you to use C++.
      - hawski 7y ago
        I am a C++ developer by career. Me and many other C++ developers I know do not really like the language. It is what it is. It has useful parts, but complexity is a weight.
        clappski 7y ago
        How do you end up being a C++ developer that hates the language? I’m a C++ developer as well, and if I ever decided that’s I didn’t like what I was doing every day I’d learn a different language and try to get hired for that.
        arcticbull 7y ago
        I’ve been an iOS engineer for 7 years and I’m not exactly a fan of Objective-C. I’m good at it though, I know where all the sore spots are and part of my value is I can stop people from hurting themselves with the language. One day, inshallah, our team can eventually move on to swift (thank you ABI compatibility). Until then I work in it because my goal (and my job) is to deliver amazing products and experiences to my customers and if I had to do that in COBOL, I’d do that too. My job is not about the language for me, it’s about what I’m doing with it.
      - 7y ago
  - deleted 7y ago
    [deleted]
  - hawski 7y ago
    C++ for me was and with every newer standard is really a meta language. It is used by many big projects to build their own "language". Such a language is almost completely ad-hoc and does not enjoy compiler checks, because it lives in project guidelines. It may enjoy some checks thanks to whole template machinery. But error messages barf about templates not a real intention behind them. Every big project is almost entirely different. They use different sets of features - some overlap more, some less. Many developers like to use C libraries, because they are easy to wrap in their version of C++. When you shop for libraries you often have to think if their version of C++ will work with yours. There is some consensus around STL and Boost, so at least that is relatively straightforward.
    - jdsully 7y ago
      There seems to be a more modern trend of wanting all code to look the same. I've worked in large projects that have existed over many eras (including as far back as K&R C). The "Refactor when it becomes a problem" seems to work amazingly well. Global refactors and project wide styles seem to always fail miserably - inevitably a new era comes before the previous standardization effort completes. E.g. in the C->C++ transition most malloc's were left alone. If you wanted to add a ctor/dtor then you would go refactor them as necessary. It also encouraged you to encapsulate your work moreso than you would have otherwise.
      - 0815test 7y ago
        "Global refactors" work well with type system support, and not at all otherwise - and more modern languages do tend to come with better such support. Even for C++ itself, LLVM has a few bespoke tools to help you refactor old code as suggested by the semi-official C++ Core Guidelines - of course not all possible "refactors" are equally supported!
      - roca 7y ago
        A project where different modules are written in different C++ dialects is a real pain when you have to refactor code across modules or even just write or review code in different modules. And the finer the granularity at which you allow dialects to be mixed (within a module, within a file, within a function), the more horrible it gets. Every time you make a change you need to think "what dialect am I supposed to be using here?" The mental surface area required to understand code grows and grows. But it is also true that forcing all the code in a project to use a single dialect is expensive. Developers need to decide what that dialect is --- not just once, but constantly as C++ evolves. ("Is it time to use Ranges yet? Concepts?" etc.) You need to do expensive refactors every time you update the dialect. You need to enforce the dialect at code review time (harder as it changes). Every time you import third-party code into the project you need to update its dialect. A constantly evolving language that regularly deprecates commonly-used features in favour of "better" alternatives, like C++ does, is problematic. The faster pace of C++ evolution is making this problem worse.
- AnimalMuppet 7y ago
  The fact that you can't make old code use the new features in no way makes the new features "half-assed". It may make the old code that, but not the features. Or did you want them to deprecate large swathes of the previous standard? As for the rest of your rant... it's mostly just a rant, with very little substance.
- hellofunk 7y ago
  > they've introduced poor rip-offs that fail to work This sounds like hyperbole to me. I've worked in other functional languages professionally for many years, but when I write C++ with consistent use of std::function and lambdas, I get many of the same benefits and a very enjoyable workflow. Is it the same as Haskell or Clojure? No, because they are totally different languages. But within the C++ world, they offer a great productivity benefit that I don't think satisifies the definition of "rip off".
  - arcticbull 7y ago
    Not all of them, to be sure, lambdas and in particular their capture list syntax is solid. By no means is that universal though, for instance, move semantics. std::move doesn't move anything, it casts an object as a movable reference (equivalent to static_cast<T&&>). The compiler doesn't preclude you from accessing the old object (or say anything at all) and there's no guarantee it actually did get moved, it's just a hint. That's not real move semantics, it's a shoddy knock-off. You also have to manage a new constructor, new reference type and the opt-in because the default remains not using move semantics. Worse yet, there's varying agreement on what you can or should do with the source of a moved value, the STL containers will all continue to let you use the old value, it's just empty now. That's not standard behavior because there is none, and it's de facto now because it's in the STL. What a nightmare. [1] std::variant is supposed to be associated values on enums, but of course, it doesn't do that either. You don't match, you create a new struct with a bunch of operator() methods on it [or overload a lambda?!] and throw it at std::visit. You can only have one variant of each type. Then it throws exceptions if you start mucking about in ways you shouldn't. There's no context. It's dreadful. [2] [1] http://yacoder.guru/blog/2015/03/14/cpp-curiosities-std-move-that-doesnt-move/ http://yacoder.guru/blog/2015/03/14/cpp-curiosities-std-move... [2] https://www.bfilipek.com/2018/06/variant.html https://www.bfilipek.com/2018/06/variant.html
    - roca 7y ago
      Lambda captures make it pretty easy to create nasty memory safety issues via dangling references. Sure, you could create such issues with the equivalent manually written closure-structs, but lambda captures pave the dangerous path.
rrss 7y ago
Those are all C++11 features, right? So they aren't much of an argument in favor of 14, 17, 20.
- blub 7y ago
  14, 17 and 20 are full of small and big improvements: coroutines, contracts, modules, concepts, huge improvements for compile-time computation with constexpr, etc.
- hellofunk 7y ago
  As an example, yes. Other versions offered similar benefits (C++14 in particular was a "bug fix" version for C++11, which I think most would be happy came quickly).
- MauranKilom 7y ago
  We also got Class Template Argument Deduction, structured bindings, various syntactic sugar (if (auto var = initializer) {}, if constexpr, fold expressions...), std::variant, std::optional, and a whole POSIX-style filesystem library, to name a few. And that's just C++17 alone. It's nothing earth-shattering (that stuff is coming in C++20) but these are all features that improve the language and allow you to write better code. Consider e.g. if constexpr which can eliminate so much SFINAE cruft. Or CTAD to reduce the need for makeXYZ() functions.

arcticbull 7y ago

The issue isn't that it gets new features it's that they're half-assed because you can't impose new restrictions on old code. The power of these features in modern languages comes from their ability to protect you from yourself. That has more to do with what you can't do than what you can. Bolting more legs onto C++ doesn't protect you from anything, it just increases the surface area of the language. They haven't introduced the features other language have, they've introduced poor rip-offs that fail to work as one might expect having worked in any of the other languages they're derived from. The problem is it's not different than it used to be, the cracked foundations are exactly the same as they've always been always been but there's a bigger and more complicated house on them. C++ is starting to feel like the Winchester mystery house.

jdsully 7y ago
The C++ philosophy is not about protecting you from yourself. Its about allowing you to express your idea in as low or high level terms as you require. This lets you write a highly optimized tight loop and then abstractly describe less performance sensitive parts. In the past it was thought that people would use safer high level languages and then drop down to C for performance. That vision just doesn’t seem to work out in practice - except at the cross process level. The trade off to this is language complexity. If you want a simple language C++ isn’t for you - and that’s OK.
- marcosdumay 7y ago
  > That vision just doesn’t seem to work out in practice Well, about half of the Python ecosystem seems to disagree.
  - jdsully 7y ago
    Python is likely the best example of this working, however even in Python the boundaries between high and low performance sections are very formal. It's a lot simpler to go in and optimize a piece of code the profiler has pointed out with C++. I really don't understand the animosity non-C++ developers have towards the language. You can still use Python, Rust, etc if you want. Nobody wants to force you to use C++.
    - hawski 7y ago
      I am a C++ developer by career. Me and many other C++ developers I know do not really like the language. It is what it is. It has useful parts, but complexity is a weight.
      - clappski 7y ago
        How do you end up being a C++ developer that hates the language? I’m a C++ developer as well, and if I ever decided that’s I didn’t like what I was doing every day I’d learn a different language and try to get hired for that.
        arcticbull 7y ago
        I’ve been an iOS engineer for 7 years and I’m not exactly a fan of Objective-C. I’m good at it though, I know where all the sore spots are and part of my value is I can stop people from hurting themselves with the language. One day, inshallah, our team can eventually move on to swift (thank you ABI compatibility). Until then I work in it because my goal (and my job) is to deliver amazing products and experiences to my customers and if I had to do that in COBOL, I’d do that too. My job is not about the language for me, it’s about what I’m doing with it.
    - 7y ago
- deleted 7y ago
  [deleted]
- hawski 7y ago
  C++ for me was and with every newer standard is really a meta language. It is used by many big projects to build their own "language". Such a language is almost completely ad-hoc and does not enjoy compiler checks, because it lives in project guidelines. It may enjoy some checks thanks to whole template machinery. But error messages barf about templates not a real intention behind them. Every big project is almost entirely different. They use different sets of features - some overlap more, some less. Many developers like to use C libraries, because they are easy to wrap in their version of C++. When you shop for libraries you often have to think if their version of C++ will work with yours. There is some consensus around STL and Boost, so at least that is relatively straightforward.
  - jdsully 7y ago
    There seems to be a more modern trend of wanting all code to look the same. I've worked in large projects that have existed over many eras (including as far back as K&R C). The "Refactor when it becomes a problem" seems to work amazingly well. Global refactors and project wide styles seem to always fail miserably - inevitably a new era comes before the previous standardization effort completes. E.g. in the C->C++ transition most malloc's were left alone. If you wanted to add a ctor/dtor then you would go refactor them as necessary. It also encouraged you to encapsulate your work moreso than you would have otherwise.
    - 0815test 7y ago
      "Global refactors" work well with type system support, and not at all otherwise - and more modern languages do tend to come with better such support. Even for C++ itself, LLVM has a few bespoke tools to help you refactor old code as suggested by the semi-official C++ Core Guidelines - of course not all possible "refactors" are equally supported!
    - roca 7y ago
      A project where different modules are written in different C++ dialects is a real pain when you have to refactor code across modules or even just write or review code in different modules. And the finer the granularity at which you allow dialects to be mixed (within a module, within a file, within a function), the more horrible it gets. Every time you make a change you need to think "what dialect am I supposed to be using here?" The mental surface area required to understand code grows and grows. But it is also true that forcing all the code in a project to use a single dialect is expensive. Developers need to decide what that dialect is --- not just once, but constantly as C++ evolves. ("Is it time to use Ranges yet? Concepts?" etc.) You need to do expensive refactors every time you update the dialect. You need to enforce the dialect at code review time (harder as it changes). Every time you import third-party code into the project you need to update its dialect. A constantly evolving language that regularly deprecates commonly-used features in favour of "better" alternatives, like C++ does, is problematic. The faster pace of C++ evolution is making this problem worse.
AnimalMuppet 7y ago
The fact that you can't make old code use the new features in no way makes the new features "half-assed". It may make the old code that, but not the features. Or did you want them to deprecate large swathes of the previous standard? As for the rest of your rant... it's mostly just a rant, with very little substance.
hellofunk 7y ago
> they've introduced poor rip-offs that fail to work This sounds like hyperbole to me. I've worked in other functional languages professionally for many years, but when I write C++ with consistent use of std::function and lambdas, I get many of the same benefits and a very enjoyable workflow. Is it the same as Haskell or Clojure? No, because they are totally different languages. But within the C++ world, they offer a great productivity benefit that I don't think satisifies the definition of "rip off".
- arcticbull 7y ago
  Not all of them, to be sure, lambdas and in particular their capture list syntax is solid. By no means is that universal though, for instance, move semantics. std::move doesn't move anything, it casts an object as a movable reference (equivalent to static_cast<T&&>). The compiler doesn't preclude you from accessing the old object (or say anything at all) and there's no guarantee it actually did get moved, it's just a hint. That's not real move semantics, it's a shoddy knock-off. You also have to manage a new constructor, new reference type and the opt-in because the default remains not using move semantics. Worse yet, there's varying agreement on what you can or should do with the source of a moved value, the STL containers will all continue to let you use the old value, it's just empty now. That's not standard behavior because there is none, and it's de facto now because it's in the STL. What a nightmare. [1] std::variant is supposed to be associated values on enums, but of course, it doesn't do that either. You don't match, you create a new struct with a bunch of operator() methods on it [or overload a lambda?!] and throw it at std::visit. You can only have one variant of each type. Then it throws exceptions if you start mucking about in ways you shouldn't. There's no context. It's dreadful. [2] [1] http://yacoder.guru/blog/2015/03/14/cpp-curiosities-std-move-that-doesnt-move/ http://yacoder.guru/blog/2015/03/14/cpp-curiosities-std-move... [2] https://www.bfilipek.com/2018/06/variant.html https://www.bfilipek.com/2018/06/variant.html
  - roca 7y ago
    Lambda captures make it pretty easy to create nasty memory safety issues via dangling references. Sure, you could create such issues with the equivalent manually written closure-structs, but lambda captures pave the dangerous path.

rrss 7y ago

Those are all C++11 features, right? So they aren't much of an argument in favor of 14, 17, 20.

blub 7y ago
14, 17 and 20 are full of small and big improvements: coroutines, contracts, modules, concepts, huge improvements for compile-time computation with constexpr, etc.
hellofunk 7y ago
As an example, yes. Other versions offered similar benefits (C++14 in particular was a "bug fix" version for C++11, which I think most would be happy came quickly).
MauranKilom 7y ago
We also got Class Template Argument Deduction, structured bindings, various syntactic sugar (if (auto var = initializer) {}, if constexpr, fold expressions...), std::variant, std::optional, and a whole POSIX-style filesystem library, to name a few. And that's just C++17 alone. It's nothing earth-shattering (that stuff is coming in C++20) but these are all features that improve the language and allow you to write better code. Consider e.g. if constexpr which can eliminate so much SFINAE cruft. Or CTAD to reduce the need for makeXYZ() functions.