By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,194 Members | 884 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,194 IT Pros & Developers. It's quick & easy.

"Reconstructing" (Calling the constructor again)

P: n/a
I've written the following demo to help me understand a problem I'm having
in a larger program. The "main" function constructs a Foo object, and then
later "reconstructs" it by calling the constructor again. In my larger
program, I find that the member variables don't get re-initialized when
"reconstructed". I don't have that problem in this demo, but the second
time the constructor is called, its "this" points to a different location.

My questions:

1. Why is the pointer 0xbffffad8 in the third output line, not 0x00300460
like the others?
2. Is there anything wrong with "reconstructing" an object as I have done
in "main"?

Thanks very much to anyone who can help!

Jerry Krinock

class Foo
{
int fooey ;
public:
Foo(int f)
{
fooey = f ;
cout << "In constructor, Addr=" << this << endl ;
}

int GetFooey() { return fooey ; }
} ;
int main ()
{
Foo* aFoo = new Foo(22) ;
cout <<"1. Addr=" <<aFoo <<", fooey=" <<(*aFoo).GetFooey() <<endl ;
// Now, "reconstruct" *aFoo with a different value for fooey
*aFoo = Foo(33) ;
cout <<"2. Addr=" <<aFoo <<", fooey=" <<(*aFoo).GetFooey() <<endl ;
}

****** Output: **********

In constructor, Addr=0x00300460
1. Addr=0x00300460, fooey=22
In constructor, Addr=0xbffffad8
2. Addr=0x00300460, fooey=33

Jul 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Jerry Krinock wrote:
I've written the following demo to help me understand a problem I'm having
in a larger program. The "main" function constructs a Foo object, and then
later "reconstructs" it by calling the constructor again. In my larger
program, I find that the member variables don't get re-initialized when
"reconstructed". I don't have that problem in this demo, but the second
time the constructor is called, its "this" points to a different location.

My questions:

1. Why is the pointer 0xbffffad8 in the third output line, not 0x00300460
like the others?
2. Is there anything wrong with "reconstructing" an object as I have done
in "main"?


1. Because you are construction a new instance of Foo. Obviously it must
have another address that the first Foo object. Furthermore you are not
"reconstructing" aFoo. Your code simply makes a shallow copy of Foo(33),
that is all values of Foo(33)'s members are assigned to their
corresponding members in Foo(22) (to which aFoo points).

2. Not in general, but instead of reconstruction use methods to alter
the object state (i.e., a method to set the value of fooey, perhaps with
some sanity checks on the value to set).

--
Regards,

Karsten
Jul 23 '05 #2

P: n/a

"Jerry Krinock" <je***@ieee.org> wrote in message
news:BE317FA5.9DB0%je***@ieee.org...
I've written the following demo to help me understand a problem I'm having
in a larger program. The "main" function constructs a Foo object, and then later "reconstructs" it by calling the constructor again.
No it doesn't. It assigns the value of another object of
the same type to it. A constructor can only be called once
for a given object, when it is created.
In my larger
program, I find that the member variables don't get re-initialized when
"reconstructed".
C++ doesn't have a concept of 'reinitialize'. An object
can be intialized only once, when it is created.
I don't have that problem in this demo, but the second
time the constructor is called,
The second constructor call is creating a different object.
(See below).
its "this" points to a different location.
Yes, because it's a different object.

My questions:

1. Why is the pointer 0xbffffad8 in the third output line, not 0x00300460
like the others?
Because those are addresses of two separate objects.
2. Is there anything wrong with "reconstructing" an object as I have done
in "main"?
You have not 'reconstructed' anything. You've created two
separate objects, and assigned the value of one to the other.

More below.
Thanks very much to anyone who can help!

Jerry Krinock
#include <iostream>
#include <ostream>
using std::cout;
using std::endl;

class Foo
{
int fooey ;
public:
Foo(int f)
Foo(int f) : fooey(f) /* this initalizes 'fooey' */ {
fooey = f ; /* this is not initialization, it's assignment */
cout << "In constructor, Addr=" << this << endl ;
}

int GetFooey() { return fooey ; }
int GetFooey() const { return fooey; }
} ;
int main ()
{
Foo* aFoo = new Foo(22) ;
/* This dynamically allocates a type 'Foo' object, causing
the constructor 'Foo::Foo(int)' to be called. The
address of this object is stored in the pointer object
'aFoo'. */
cout <<"1. Addr=" <<aFoo <<", fooey=" <<(*aFoo).GetFooey() <<endl ;
This outputs the address of the dynamicaly allocated object,
and the value of its data member 'fooey'. Note that there
is a 'shorthand' syntax for accessing members through a
pointer: aFoo->GetFooey() (but the way you wrote it is
valid as well).
// Now, "reconstruct" *aFoo with a different value for fooey
*aFoo = Foo(33) ;
You're *assigning* '*aFoo' a new value. Initialization
and assignment are not the same thing.

The above line creates a temporary type 'Foo' object, causing
the constructor 'Foo::Foo(int)' to be called. (This
initializes the temporary object, it does not affect
the one previously created.) Then the value of this
temporary object is *assigned* to the previously
created object (the one pointed to by 'aFoo'). Then
the temporary object is destroyed.
cout <<"2. Addr=" <<aFoo <<", fooey=" <<(*aFoo).GetFooey() <<endl ;
This output statement is the same as the one above, So again,
it outputs the address of the dynamically allocated object,
and the value of its data member 'fooey'. The object's address
does not change, it still exists at the location where it
was allocated. The only difference in the output should
be the value of 'fooey', 33 (since you assigned your object
a new value above).
}

****** Output: **********

In constructor, Addr=0x00300460
1. Addr=0x00300460, fooey=22
0x00300460 is the address of the dynamically allocated
object.
In constructor, Addr=0xbffffad8
0xbffffad8 is the address of the temporary object
(the one created with a constructor argument of 33)
2. Addr=0x00300460, fooey=33


0x00300460 is the address of the (same) dynamically allocated
object. So of course it is the same.
Which C++ book(s) are you reading? Perhaps you need
better ones.

-Mike
Jul 23 '05 #3

P: n/a
in article cu*************@news.t-online.com, Karsten Baumgarten at
in*****@spam.net wrote on 05/02/10 21:38:
instead of reconstruction use methods to alter the object state
Yes, I understand that the normal practice is to use a setter.

in article sB*****************@newsread3.news.pas.earthlink.n et, Mike Wahler
at mk******@mkwahler.net wrote on 05/02/10 21:42:
Which C++ book(s) are you reading? Perhaps you need better ones.


Unfortunately, a few years ago I bought a book which I later learned is
called "bullschildt" at a local store. Tell me the title of a better one
and I'll subscribe to it on O'Reilly Safari.

Thanks for the help. I understand the problems and can take it from here.

Jerry

Jul 23 '05 #4

P: n/a
"Jerry Krinock" <je***@ieee.org> wrote in message
news:BE31F606.A14D%je***@ieee.org...
in article sB*****************@newsread3.news.pas.earthlink.n et, Mike Wahler at mk******@mkwahler.net wrote on 05/02/10 21:42:
Which C++ book(s) are you reading? Perhaps you need better ones.


Unfortunately, a few years ago I bought a book which I later learned is
called "bullschildt" at a local store. Tell me the title of a better one
and I'll subscribe to it on O'Reilly Safari.


Which book is 'best' will vary among individuals and
their circumstances (e.g. complete beginner; have
experience with other language; etc.) Here are
some good peer reviews:

http://www.accu.org/bookreviews/public/index.htm

Also imo it's good to have more than a single
book. I suggest you choose two or more.

-Mike
Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.