I think that most people consider something like isPrimaryColor = [“Red”, “Blue”, “Yellow”].contains(someColor) to be sufficiently clear that they don’t need extra syntax for this.
‘for backwards compatibility’ seems a sufficient reason for the type erasure of class generic types – it is needed e.g. to allow you to return an untyped List and pass it to some legacy code. The extension of this to generic methods seems like a tricky sub-case. The JLS snippet from 4.8 (which you quote) … Read more
There are formal and actual parameters: void foo(int arg); //arg is a formal parameter int main() { int val = 1; foo(val); //val is an actual parameter } From C++ Standard: 1.3.1 formal parameter (parameter) an object or reference declared as part of a function declaration or definition, or in the catch clause of an … Read more
I believe backwards compatibility plays a big part here. If the user defines any of the “Rule of three” functions (copy ctor, copy assignment op, dtor), it can be assumed the class does some internal resource management. Implicitly defining a move constructor could suddenly make the class invalid when compiled under C++11. Consider this example: … Read more
Here is what Bjarne Stroustrup says about why they introduced using instead of extending typedef: The keyword using is used to get a linear notation “name followed by what it refers to.” We tried with the conventional and convoluted typedef solution, but never managed to get a complete and coherent solution until we settled on … Read more
When n3406 (revision #2 of the proposal) was discussed, some committee members were uncomfortable with optional references. In n3527 (revision #3), the authors decided to make optional references an auxiliary proposal, to increase the chances of getting optional values approved and put into what became C++14. While optional didn’t quite make it into C++14 for … Read more
Well, there is one obvious reason: because it wouldn’t do everything that bit_cast does. Even in the C++20 world where we can allocate memory at compile time, reinterpret_cast is forbidden in constexpr functions. One of the explicit goals of bit_cast is to be able to do these sorts of things at compile-time: Furthermore, it is … Read more
When using reset() the parameter passed to reset need not be a managed object (nor can it be); whereas with = the right hand side must be a managed object. So these two lines give you the same end result: p = std::make_shared<int>(5); // assign to a newly created shared pointer p.reset(new int(5)); // take … Read more
In addition to the differences you cite, and the library differences that Steve Jessop mentions, char* p1; char const* const* p2 = &p1; is legal in C++, but not in C. Historically, this is because C originally allowed: char* p1; char const** p2 = &p1; Shortly before the standard was adopted, someone realized that this … Read more
The definitive ruling is found in Stroustrup’s FAQs. In short, it doesn’t convey any semantic meaning. It will have a cost. Templates are more useful for containers. Why doesn’t C++ have a universal class Object? We don’t need one: generic programming provides statically type safe alternatives in most cases. Other cases are handled using multiple … Read more