5 ms·

The problem with a release that breaks backwards compatibility is that no one would use it. Very few new projects are written in C++. It's the old products wit

The problem with a release that breaks backwards compatibility is that no one would use it. Very few new projects are written in C++. It's the old products with 1M+ LOC codebases that most C++ devs live in.

vilya 11y ago
You're right with your first point, but wrong with the second: a lot of new projects are still written in c++. Pretty much every non-indie video game, for example.
- such_a_casual 11y ago
  >Pretty much every non-indie video game, for example. So code that relies on a lot of existing software then (ie the game engine and other in-house libraries that any company would have). You have proved his point instead of countering it.
  - okatsu 11y ago
    Any large enough game will use C/C++ at its core because short of using assembly, it's the only real choice we have. C#, Lisp or whatever else are nice for gameplay scripting, but underneath there is a need for control that most languages will not give you. Same thing for anything with hard real-time requirements.
    - such_a_casual 11y ago
      So? That's completely irrelevant to the argument.
      - okatsu 11y ago
        Your argument is that people only use C++ because of existing libraries and engines My response is that we use C++ for the language itself, existing engine or not. :)
    - anonymoushn 11y ago
      The JVM is fine for running low-latency automated trading systems. I wonder why it's not suitable for applications with timing requirements that are hundreds of times more relaxed? I don't know if the JVM is better or worse for this than some other runtime like Go's or the CLR or whatever, I just wrote about the JVM because it is the one that I have used in this context.
      - humanrebar 11y ago
        > The JVM is fine for running low-latency automated trading systems. 1. There is a lot of expert tuning to get that sort of performance with respect to latency. That tuning would need to be reproduced for every target system. 2. Those trading systems can have ridiculous amounts of RAM to give the JVM GC lots of room to work with. 3. Reading packets from a wire and writing other packets to a wire is a different problem than reading controller inputs and modelling complex 3D worlds. ...that's not to say you can't have AAA Java games. To some degree that already happens with Android games, at least if you're willing to stretch the definition of AAA. (If you define AAA as "uses C++", the nomenclature becomes fairly moot).
        plonh 11y ago
        Minecraft is Java. It has awful performance (but it's simple enough and mixed desktops are powerful enough)
  - overgard 11y ago
    No, code that has to run fast. Most c++ popular libs are callable from other languages. Whatever you feel about it c++ isn't a dead dinosaur, most the things you use were probably written in it.
  - yoklov 11y ago
    Even if there's no existing game engine, it's almost certainly written in C++. There are toolchain requirements that push in this direction, but honestly I doubt they make any significant difference in the matter.
- berkut 11y ago
  And VFX software! :) Not even fully on C++11 yet! Vil: How's it going?
  - vilya 11y ago
    I'm good! You? We should catch up for lunch sometime soon. We'll hopefully be moving to compilers capable of supporting c++11 at work soon - maybe even in 2016 if we're lucky - but it'll probably be an even longer wait before we can start using c++11 features in our code. Still, a guy can dream...
    - berkut 11y ago
      Cool - I'm working on Manuka at Weta atm so the logistics might be a bit difficult :) Yeah, there's a bit of c++11 going on here - but until all the DCC apps move next year, as you say, it's going to be a while.
jlarocco 11y ago
In my experience, when people say there aren't new projects written in C++ it really means, "I'm a web or 'enterprise' developer, and we don't use C++." There's a huge world outside of those two categories, and there's tons of new C++ projects being written.
- vvanders 11y ago
  Bingo, if you want cache aware programs C++ is really the only language widely used(although I'd love to see Rust supplant it).
  - pjmlp 11y ago
    Wrong. .NET provides all the tools to write cache friendly programs. That many devs use it like Java is another matter. If we include high integrity systems there is Ada as well, even though it is a niche.
    - berkut 11y ago
      Really? So you can completely control the layout of where items on the heap are allocated, get hold of pointer addresses, and store things within the least significant bits (for tagged pointers)?
      - pjmlp 11y ago
        For Ada, yes to all your points. For .NET, almost with a few additional tricks. - Value types - Struct layout attributes - Field offsets. - Arrays with value types - Unsafe - Interop with native buffers - Buffer manipulation with custom serialisers Your challenge can be fulfilled with getting a native buffer, with a custom serialiser and a few unsafe tricks. As a matter of fact, you just gave me a mini project idea. Lets see if I am up for the challenge or need to eat my own words. Meanwhile here is an example what C# devs are able to achieve, when they know how to explore the tooling properly. http://www.infoq.com/articles/Big-Memory-Part-2 http://www.infoq.com/articles/Big-Memory-Part-2 I am an old C++ dog since the C++ ARM days, meanwhile busy with other languages.

vilya 11y ago

You're right with your first point, but wrong with the second: a lot of new projects are still written in c++. Pretty much every non-indie video game, for example.

such_a_casual 11y ago
>Pretty much every non-indie video game, for example. So code that relies on a lot of existing software then (ie the game engine and other in-house libraries that any company would have). You have proved his point instead of countering it.
- okatsu 11y ago
  Any large enough game will use C/C++ at its core because short of using assembly, it's the only real choice we have. C#, Lisp or whatever else are nice for gameplay scripting, but underneath there is a need for control that most languages will not give you. Same thing for anything with hard real-time requirements.
  - such_a_casual 11y ago
    So? That's completely irrelevant to the argument.
    - okatsu 11y ago
      Your argument is that people only use C++ because of existing libraries and engines My response is that we use C++ for the language itself, existing engine or not. :)
  - anonymoushn 11y ago
    The JVM is fine for running low-latency automated trading systems. I wonder why it's not suitable for applications with timing requirements that are hundreds of times more relaxed? I don't know if the JVM is better or worse for this than some other runtime like Go's or the CLR or whatever, I just wrote about the JVM because it is the one that I have used in this context.
    - humanrebar 11y ago
      > The JVM is fine for running low-latency automated trading systems. 1. There is a lot of expert tuning to get that sort of performance with respect to latency. That tuning would need to be reproduced for every target system. 2. Those trading systems can have ridiculous amounts of RAM to give the JVM GC lots of room to work with. 3. Reading packets from a wire and writing other packets to a wire is a different problem than reading controller inputs and modelling complex 3D worlds. ...that's not to say you can't have AAA Java games. To some degree that already happens with Android games, at least if you're willing to stretch the definition of AAA. (If you define AAA as "uses C++", the nomenclature becomes fairly moot).
      - plonh 11y ago
        Minecraft is Java. It has awful performance (but it's simple enough and mixed desktops are powerful enough)
- overgard 11y ago
  No, code that has to run fast. Most c++ popular libs are callable from other languages. Whatever you feel about it c++ isn't a dead dinosaur, most the things you use were probably written in it.
- yoklov 11y ago
  Even if there's no existing game engine, it's almost certainly written in C++. There are toolchain requirements that push in this direction, but honestly I doubt they make any significant difference in the matter.
berkut 11y ago
And VFX software! :) Not even fully on C++11 yet! Vil: How's it going?
- vilya 11y ago
  I'm good! You? We should catch up for lunch sometime soon. We'll hopefully be moving to compilers capable of supporting c++11 at work soon - maybe even in 2016 if we're lucky - but it'll probably be an even longer wait before we can start using c++11 features in our code. Still, a guy can dream...
  - berkut 11y ago
    Cool - I'm working on Manuka at Weta atm so the logistics might be a bit difficult :) Yeah, there's a bit of c++11 going on here - but until all the DCC apps move next year, as you say, it's going to be a while.

jlarocco 11y ago

In my experience, when people say there aren't new projects written in C++ it really means, "I'm a web or 'enterprise' developer, and we don't use C++." There's a huge world outside of those two categories, and there's tons of new C++ projects being written.

vvanders 11y ago
Bingo, if you want cache aware programs C++ is really the only language widely used(although I'd love to see Rust supplant it).
- pjmlp 11y ago
  Wrong. .NET provides all the tools to write cache friendly programs. That many devs use it like Java is another matter. If we include high integrity systems there is Ada as well, even though it is a niche.
  - berkut 11y ago
    Really? So you can completely control the layout of where items on the heap are allocated, get hold of pointer addresses, and store things within the least significant bits (for tagged pointers)?
    - pjmlp 11y ago
      For Ada, yes to all your points. For .NET, almost with a few additional tricks. - Value types - Struct layout attributes - Field offsets. - Arrays with value types - Unsafe - Interop with native buffers - Buffer manipulation with custom serialisers Your challenge can be fulfilled with getting a native buffer, with a custom serialiser and a few unsafe tricks. As a matter of fact, you just gave me a mini project idea. Lets see if I am up for the challenge or need to eat my own words. Meanwhile here is an example what C# devs are able to achieve, when they know how to explore the tooling properly. http://www.infoq.com/articles/Big-Memory-Part-2 http://www.infoq.com/articles/Big-Memory-Part-2 I am an old C++ dog since the C++ ARM days, meanwhile busy with other languages.