5 ms·

I think the lots of changes that is having c++ in every release is killing the language.

fabiensanglard 4y ago
It is really hard to keep up. I often have to Google for definition when I read code. Inevitably someone uses the latest feature.
pjmlp 4y ago
Say those stuck in Java 8, C# 7, Python 2, C89, Ada83, Fortran77,.... It is a pain, but languages are software products as well, so they either get new features to keep going on each new release or they wither and fade away. Eventually some do still die of complexity, replaced by simpler languages, and the cycle reboots, see PL/I, Algol 60/68, ...
- dmitrygr 4y ago
  > or they wither and fade away C and assembly enter the chat
  - 331c8c71 4y ago
    > C and assembly enter the chat Wouldn't you agree that the fraction of software written in C or asm has shrunk tremendously over the last decades?
  - pjmlp 4y ago
    C23 and AVX512 greet them.
    - colejohnson66 4y ago
      I wonder what the ratio of intrinsics to raw assembly is
      - pjmlp 4y ago
        Those using VC++ for ARM or amd64 only have intrisics to chose from, unless they make use of MASM (or similar), as it only supports inline Assembly in x86 mode. Burroughs (now Unisys ClearPath MCP) showed that intrisics are enough, no need for raw Assembly, so in a sense it isn't as crazy idea, and much developer friendly than the inline syntax used by GCC and clang.
  - TeMPOraL 4y ago
    C is continuously gaining features as well (even if it didn't, it's entrenched as the low-level implementation language of all major operating systems, so it's an exception to the rule). Assembly is evolving at least at the speed of your target chip family.
  - duped 4y ago
    Which assembler syntax for which target and is it actually human writable or does it need a proprietary tool chain? ISAs have to exist but the way that code is generated for them is as varied as the landscape of high level languages.
blub 4y ago
I don’t think it’s killing it, but it’s definitely a pain in the ass. Not sure what major malfunction our industry is suffering from, but we seem to have settled on continuously running just to keep in the same place. Apps, operating systems, cars, languages, everything is being updated all the time.
nikanj 4y ago
My feeling is that it's the amount of characters written. Used to be foo* x=new foo(). Now it's std::shared_ptr<foo> x=std::make_shared<foo>() It adds up, every line of code is three times longer than it used to be.
- johannes1234321 4y ago
  > Used to be foo* x=new foo(). Now it's std::shared_ptr<foo> x=std::make_shared<foo>() There's `auto` for that reason. No need to duplicate the info. And: In general code is read more often than written, and the variant with `make_shared` provides extra information on the purpose of the heap allocation. That first line with the raw pointer and new requires following all calls closely to understand the intention. (Aside from also handling the lifecycle, which would this be code which one would have to write elsewhere, your example is missing at least one `delete x` (and likely more handling, considering this being a shared, not unique, ptr)
- TheFlash 4y ago
  While I agree C++ is very verbose, I would argue that modern C++ reduces the amount of code you need to write. The full code above should be : foo* x = new foo(); if (x != nullptr) { ... } delete x; and the equivalent modern C++: auto x = std::make_shared<x>(); ...
- dvzk 4y ago
  I started using std::shared_ptr in every project in 2008. Isn’t it late to denounce the changes now? The state of most C++ codebases is infinitely better today compared to then, partly owed to the added descriptivity.
- deleted 4y ago
  [deleted]

It is really hard to keep up. I often have to Google for definition when I read code. Inevitably someone uses the latest feature.

pjmlp 4y ago

Say those stuck in Java 8, C# 7, Python 2, C89, Ada83, Fortran77,.... It is a pain, but languages are software products as well, so they either get new features to keep going on each new release or they wither and fade away. Eventually some do still die of complexity, replaced by simpler languages, and the cycle reboots, see PL/I, Algol 60/68, ...

dmitrygr 4y ago
> or they wither and fade away C and assembly enter the chat
- 331c8c71 4y ago
  > C and assembly enter the chat Wouldn't you agree that the fraction of software written in C or asm has shrunk tremendously over the last decades?
- pjmlp 4y ago
  C23 and AVX512 greet them.
  - colejohnson66 4y ago
    I wonder what the ratio of intrinsics to raw assembly is
    - pjmlp 4y ago
      Those using VC++ for ARM or amd64 only have intrisics to chose from, unless they make use of MASM (or similar), as it only supports inline Assembly in x86 mode. Burroughs (now Unisys ClearPath MCP) showed that intrisics are enough, no need for raw Assembly, so in a sense it isn't as crazy idea, and much developer friendly than the inline syntax used by GCC and clang.
- TeMPOraL 4y ago
  C is continuously gaining features as well (even if it didn't, it's entrenched as the low-level implementation language of all major operating systems, so it's an exception to the rule). Assembly is evolving at least at the speed of your target chip family.
- duped 4y ago
  Which assembler syntax for which target and is it actually human writable or does it need a proprietary tool chain? ISAs have to exist but the way that code is generated for them is as varied as the landscape of high level languages.

blub 4y ago

I don’t think it’s killing it, but it’s definitely a pain in the ass. Not sure what major malfunction our industry is suffering from, but we seem to have settled on continuously running just to keep in the same place. Apps, operating systems, cars, languages, everything is being updated all the time.

nikanj 4y ago

My feeling is that it's the amount of characters written. Used to be foo* x=new foo(). Now it's std::shared_ptr<foo> x=std::make_shared<foo>() It adds up, every line of code is three times longer than it used to be.

johannes1234321 4y ago
> Used to be foo* x=new foo(). Now it's std::shared_ptr<foo> x=std::make_shared<foo>() There's `auto` for that reason. No need to duplicate the info. And: In general code is read more often than written, and the variant with `make_shared` provides extra information on the purpose of the heap allocation. That first line with the raw pointer and new requires following all calls closely to understand the intention. (Aside from also handling the lifecycle, which would this be code which one would have to write elsewhere, your example is missing at least one `delete x` (and likely more handling, considering this being a shared, not unique, ptr)
TheFlash 4y ago
While I agree C++ is very verbose, I would argue that modern C++ reduces the amount of code you need to write. The full code above should be : foo* x = new foo(); if (x != nullptr) { ... } delete x; and the equivalent modern C++: auto x = std::make_shared<x>(); ...
dvzk 4y ago
I started using std::shared_ptr in every project in 2008. Isn’t it late to denounce the changes now? The state of most C++ codebases is infinitely better today compared to then, partly owed to the added descriptivity.
deleted 4y ago
[deleted]