2 (or 3?) ways of declaring objects... what's the difference?

Started by
7 comments, last by DevFred 15 years, 5 months ago
class Season { whatever; }; Season spring; Season fall; or Season spring = new spring; Season fall = new fall; I don't get the difference in these. Or was it... Season* spring = new spring; Season* fall = new fall; The first version is what I've been using the most. The second version, well, I don't get the point to using new when the other one works fine. What's it doing? And as for the third version, what's the point of using a pointer like that? The only thing I've noticed is I'd use -> like... spring->setWeather(); instead of spring.setWeather(); So much to learn still... thanks anyone!
Advertisement
Quote:Original post by Jaqen
class Season {
whatever;
};

Season spring;
Season fall;

or

Season spring = new spring;
Season fall = new fall;

I don't get the difference in these.



The first declares the variables. The second declares the variables and initiates two instances of the class.
What do you mean when you say initiates? Not that the constructor is called, right? Because the constructor is called when I just do Season fall; so I'm still a little confused.
You got the syntax wrong, it's not this:
Season spring = new spring;Season fall = new fall;
And it's not this:
Season* spring = new spring;Season* fall = new fall;
It's this:
Season* spring = new Season;Season* fall = new Season;

This creates a new 'Season' object that lasts forever*, until you destroy it with 'delete'.

This means, 'Season' objects you 'new' in one function, can be used in another function, if you have access to a pointer to them.

If you don't understand pointers, you need learn them before learning 'new' and 'delete'. But if you do understand pointers, here's one difference between using 'new' and not using 'new':
Season *usingNew(){    //Declaring season with 'new'. It is never deleted until you manually do it with 'delete'.    Season *mySeason = new Season;         //Returns the pointer to mySeason.     return mySeason; }Season *notUsingNew(){    //Declaring season without 'new'. It is automaticly deleted when you reach the end of this function.    Season *mySeason = Season;         //Returns the pointer to mySeason...     //But it's deleted at the end of this function, so the function is returning a invalid pointer!    return mySeason; }


*By 'forever' I mean as long as your program lasts. If you fail to clean up memory that you manually create, the operating system will clean it up for you, but it's a bad programming practice.
Season s1;
// creates a variable s1, on the stack, using the default constructor

Season s2(0);
// creates a variable s2, on the stack, using a constructor that accepts an integer (assuming there is one).

Season s3 = 0;
// creates a variable s3, on the stack, using a constructor that accepts an integers. (same as s2).

Season s4;
s4 = 0;
// creates a variable s4, on the stack, using the default constructor, then calls the assignment operator that accepts an integer (assuming there is one).

Season *s5;
// creates a variable s5, on the stack, that is a pointer to a Season. No actual season object has been created.

s5 = &s4
// assigns the address of s4 into the pointer s5, so s5 now points to s4

s4.whatever;
s5->whatever;
// these now do the same thing, access "whatever" in the object created as "s4", which is also currently pointed to by the pointer s5

Season *s6 = new Season();
// creates a variable s6, on the stack, that is a pointer to a Season, also creates a Season object on the head, and assigns that Season object's address into the pointer s6. So at this time there is a season object somewhere in memory, and a pointer variable "s6" on the local stack.

s6->whatever;
// same as the above version (with s5) except that in the case of s6, the affected object is not some other named object in the system ... so most people think of this as being s6's object. Basically, if an object is instantiated at the same time as the variable pointing to it, most people think of them as if they are one object (they aren't, but unless you reassign the s6 pointer they might as well be). Be carefull though because if you then do this:

s6 = new Season();
// this creates another Season object and reassigned pointer s6 to point to it, instead of the previous object.

// now the original Season pointed to by s6 is lost in space. The object is still out there in memory somewhere, holding all its values, but you the programmer have no way to access it ... since you have no pointer or reference to it anymore.
The point of using pointers is as said above, to have the lifetime of the object be different than the lifetime of the local variable. But also another purpose ... to be able to switch which object is affected. like this:

Season seasons[4]; // create an array of 4 seasonsSeason *currentSeason = 0; // create a season pointer, set to nullunsigned choice;std::cout << "select a season (0-3): ";std::cin >> choice;if(choice < 4) // make sure the choices is in range  currentSeason = &seasons[choice]; // select the corresponding seasonelse  currentSeason = 0;if(currentSeason == 0)  std::cout << "You selected an invalid season." << std::endl;else  std::cout << "You selected " << currentSeason->name << "." << std::endl;

Thanks all, a lot of helpful information here. Surprised at how much some of you elaborated but it helps a lot.

I'm still trying to get a good handle on the whole pointer thing but it's not going too well. Hopefully if I just keep working with them (or at least keep attempting to), they'll click eventually. Most everything else has come relatively easy to me but pointers, bleh.
Pointers are what kills most programmers at first ... it slows down everyone, and those who aren't going to become programmers never do get it ... but it usually isn't really hard to understand after your brain has a few different models for them and a little time to absorb it (most people "get" pointers a few months or even a year or so after they first learn to "use" them).

The semester me and my friends learned them in school, we barely passed the labs ... a year later it was all absurdly easy to us.

The year after I learned them I liked to draw them. My view of memory back then was: each byte is a little rectangular box (like in a spreadsheet), each 32 bit int is a longer box, that can be subdivided when needed. a "pointer" is a long box (same as int) but instead of being subdivided I just draw a little dot in the middle of the box, and then draw an arrow to whatever it points to. a "null" point has a slanted line in it (the line drawn through a zero, the divide symbol) ... so I can tell when it is null - which is physically the same as 0, but logically I visualized it differently).

[ ] <= byte
[ ] <= int
[ | | | ] <= int (with byte boxes, when dealing with unions or other strange stuff)
[ / ] <= null pointer

[ 3560 ] <= integer value
[0x8054CA8B ] <= pointer value (I ALWAYS use hexidecimal when writing a pointer value - ie, a memory address).
Quote:Original post by Xai
Pointers are what kills most programmers at first

And in my experience, it is because beginners have an incomplete model of what a variable is (they don't know that variables have addresses, and thus don't realize that these addresses can be treated as values that can be manipulated and stored in other variables).

This topic is closed to new replies.

Advertisement