Inheritance basic issue form newbie

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

Marco

On Sat, 03 Apr 2004 07:25:56 -0800, Marco wrote:

> 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

James Gregory

>
> Virtual functions only work via pointers.
>

Nitpick - or references.

john

John Harrison

Thank you both for the clarification!

Marco

"John Harrison" <> ha scritto nel messaggio
news:c4mlvh$2jr6hj$...
> >
> > Virtual functions only work via pointers.
> >
>
> Nitpick - or references.
>
> john
>
>

Marco

On Sat, 03 Apr 2004 16:35:52 +0100, James Gregory <> wrote:

>
>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


>
> James

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

Leor Zolman

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"!

"Marco" <> ha scritto nel messaggio
newsoBbc.22471$...
> Thank you both for the clarification!
>
> Marco
>
> "John Harrison" <> ha scritto nel messaggio
> news:c4mlvh$2jr6hj$...
> > >
> > > Virtual functions only work via pointers.
> > >
> >
> > Nitpick - or references.
> >
> > john
> >
> >
>
>

Marco

On Sat, 03 Apr 2004 18:59:28 +0200, Marco wrote:

> 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

James Gregory

On Sat, 3 Apr 2004 18:59:28 +0200, "Marco" <>
wrote:

>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 news:alt.comp.lang.learn.c-c++ (man
I hate typing that out...)
-leor

>
>"Marco" <> ha scritto nel messaggio
>newsoBbc.22471$.. .
>> Thank you both for the clarification!
>>
>> Marco
>>
>> "John Harrison" <> ha scritto nel messaggio
>> news:c4mlvh$2jr6hj$...
>> > >
>> > > Virtual functions only work via pointers.
>> > >
>> >
>> > Nitpick - or references.
>> >
>> > john
>> >
>> >
>>
>>
>

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

Leor Zolman

Hello Leor,

> >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.

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"...

>
> >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".

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...

>
> >It would be very useful for me to store these objects from different
> >subclasses
....
> >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.
>


> >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 news:alt.comp.lang.learn.c-c++ (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 news:alt.comp.lang.learn.c-c++ 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

Marco