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

Recommended Posts

I tried google, but can't find a good way to ask this question... lol

For instance:

myClass anObject = new myClass;

Why do you declare a myClass, then specify "new myClass"

In my mind, it's the same as:

int myNumber = new int.

"No shit, it's a new int! If I wanted a f***ing float, it woulda said 'FLOAT myNumber'!!!"

If I wanted a "new yourClass", I would've typed "yourClass anObject"

And for that matter, what would be a good search phrase to find info on this, cause "why double declare class" and "why declare a class instance as new" and all the related phrases that come to mind don't turn up a damn thing....

Thanks, cause this is really bugging the shit outta me.

Edited by Aspirer

Share on other sites

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.

Share on other sites

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>"

Share on other sites

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

Share on other sites

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;

Share on other sites

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; }

Edited by NightCreature83

Share on other sites

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);
}


Share on other sites
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<T>
List<T> 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<T>", but how can the compiler know you really want a "new List<T>" and not an existing one, or some other object that inherits from List<T>? What if you really want a new List<T> but you want it to be created by a function that initializes it with some values?

Share on other sites

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.)

Edited by haansn08

Share on other sites
&nbsp;

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

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++.

Share on other sites

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?

Share on other sites

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();

Share on other sites

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++

Edited by NightCreature83

Share on other sites

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.

Share on other sites

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? Edited by Servant of the Lord

Share on other sites

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

Share on other sites

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.

Share on other sites

I'll ilustrate with C#:

// Here you create a create a variable, but is empty or null.
GameObject myGameObj;

// Here you assign a instance to that variable, so that is no longer null.
myGameObj = new GameObject();

/**
The code you posted is just and shortcut for doing what I did.
The advantage? You can create multiple instances using a for and assign them to a list.
Every time the "new" keyword is used, it means that a new object of that type is being created.
*/

Edited by brunopava

Create an account

Register a new account

• Forum Statistics

• Total Topics
628293
• Total Posts
2981868

• 11
• 10
• 10
• 11
• 17