Sign in to follow this  
Followers 0
Aspirer

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

20 posts in this topic

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
0

Share this post


Link to post
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.

1

Share this post


Link to post
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>"

0

Share this post


Link to post
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.

0

Share this post


Link to post
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;
4

Share this post


Link to post
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
1

Share this post


Link to post
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);
}
0

Share this post


Link to post
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?
2

Share this post


Link to post
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
0

Share this post


Link to post
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++.
0

Share this post


Link to post
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?
1

Share this post


Link to post
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();
1

Share this post


Link to post
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++ smile.png

Edited by NightCreature83
1

Share this post


Link to post
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.

1

Share this post


Link to post
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++ smile.png

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
0

Share this post


Link to post
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.

2

Share this post


Link to post
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
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0