So today I learned that when you instantiate an array of a custom class (in C# and Java)
Code:
customClass[] customClasses = new CustomClass[4];
|
you actually create an array of null references to this class. The class doesn't automatically initialize. And personally, I think THAT IS SO DAMN DUMB...
WHO THE FUCK NEEDS AN ARRAY OF NULL REFERENCES
WHY DON'T THEY JUST AUTO INSTANTIATE?
When I found out Java did this I almost slapped a bitch, but then I tested it in C# an the exact same thing happens...
I guess I've always taken the ArrayList for granted since it actually automatically instantiates your classes for you. Unfortunately, the ArrayList is not allowed on this assignment.
Your statement merely dynamically allocates an array of size 4 as you said.
There are many cases where you may want an array with no actual instantiated objects, at the time of declaration. Simple example could be if you want to supply different constructor arguments for each object.
Perhaps the language could have a means of instantiating multiple objects automatically (if it doesn't already)... Although the following isn't too bad
Code:
customClasses.Select(x => new CustomClass);
|
(unsure about syntax since I don't really do C#)
Slushba132 Wrote: [ -> ]So today I learned that when you instantiate an array of a custom class (in C# and Java)
Code:
customClass[] customClasses = new CustomClass[4];
|
you actually create an array of null references to this class. The class doesn't automatically initialize. And personally, I think THAT IS SO DAMN DUMB...
WHO THE FUCK NEEDS AN ARRAY OF NULL REFERENCES
WHY DON'T THEY JUST AUTO INSTANTIATE?
Stop bitching, it's not like it's hard to do it yourself.
Also, what if your class can't initiate without arguments? Wouldn't work man.
Most Classes have a default constructor...
On top of that you could implement ArrayList like support of
Code:
customClass[] customClasses = new CustomClass[4](CREATION ARGUMENTS);
|
Slushba132 Wrote: [ -> ]On top of that you could implement ArrayList like support of
Code:
customClass[] customClasses = new CustomClass[4](CREATION ARGUMENTS);
|
The whole point of constructors that take arguments is that the arguments vary. So passing the same arguments to all the constructors like that is pointless.
because when you create an array you may not necessarily need to allocate memory for every instance that will be in that array straight away. If you don't need what's in that array straight away, why are you instantiating it? They'll just sit there in memory being useless until you need them, taking up space.
Assassinator Wrote: [ -> ]The whole point of constructors that take arguments is that the arguments vary. So passing the same arguments to all the constructors like that is pointless.
Not necessarily, and constructors don't necessarily have to need arguments. Really depends on the situation.
ZiNgA BuRgA Wrote: [ -> ]Assassinator Wrote: [ -> ]The whole point of constructors that take arguments is that the arguments vary. So passing the same arguments to all the constructors like that is pointless.
Not necessarily, and constructors don't necessarily have to need arguments. Really depends on the situation.
Lol, I know they don't necessarily need arguments, but there are cases that they do. What I'm saying is that if you hit such a case, then....
customClass[] customClasses = new CustomClass[4];
... is going to fail, and...
customClass[] customClasses = new CustomClass[4](CREATION ARGUMENTS);
... is pointless because passing the same arguments every time defeats the purpose.
Assassinator Wrote: [ -> ]Lol, I know they don't necessarily need arguments, but there are cases that they do. What I'm saying is that if you hit such a case, then....
customClass[] customClasses = new CustomClass[4];
... is going to fail
Hardly an issue for the language - compilers can easily check for this.
Assassinator Wrote: [ -> ], and...
customClass[] customClasses = new CustomClass[4](CREATION ARGUMENTS);
... is pointless because passing the same arguments every time defeats the purpose.
In which case you wouldn't use that construct.
This doesn't prevent one from instantiating in a traditional fashion.
Not auto-instantiating is a sensible default to have, but having an additional operator, for instance, for doing this automatically is harmless IMO.
ZiNgA BuRgA Wrote: [ -> ]Hardly an issue for the language - compilers can easily check for this.
But but but it's inconsistent!!!
I guess I just don't like inconsistent things.