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.
Very few new projects are written in C++. It's the old products with 1M+ LOC codebases that most C++ devs live in.
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.
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.
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).
My response is that we use C++ for the language itself, existing engine or not. :)
There are toolchain requirements that push in this direction, but honestly I doubt they make any significant difference in the matter.
Not even fully on C++11 yet!
Vil: How's it going?
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...
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.
There's a huge world outside of those two categories, and there's tons of new C++ projects being written.
.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.
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
I am an old C++ dog since the C++ ARM days, meanwhile busy with other languages.
I am not being snarky, such libraries would help me a great deal.
http://www.roguewave.com/products-services/imsl-numerical-li...
http://quantalea.com/highlights/
I do concede that my remark was a bit flame-bait, but as I replied on a sibling thread, there are mechanisms available that allow for cache friendlier code, while staying inside .NET.
It is going to outperform or be shoulder-to-shoulders to an optimizing C++ compiler?
Most likely not (lets see how .NET Native evolves), but in certain use cases will be already fast enough.
The problem is that many see .NET as Java clone, as I once did as well, Microsoft and miss to explore the mechanisms .NET has available for a bit closer to the metal coding.
Many times 90% there is already a solution costumers will appreciate.
Plus there are plans to bring more of their learnings from System C# (aka M#) and project Midori into .NET.
In theory .NET can do a whole lot of things, but I have been waiting for this hole to be filled for a long time. So far there is nothing even remotely useful as Eigen, Armadillo and their ilk.
Heck, there isn't even a standard sin, cos exp log etc. for floats. Not a place where a number-cruncher will feel at home.