I've designed a checklist that would instantly decide if language will be a C++ successor or not. Every line is requirement for a "language that will dethrone C++", 9/10 wouldn't cut it. 1.No dependencies on GC/refcounting. 2.Object abstraction system(as powerful as in C++). 3.Same or better execution speed(compared to similar C++ code). 4.Type-inference,type-inferred lambda expression. 5.Strict type system with escapes(fast casts, conversion). 6.Clear and terse imperative syntax. 7.Large standard library with functional/OOP/procedural programming support. Must include threading and graphics. 8.Support for low-level code(such as inline assembler and OS/hardware interfaces). 9.Text-generator(aka #define a(b)) and code-generator(template/mixin/lispmacro) macros. 10.Operator/function overloading without restrictions.
>>35 Integer conversions most certainly can be checked, and this checking can be performed statically with zero runtime overhead in many cases. It is only necessary to provide escape mechanisms for raw word / bit level access in a very few cases, even in high performance or embedded code.
That C or C++ aren't required to do so by default is a weakness of those particular languages. Any C or C++ codebase of sufficient size is forced to implement its own abstractions for common integer conversion operations precisely because it is so easy to get them wrong.
auto provides only compile-time type inference, since the C/C++ type system only exists at compile time. The only type system available at runtime is that of machine code, which doesn't even have a notion of data type, as all machine code data is just strings of bits. Functions and instructions are typed insofar as different bit manipulations are needed to perform equivalent operations on different data types. This is the opposite of how C operators work: the '+' operator for example can mean either integer addition or floating point addition, depending on the types of the operands. In machine code on the other hand, integer addition and floating point addition are two different instructions, and the operands are interpreted differently depending on which instruction is used. Runtime type inference would require adding overhead to every variable to store its type, and checking types before every operation. That certainly could be done, but C focuses on eliminating any and all unnecessary overhead in order to provide maximum performance.
Runtime type inference would require adding overhead to every variable to store its type, and checking types before every operation
Wrong
Name:
Anonymous2016-11-11 17:46
>>51 If the type can change(fully dynamic) the system must store the type. Valid dynamic variable in js vat x=1.0 x="String" x=[1,["What","is","this","i'm","not","good", "with", "computers"]]
Name:
Anonymous2016-11-11 17:55
Rust: [x]1.No dependencies on GC/refcounting. [traits]2.Object abstraction system(as powerful as in C++). [almost]3.Same or better execution speed(compared to similar C++ code). [x]4.Type-inference,type-inferred lambda expression. [unsafe]5.Strict type system with escapes(fast casts, conversion). [x]6.Clear and terse imperative syntax. [almost]7.Large standard library with functional/OOP/procedural programming support. Must include threading and graphics. [x]8.Support for low-level code(such as inline assembler and OS/hardware interfaces). [macro_rules]9.Text-generator(aka #define a(b)) and code-generator(template/mixin/lispmacro) macros. [traits]10.Operator/function overloading without restrictions.