[kjeetgill]

> Languages do not need a 1 to 1 relationship between the storage medium of a value and the interface it exposes to a programmer. ... I suspect the reason Java did it was to not surprise C++ programmers. Solely dictated by marketing, not by technical reasons.

The situation is almost the opposite of what you described it. If anything one of the major design points was to solve the surprises inherent to C/C++.

Take integers for example. In java they're defined to be 2s compliment; the processor architecture doesn't matter. C/C++ left the spec open to let the language be 1 to 1 with the medium, Java did not.

You can see the proposals to close this headache: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p090... http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm

This is similar to all the issues with how threads interact with memory. Java lend the way in making the memory model a part of the language specification rather than allow it to be implementation (and architecture) defined.

http://www.theregister.co.uk/2011/06/11/herb_sutter_next_c_p...

[MaxBarraclough]

> If anything one of the major design points was to solve the surprises inherent to C/C++.

Sure, but you're speaking past each other.

* Java was designed to be more predictable and have fewer dark corners than C++ (no undefined behaviour, precisely defined primitives and generally far less platform-specific behaviour, etc)

* Java was designed to feel familiar to C++ developers in order to aid adoption (specifically its syntax)

These aren't in contradiction.

[skissane]

> Take integers for example. In java they're defined to be 2s compliment; the processor architecture doesn't matter. C/C++ left the spec open to let the language be 1 to 1 with the medium, Java did not.

There is a historical reason for this. In the early 1970s, when C was first designed, non-twos complement machines (such as CDC and UNIVAC machines) were still an important part of the industry and so it made sense for C to be designed to allow supporting those machines. By the 1990s, when Java was designed, non-twos complement machines were much less relevant, so it made sense to exclude support for them from the design of Java. Now finally, in the late 2010s, when the relevance of those machines has shrunk even further (although ones-complement Unisys mainframes still exist even today), it makes sense to remove that support from the C standard, even though it made a lot of sense when C was first designed.