Inheritance basic issue form newbie

[Marco]

Hello Group,
This may be a basic question, anyway I'd really appreciate any help on
this:

I have a base class (base) with some virtual functions (for example
void Show()) and some derived classes (derived1, derived2) that
redefine these functions.


// I define an array of the base class

base arr[10];

// then i create some objects from the derived class

derived1 obj1;
derived2 obj2;

// then I assign these objects to the array elements:

arr[1] = obj1;
arr[2] = obj2;

// The problem is that if now I call arr[1].Show() I enter the
base::Show()
// function and not the derived1::Show() function.
// Am I missing something or is there a different way to implement
this?
// Thank you in advance,

// Marco

 

[James Gregory]

Hello Group,
This may be a basic question, anyway I'd really appreciate any help on
this:

I have a base class (base) with some virtual functions (for example
void Show()) and some derived classes (derived1, derived2) that
redefine these functions.


// I define an array of the base class

base arr[10];

// then i create some objects from the derived class

derived1 obj1;
derived2 obj2;

// then I assign these objects to the array elements:

arr[1] = obj1;
arr[2] = obj2;

// The problem is that if now I call arr[1].Show() I enter the
base::Show()
// function and not the derived1::Show() function.
// Am I missing something or is there a different way to implement
this?
// Thank you in advance,

Virtual functions only work via pointers.

So to get the above example to work you would have to go:

base* arr[10];

derived1 obj1;
derived2 obj2;

arr[1] = &obj1;
arr[2] = &obj2;

arr[1]->Show();

Also, I don't think you need to comment out everything in your post that
isn't valid C++!

James

 

[John Harrison]

Virtual functions only work via pointers.

Nitpick - or references.

john

 

[Marco]

Thank you both for the clarification!

Marco

Nitpick - or references.

john

 

[Leor Zolman]

Also, I don't think you need to comment out everything in your post that
isn't valid C++!

For folks like me who like to copy-and-paste code as much as possible to
avoid transcription errors and save time, putting those comment symbols in
is, generally speaking, actually quite helpful. Granted, it wouldn't have
made any difference in this particular case, but I like seeing code
presented in as compile-able a form as possible (and I appreciate the
extent to which that is already happening.)
-leor

 

[Marco]

One more question.
I'm working on a multi-file object, so once I create a derived1 obj1 object
I need to store them in a "global container" to make them available even
after the call to the destructor function (that destroys the obj1 object).
It would be very useful for me to store these objects from different
subclasses (derived1, derived2 and so on) in an array but if I try to use
these code lines:

//global variable:
base arr[10];
base *p_arr[10];

//creation function:
derived1 obj1;
arr[1] = obj1;
p_arr[1] = &arr[1];

// now p_arr[1] points to a base object and not to a derived1 object.

so is there a way to store objects from different subclasses in a unique
"container", possibly with a random access (like arrays or vectors), without
loosing their original class properties?

Thank you again for the help!
Marco

P.S. If these questions are too "basics" please let me know if there is a
more suitable group to post... I wouldn't like to be "annoying"! ;-)

 

[James Gregory]

One more question.
I'm working on a multi-file object, so once I create a derived1 obj1 object
I need to store them in a "global container" to make them available even
after the call to the destructor function (that destroys the obj1 object).
It would be very useful for me to store these objects from different
subclasses (derived1, derived2 and so on) in an array but if I try to use
these code lines:

//global variable:
base arr[10];
base *p_arr[10];

//creation function:
derived1 obj1;
arr[1] = obj1;
p_arr[1] = &arr[1];

// now p_arr[1] points to a base object and not to a derived1 object.

so is there a way to store objects from different subclasses in a unique
"container", possibly with a random access (like arrays or vectors), without
loosing their original class properties?

Thank you again for the help!

Look for a tutorial in a good book, or if you are poor then with google,
on "handles".

P.S. If these questions are too "basics" please let me know if there is a
more suitable group to post... I wouldn't like to be "annoying"! ;-)

I've no idea, but I haven't been told to go away yet.

James

 

[Leor Zolman]

One more question.
I'm working on a multi-file object,

There's no such thing. I assume you meant a multi-file /project/, with base
class in one module and derived in another? The file organization really
does not affect the mechanisms you're grappling with here. Whether
everything were in one big file or spread out across many, you'd still have
exactly the same issues.

so once I create a derived1 obj1 object
I need to store them in a "global container" to make them available even
after the call to the destructor function (that destroys the obj1 object).

Whoa. Not sure what you're trying to say there, but no object remains
"available" after its destructor has run; that's why it is called a
"destructor". From your code below it looks like you're defining an object
(obj1), making a "sliced copy" (a temporary base object created by "slicing
off" the derived part of obj1 and keeping what remains), putting a copy of
that base slice into your array, and then finally putting a pointer to that
base slice into your array of pointers. After the "creation function" code
runs, the only object that might be destroyed before your program completes
execution is going to be the original obj1 object (if execution reaches the
end of the block where obj1 is defined, and that isn't the end of main()).
The sliced copy you made will stick around "forever" (because the array is
at file scope), and so will the pointer you've installed in p_arr.

[BTW, did you know array indexing begins at 0, not 1? Just checking...]

I'm explaining all this so you know what your code is doing, but I doubt
you really want slices created in the first place...

It would be very useful for me to store these objects from different
subclasses (derived1, derived2 and so on) in an array but if I try to use
these code lines:

//global variable:
base arr[10];
base *p_arr[10];

//creation function:
derived1 obj1;
arr[1] = obj1;
p_arr[1] = &arr[1];

// now p_arr[1] points to a base object and not to a derived1 object.

so is there a way to store objects from different subclasses in a unique
"container", possibly with a random access (like arrays or vectors), without
loosing their original class properties?

Only by storing pointers, and the current thinking is that "smart pointers"
such as those available from the Boost library are the better choice for
storing in STL containers. The only kind of smart pointer provided by the
C++ Standard Library, std::auto_ptr, is specifically /not/ any good for
storing in containers due to its copying-means-transfer-of-ownership
semantics. Fortunately, libraries are now generally designed to not let you
store auto_ptrs in STL containers.

Thank you again for the help!
Marco

P.S. If these questions are too "basics" please let me know if there is a
more suitable group to post... I wouldn't like to be "annoying"! ;-)

I never consider anyone who takes the trouble to explain their questions to
the best of their ability (and disclose the level they're approaching the
questions from) to be annoying. If you'd prefer to post in a newsgroup
that was designed specifically for catering to "newbie"-level questions,
though, I'd invite you to go check out (man
I hate typing that out...)
-leor

 

[Marco]

Hello Leor,

There's no such thing. I assume you meant a multi-file /project/, with base
class in one module and derived in another? The file organization really
does not affect the mechanisms you're grappling with here. Whether
everything were in one big file or spread out across many, you'd still have
exactly the same issues.

Well, I didn't explain the situation: it's a plug-in that is hosted in an
external App. It is compiled into different modules that are "commands"
called from within the host app. Every command creates a derivedX object
with a "derivedX objx;" instruction and destroys all its local variables at
the end of its execution. The fact is that I need to store the created
objects so that when another command is executed it can access the
previously created objects...

I hope I clarified my "situation"...

object).

Whoa. Not sure what you're trying to say there, but no object remains
"available" after its destructor has run; that's why it is called a
"destructor".

Actually I can store an object as a global variable, or better, a member of
a global class (declared in another "module") that is accessible from all
the commands.

From your code below it looks like you're defining an object

(obj1), making a "sliced copy" (a temporary base object created by "slicing
off" the derived part of obj1 and keeping what remains),

This is just the problem, as I loose the derived class properties...

putting a copy of

that base slice into your array, and then finally putting a pointer to that
base slice into your array of pointers. After the "creation function" code
runs, the only object that might be destroyed before your program completes
execution is going to be the original obj1 object (if execution reaches the
end of the block where obj1 is defined, and that isn't the end of main()).
The sliced copy you made will stick around "forever" (because the array is
at file scope), and so will the pointer you've installed in p_arr.

The arrays are managed at a higher level, and are eventually destroyed by
other functions.

[BTW, did you know array indexing begins at 0, not 1? Just checking...]

Yes, I know... thanks anyway!

I'm explaining all this so you know what your code is doing, but I doubt
you really want slices created in the first place...

Yes, you are right and I really appreciate your notes...

Only by storing pointers, and the current thinking is that "smart pointers"
such as those available from the Boost library are the better choice for
storing in STL containers. The only kind of smart pointer provided by the
C++ Standard Library, std::auto_ptr, is specifically /not/ any good for
storing in containers due to its copying-means-transfer-of-ownership
semantics. Fortunately, libraries are now generally designed to not let you
store auto_ptrs in STL containers.



I never consider anyone who takes the trouble to explain their questions to
the best of their ability (and disclose the level they're approaching the
questions from) to be annoying. If you'd prefer to post in a newsgroup
that was designed specifically for catering to "newbie"-level questions,
though, I'd invite you to go check out (man
I hate typing that out...)
-leor

I asked this just to know. I am quite new here, and I found this group to be
really competent and "fast", but I don't want to be an "unpleasant" visitor!

I'll go to the group and check out if it's
more suitable for the moment, but I think I'll keep on visiting this one, as
I read many interesting threads!

Thanx again for your reply!

Marco

 

[Marco]

Hi James,

Look for a tutorial in a good book, or if you are poor then with google,
on "handles".

I've found some info and I'll go through them. Thanx !

Marco

 

[Leor Zolman]

Well, I didn't explain the situation: it's a plug-in that is hosted in an
external App. It is compiled into different modules that are "commands"
called from within the host app. Every command creates a derivedX object
with a "derivedX objx;" instruction and destroys all its local variables at
the end of its execution. The fact is that I need to store the created
objects so that when another command is executed it can access the
previously created objects...

I hope I clarified my "situation"...

Since I don't deal with plug-ins and such myself, I have a difficult time
relating to your particular environment, but fortunately there are lots of
other folks who read this group and are likely to have a good handle on it.

Actually I can store an object as a global variable, or better, a member of
a global class (declared in another "module") that is accessible from all
the commands.

What about having the global container (array or whatever) just store
pointers to the base class. In whatever function obj1 is first
instantiated, create a dynamically-allocated copy of obj1 and install a
pointer to in the container. Then when the original obj1 turns into a
pumpkin, you've got the copy on the free store (complete with all of its
properties) and a pointer to it.
-leor

 

[Marco]

Hello Leor,

Since I don't deal with plug-ins and such myself, I have a difficult time
relating to your particular environment, but fortunately there are lots of
other folks who read this group and are likely to have a good handle on

it.

Fortunately, many programming issues are not specifically related to this
plug-in structure, but are more general...

What about having the global container (array or whatever) just store
pointers to the base class. In whatever function obj1 is first
instantiated, create a dynamically-allocated copy of obj1 and install a
pointer to in the container. Then when the original obj1 turns into a
pumpkin, you've got the copy on the free store (complete with all of its
properties) and a pointer to it.

This is the way I'm moving to at the moment. Thank you very much for
pointing it out and for the help, I really appreciated it!

Marco