[Insight-developers] itkEventObject and type_info::before
William A. Hoffman
bill.hoffman@kitware.com
Thu, 13 Dec 2001 23:10:29 -0500
We could always just re-introduce the AnyEvent class, and get rid of the
hierarchy approach.
Really all we need are unique tags for event types. Having it work on
supper classes of an event
may not be needed.
-Bill
At 07:30 PM 12/13/2001 -0800, Lydia Ng wrote:
>Hi Luis,
>
> > 2) typeid( X ).before( typeid( Y )) can be read as
> > "Is Y deriving from X ?"
>
>In "The C++ Programming Language" Stroustrup (3rd ed)
>section 15.4.4
>
>"There is no relation between the relationships defined
>by before and inheritance relationships"
>
>Would you have a link to the RTTI specs?
>
> > Maybe our best option at this point is to implement
> > the behavior of "before" in the EventObject class
> > itself.
>
>I guess if there is no consistency across the
>compiler then we must implement our own "before"
>behavior if we are to support event heirarchies.
>
>I don't think I quite understand your second
>implementation option. I suppose we just need to try
>it and see...
>
>Cheers,
>Lydia
>
>
> > -----Original Message-----
> > From: Luis Ibanez [mailto:ibanez@choroid.cs.unc.edu]
> > Sent: Thursday, December 13, 2001 6:34 PM
> > To: Lydia Ng
> > Cc: Insight-developers (E-mail)
> > Subject: Re: [Insight-developers] itkEventObject and type_info::before
> >
> >
> >
> > Hi Lydia,
> >
> > The intention of the EventObject family is to behave
> > pretty much as the Exceptions. In particular in the
> > sens of having a hierarchy of events and being able
> > to accept for an event any of its descendents (derived
> > classes).
> >
> > the run time type information RTTI support provides
> > the information about the "real" type of objects at
> > run time.
> >
> > typeid(X) is an object that is constructed by using
> > a type X as argument. It is supposed to extract type
> > information that is specific for type X.
> >
> > typeid() is a kind of hybrid that looks like a class
> > but act as a template. A bit like the sizeof() does.
> >
> > Some operators are defined in typeid(). For example
> > the operator== will indicate if the arguments of two
> > typeid() are *exactly* the same type.
> >
> > typeid( A ) == typeid( B )
> >
> > will return true if A and B are exactly the same
> > type and will return false if B derives from A,
> > or A derives from B or if A and B are completly
> > unrelated.
> >
> > For a hierarchy we want to know if a type is
> > deriving from another. Because we want to accept
> > base classes as catch-all for its descendents
> > (as in Exceptions).
> >
> > the operator before() is supposed to play this role.
> >
> >
> > typeid( A ).before( typeid( B ) )
> >
> >
> > will return true if B derives from A.
> > It will return false if A and B are of the same
> > type or if A derives from B or if A and B
> > are unrelated.
> >
> > The problem with RTTI is that it is relatively
> > recent. In gcc 2.8 rtti was off by default and
> > you needed to activate it with the --rtti option
> > when compiling.
> >
> > Unfortunately the behavior doesn't seems to be
> > standard among platforms. Which means that some
> > platforms have not implemented correctly the
> > specification for RTTI. It is however, working
> > fine for exceptions, so it could be interesting
> > to see the source code in gcc for managing
> > exceptions.
> >
> >
> > The information about type_info is pretty cryptic.
> > This "collation sequence" description seems to
> > be the term that was copied from the specification
> > and repeated without further explanation in other
> > documents.
> >
> >
> > When searching on the web about details of
> > "before" one of the things that google brings up
> > are some comments in the gcc mailing list about
> > problems with the implementation of typeid()...
> >
> >
> > To summarize:
> >
> > 1) the behavior of typeid() is not yet standard
> > among platforms.
> >
> > 2) typeid( X ).before( typeid( Y )) can be read as
> > "Is Y deriving from X ?"
> >
> > 3) typeid( X ) == typeid( Y ) can be read as
> > "Is X exactly the same type as Y ?"
> >
> >
> > So, for your question: StarEvent action should not
> > be triggered by ProgressEvent or viceversa because
> > StarEvent and ProgressEvent are sibling deriving
> > both from AnyEvent.
> >
> > Maybe our best option at this point is to implement
> > the behavior of "before" in the EventObject class
> > itself.
> >
> > That could be relatively easily implemented by creating
> > static strings in each new class on the hierarchy of
> > Events and using comparision of these strings in order to
> > determine descendants.
> >
> > Another way is to copy the IP encoding for addresses
> > accepting the restriction that a particular Event can
> > not have more than 255 derived classes (which a priori
> > sound reasonable). In that case we will need only one byte
> > to encode any given level of the hierarchy.
> >
> > Comparitions between events should not be significantly
> > slow if we use this last method.
> >
> >
> > What do you like better ?
> >
> >
> >
> > Thanks
> >
> >
> >
> > Luis
> >
> >
> > ========================================
> >
> >
> > On Thu, 13 Dec 2001, Lydia Ng wrote:
> > > Hi All,
> > >
> > > In SubjectImplementation::InvokeEvent an observer
> > > is executed if it event "the same as" (*observer)->m_Event or
> > > if event is "before" (*observer)->m_Event
> > > (see code below).
> > >
> > > What does the "before" ordering mean?
> > > Who determines this "before" ordering?
> > > Is it consistent across platforms?
> > >
> > > The only description I can on this find is:
> > > ---------------------------
> > > You can also ask a typeinfo object if it precedes another typeinfo
> > > object in the implementation-defined "collation sequence," using
> > > before(typeinfo&), which returns true or false. When you say,
> > >
> > > if(typeid(me).before(typeid(you))) // ...
> > >
> > > you're asking if me occurs before you in the collation sequence.
> > > ---------------------------
> > > (from http://www.codeguru.com/cpp/tic/tic0270.shtml)
> > >
> > > It's not clear to me what the ordering mean? What
> > > is a "collation sequence"?
> > >
> > > In my LevelSetShapeDetectionTest I attached an
> > > observer that response to the ProgressEvent only.
> > >
> > > In Win32/VC++ the observer also get activated by
> > > StartEvent. While in Cygwin/gcc the observer
> > > was *not* activated by StartEvent.
> > > Which behavior is correct?
> > >
> > >
> > > Lydia
> > >
> > >
> > >
> > > ----------------------------------------------------------
> > > void
> > > SubjectImplementation::
> > > InvokeEvent( const EventObject & event,
> > > Object* self)
> > > {
> > > for(std::list<Observer* >::iterator i = m_Observers.begin();
> > > i != m_Observers.end(); ++i)
> > > {
> > > const EventObject * e = (*i)->m_Event;
> > > if( typeid( *e ) == ( typeid( event ) ) ||
> > > typeid( *e ).before( typeid( event ) ) )
> > > {
> > > (*i)->m_Command->Execute(self, event);
> > > }
> > > }
> > > }
> > > _______________________________________________
> > > Insight-developers mailing list
> > > Insight-developers@public.kitware.com
> > > http://public.kitware.com/mailman/listinfo/insight-developers
> > >
> >
> > --
> > Luis Ibanez CB#: 7060
> > Research Assistan Professor phone: (919) 843 5436
> > Division of Neurosurgery fax: (919) 966 6627
> > University of North Carolina at Chapel Hill email:
> > ibanez@cs.unc.edu
> > Chapel Hill, NC 27599-7060
>http://www.cs.unc.edu/~ibanez
>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers