Why "double declare" classes? (Lack of better terminology)

Well, most languages have evolved so that you don't actually need to do that. Ex C# has had the var keyword since 3.0 and C++11 introduced the use of the auto keyword to implicitly define a type.

Well, what brought it up was reading up on using lists in Unity, and their example was

List myList = new List();

To me, it should be a no brainer, "Hey, I said myList was "List" so it should probably be a "new List"

In implicitly typed C# syntax, that would be expressed as "var myList = new List();", and would be exactly equivalent in the subsequent code.

In C++ you'd write:

int anInt;
myClass anObject;

or for a pointer to an object (can by null) in C++98:

int* anIntPointer = new int;
myClass* aClassPointer = new myClass;

or in C++11 you can make the above not repeat itself:

auto anIntPointer = new int;
auto aClassPointer = new myClass;

Say you have a Base class and a derived class. Unless I'm mistaken, the following code is valid

Base base=new Derived;

Say you have a Base class and a derived class. Unless I'm mistaken, the following code is valid

Base base=new Derived;

Precisely. This is the main reason that prevents type declarations from being eradicated entirely in statically typed languages. Even "var" and "auto" are picking a specific static type. They just allow you to use them to reduce typing.

If you use C#, use 'var' to reduce redundant typing, ESPECIALLY for long types like Dictionary. But don't forget that being able to designate a variable's type manually when you need to is also very important.

In C++ you'd write:

int anInt;
myClass anObject;

or for a pointer to an object (can by null) in C++98:

int* anIntPointer = new int;
myClass* aClassPointer = new myClass;

or in C++11 you can make the above not repeat itself:

auto anIntPointer = new int;
auto aClassPointer = new myClass;

And in C++14 you can write this as long as the range supports a push_back method of value type

auto add_value_to_range(auto range, auto value) { range.push_back(value); return true; }

Say you have a Base class and a derived class. Unless I'm mistaken, the following code is valid

Base base=new Derived;

An example of this is that you might want to have a for loop that goes through all of your Shapes and changes their colour to green. The Shape class has a colour, and derrived classes like Square and Circle have what ever extra properties they need. You would have an array of type shape that contains Cirles and Squares.

Shape [] arr = new Shape [2];
arr[0] = new Circle();
arr[1] = new Square();

for(int i = 0; i < arr.length; ++i) {
    arr[i].setColour(GREEN);
}

Speaking of C# that's because variable declaration and object instantiation are two different things

Here we are just declaring a variable of type List
List myList;

It has no value, and is not initialized, it can't be used unless it's used in an out parameter

What would happen if it automatically create a new instance of the object just by declaring it? If it was a value type, like an int or float there would be no problem at all, but it would never work for a reference type.

First of all a reference type may not have a parameterless constructor, or it could be an abstract class or even an Interface, there would be no way to initialize then this way, or it could have no public constructors at all, what if it uses some kind of factory class to initialize the objects?

And of course, what if you just want the variable to receive an instance from somewhere else? You do not always want a new object, sometimes you will receive it as a parameter or from calling some other function

So you say it's a "List", but how can the compiler know you really want a "new List" and not an existing one, or some other object that inherits from List? What if you really want a new List but you want it to be created by a function that initializes it with some values?

Say you have a Base class and a derived class. Unless I'm mistaken, the following code is valid

Base base=new Derived;

Yes - and it's not just valid it's also good practice:

http://www.fatagnus.com/program-to-an-interface-not-an-implementation/

And you can type var (C#) or auto (C++) or whatever if you want the compliler to recognize the type automatically.

(But it disguises the type e.g. if the return value of a function is not clear.)

 

Well, what brought it up was reading up on using lists in Unity, and their example was
 
 List<T> myList = new List<T>();
 
To me, it should be a no brainer, "Hey, I said myList was "List<T>" so it should probably be a "new List<T>"

It's the other way around: expressions (here new List(), the constructor) have a definite type (here List), and it can be inferred that the same type as the expression is a valid default choice for the type of a variable that is meant to hold the value of the expression. This is what allows syntax like "var" in C# and "auto" in C++.

And in C++14 you can write this as long as the range supports a push_back method of value type

auto add_value_to_range(auto range, auto value) { range.push_back(value); return true; }

In templates only, or regular functions? That seems like it'd have to be a compile-time template.
The return value makes sense (and is already supported in C++11, but is being refined in C++14), but as parameters, if the function is overloaded, that seems like it'd introduce ambiguity. Are auto parameters the last to be resolved only if the other overloads don't match?

C++ examples of why the syntax needs to support having them on both sides:

//As dawgdog mentioned
MyBase *base = new MyDerived();

MyType type; //Left-hand side needed, because no right hand is specified.

//Right-hand needed, because no left hand is specified.
myFunction(MyType());

//Unnecessarily redundant, but validly. Type on both sides.
MyType type = MyType();

//Left-hand needed, but since it's already present you can just use auto (as others already mentioned).
auto type = MyType();

And in C++14 you can write this as long as the range supports a push_back method of value type

auto add_value_to_range(auto range, auto value) { range.push_back(value); return true; }

In templates only, or regular functions? That seems like it'd have to be a compile-time template.
The return value makes sense (and is already supported in C++11, but is being refined in C++14), but as parameters, if the function is overloaded, that seems like it'd introduce ambiguity. Are auto parameters the last to be resolved only if the other overloads don't match?

It's regular functions and even lambda captures, thats the whole reason for it. This explains better: http://herbsutter.com/2013/06/13/gotw-93-solution-auto-variables-part-2/

Example code from article in base form:

function<void(vector<int>)> get_size =
     [](const vector<int>& x) { return x.size(); };

Rewritten to use auto:

auto get_size = [](const auto& x) { return x.size(); };

this will work for any object passed to the lambda that has a size() function defined for it. It pretty much allows you to write duck typed code in C++

I'm assuming you're referring to C# here since all the examples you've mentioned look C#ish and not C++ish, and you mention Unity, which has no C++ implementation. though you may be referring to Java as well.

In C# all variables full under two categories. The narrow category of Value types, which are all the built-in primitives (int, float, char, etc), and the much broader category of Reference types which is any class or template type.

If you're most familiar with C++ it's easiest to think of Value types as variables on the stack and Reference types as variables on the Heap. And as any variable on the Heap in C++ must be Instantiated with new, so must any Reference variable in C# be instantiated. Unlike C++, Reference types can only be instantiated on the heap. There's no way to automatically create a local instance of a Reference type.

In templates only, or regular functions? That seems like it'd have to be a compile-time template.
The return value makes sense (and is already supported in C++11, but is being refined in C++14), but as parameters, if the function is overloaded, that seems like it'd introduce ambiguity. Are auto parameters the last to be resolved only if the other overloads don't match?

It's regular functions and even lambda captures, thats the whole reason for it. This explains better: http://herbsutter.com/2013/06/13/gotw-93-solution-auto-variables-part-2/

Example code from article in base form:

function<void(vector<int>)> get_size =
     [](const vector<int>& x) { return x.size(); };

Rewritten to use auto:

auto get_size = [](const auto& x) { return x.size(); };

this will work for any object passed to the lambda that has a size() function defined for it. It pretty much allows you to write duck typed code in C++

I can't see where the linked article talks about auto parameters in normal overloaded functions, am I missing something?
Return values, yes. C++11 has that in some limited cases already.
Template arguments, yes, that makes sense. Lambda arguments make sense (lambda auto parameters could be compiled as templated arguments), but normal C-style C++ functions can't change their arguments... Are auto-parameterized functions secretly template functions in disguise, generating additional compile-time overloads?

Well, what brought it up was reading up on using lists in Unity, and their example was

List myList = new List();

To me, it should be a no brainer, "Hey, I said myList was "List" so it should probably be a "new List"

If you are coming from a C or C++ background, know that C# is a different language.

If it helps you transition, you can think that in languages like Java and C# all variables are secretly pointers. They don't look like pointers, but myList is really a pointer to List. If you type SomeObject obj; the equivalent C++ would be SomeObject *obj;, a pointer rather than an instance.

Again if it helps to make the transition, think of it as a conspiracy. The writers of these new languages don't want you to know about pointers. They want you to forget pointers even existed. So variables are really pointers to objects rather than objects; instead of the -> operator on these secret pointers they use the . operator to try to confuse you. That's also why the languages use dot for scope resolution rather than ::, to make you forget about your true roots, trying to tempt you with an easier way rather than the true path of hard work and struggles.

Once you are indoctrinated to the secret cult of modern programming languages you might discover that it frees your mind to work on other more important issues. But for now, they are just trying to cover up the truth. Pointers are hidden to just use a dot. Scope is hidden to just use a dot. Who knows what critical truths of programming they will hide next behind the dot.

Be careful about drinking from the punch bowl, because until you do you can rest assured that there are serious performance penalties for hiding pointers, that hiding pointers this way will upset every performance metric, and that every time a pointer is hidden this way a puppy gets drowned. This is why it is important to stick with C and C++ that have their roots in 1950's model, rather than those hippie/punk/goth kids using languages with a 1990's model. If you are forced to use their languages, always remember that you really are dealing with pointers when they want you to think you have objects.

Until your mind makes the transition, know that in these sneaky modern languages everything is secretly a pointer, to appease the secret pointer objects must be made with new, and they want to deny the existence of delete. They are a cult of satan using a powerful drug, be careful when working with the code lest it addict you. :)

Frob, this was the single most funny thing I read here in weeks :D ROFL

That was kind of funny, but it's actually more informative than funny. I do wish people that learn Java as a first language would know that much, so they have a mental picture of what's likely to happen under the hood, and therefore make reasonable estimates of the performance some way of implementing something will have.

In particular, I seem to encounter a lot of people trying to write an alpha-beta searcher (chess, checkers, connect-4...) in Java, and they don't understand why their programs are two orders of magnitude slower than commercial programs. The answer is typically that they are doing a whole bunch of dynamic memory allocations per node visited, which is unacceptably slow. And yes, for some types of programs (the vast majority of the programs I care about) performance still matters, certainly in the two-orders-of-magnitude scale.

I was going to ask what mechanisms in Java and C# I should recommend to people with this problem, but I think that would be too much of a thread hijack. I'll ask whenever I find someone with that problem again.