Dynamic function call
Thu Jun 14 08:04:00 GMT 2001
Thanks for your answer!
> >-----Original Message-----
> >From: Daniel.Andersson@combitechsystems.com
> >Sent: 14 June 2001 13:10
> > The idÃÂ©a of my code is that all the object that is created
> within a thread
> >attaches it self to a dispatcher. This is done so that they
> can receive
> >messages that are sent to that thread. Every object attaches
> it self in a
> >list that means that when a message is sent to that position
> in the list
> >then every attached object receives that message.
> >Doesn't the linker support this kind of dynamic calls?
> Sounds very much like a C++ virtual function call to me.
> Nothing to do
> with the linker at all.
> >-----clip from the attachfunction in dispatcher-----
> >void CDispatcher::Attach(CCommon* pMsgHandler, Receiver_t RecObj)
> > AttachedObjects[RecObj] = pMsgHandler;
> Ok, so for each receiver type, you have an array entry that
> points to
> the object that wants to receive the messages. I got the
> impression from
> the way you described this above that you wanted a *list* of
> objects of a
> particular type, so they could all receive the message, but
> you could easily
> extend that code to make a singly-linked list, using a next
> item pointer in
> the base class CCommon.
Well, i really dont want a list but an array that holds pointers to the
functions that a want to call. I have declared AttachedObjects as "CCommon
> >-----clip from the caller of dispatcher-----
> >Dispatcher.Attach(this, USERS);
> See, that will be the only object that gets messages for
> USERS: if there
> was already one registered, it will be overwritten in the array.
I see what you mean but that is not a problem at this time since only one
object wants the message.
> >Here comes all the different ways that i have tried so far.
> I want to be
> >able to use the first one but is doesn't work. The array
> >declared as a CBase* AttachedObjects[N] so it will contain
> of a lot of
> CBase * ? Do you not mean CCommon * ? Or is CCommon
> derived from CBase,
> and the other class types (CUsers, CCar, CNodeman ?) derived
> from CCommon ?
> >pointers to all the attached objects. None of the three
> alternatives below
> >works!! The only thing that works is when i hardcode the
> object name in the
> >function (see clip below)
> >Any hints?
> It would have been good if you'd told us in what way it
> doesn't work.
> Does the code fail to compile, or does it just do the wrong thing when
> it executes ?
When i run the line "AttachedObjects[msgRaw->Receiver]->EventHandler(msgRaw)
then i get a "sig trap" from GDB. I assume that this means that i have made
a reference to a memory that isn't available and that the reason for this is
a pointer that has a strange value. However, when i take a look at all the
attached objects (CAR, NODEMANAGER, USERS) in the AttachedObjects then
they all reside within RAM so i think that they have correct memory values
in their registered "this"-pointers.
> >Alt 1
> Looking at your code, I would expect that it does compile
> (although you
> should have shown us the definition of EventHandler), but
> runs wrong. And
> here's the problem: all the pointers in the AttachedObjects
> array are of
> type CCommon *, so the function that gets called here is
> CCommon::EventHandler. What you really want I assume is for
> it to call
> (type derived from CCommon)::EventHandler, but the compiler
> can't do that
> by default, because it doesn't know what type of object the
> array entry
> points to: it knows that it points to a CCommon object, but
> it doesn't know
> that that might be the CCommon base part of a derived object.
> This is exactly the sort of situation that virtual
> functions were made
> for! If you declare EventHandler to be a virtual function in
> the CCommon
> class definition, that means that every object of type
> CCommon, and every
> object of a type derived from CCommon, will carry around a
> pointer to the
> EventHandler function for that particular type. This means
> that when the
> only pointer you have to the object is of CCommon * type, the
> compiler will
> still be able to compile code to get to the correct function,
> by looking
> up the function's address from the actual object itself.
> For more info, refer to a C++ textbook on the subject of virtual
I do have declared the base class (CCommon) function to be virtual: "virtual
void EventHandler(MessageRaw_t *pMsg);" since i always want to override it
with my functions in the derived classes.
Can it be something with my environment that doesn't handle this dynamic
calls to functions?
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to email@example.com
More information about the crossgcc