This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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; > >} > >----endclip------ > > 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 *AttachedObjects[NBR_OF_OBJS]". > > >-----clip from the caller of dispatcher----- > >Dispatcher.Attach(this, USERS); > >----endclip------ > > 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 > AttachedObjects > >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 > >AttachedObjects[(msgRaw->Receiver)]->EventHandler(msgRaw); > > 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 > functions. 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? /Daniel ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |