[Insight-developers] itkEventObject and type_info::before
Lydia Ng
lng@insightful.com
Thu, 13 Dec 2001 19:30:35 -0800
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)=20
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
>=20
>=20
>=20
> Hi Lydia,
>=20
> The intention of the EventObject family is to behave
> pretty much as the Exceptions. In particular in the=20
> sens of having a hierarchy of events and being able
> to accept for an event any of its descendents (derived
> classes).
>=20
> the run time type information RTTI support provides
> the information about the "real" type of objects at
> run time.
>=20
> 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.=20
>=20
> typeid() is a kind of hybrid that looks like a class
> but act as a template. A bit like the sizeof() does.
>=20
> Some operators are defined in typeid(). For example
> the operator=3D=3D will indicate if the arguments of two
> typeid() are *exactly* the same type.
>=20
> typeid( A ) =3D=3D typeid( B )
>=20
> 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.
>=20
> For a hierarchy we want to know if a type is=20
> deriving from another. Because we want to accept
> base classes as catch-all for its descendents
> (as in Exceptions).
>=20
> the operator before() is supposed to play this role.
>=20
> =20
> typeid( A ).before( typeid( B ) )
>=20
>=20
> 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.
>=20
> 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.
>=20
> 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=20
> fine for exceptions, so it could be interesting
> to see the source code in gcc for managing=20
> exceptions.
>=20
> =20
> The information about type_info is pretty cryptic.
> This "collation sequence" description seems to=20
> be the term that was copied from the specification
> and repeated without further explanation in other
> documents.
>=20
>=20
> When searching on the web about details of=20
> "before" one of the things that google brings up
> are some comments in the gcc mailing list about
> problems with the implementation of typeid()...
>=20
>=20
> To summarize:
>=20
> 1) the behavior of typeid() is not yet standard
> among platforms.
>=20
> 2) typeid( X ).before( typeid( Y )) can be read as
> "Is Y deriving from X ?"
>=20
> 3) typeid( X ) =3D=3D typeid( Y ) can be read as
> "Is X exactly the same type as Y ?"
>=20
>=20
> So, for your question: StarEvent action should not
> be triggered by ProgressEvent or viceversa because
> StarEvent and ProgressEvent are sibling deriving
> both from AnyEvent.
>=20
> Maybe our best option at this point is to implement
> the behavior of "before" in the EventObject class
> itself.
>=20
> 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.=20
>=20
> Another way is to copy the IP encoding for addresses=20
> accepting the restriction that a particular Event can=20
> not have more than 255 derived classes (which a priori=20
> sound reasonable). In that case we will need only one byte=20
> to encode any given level of the hierarchy.
>=20
> Comparitions between events should not be significantly
> slow if we use this last method.
>=20
>=20
> What do you like better ?
>=20
>=20
>=20
> Thanks
>=20
>=20
>=20
> Luis
>=20
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
>=20
> On Thu, 13 Dec 2001, Lydia Ng wrote:
> > Hi All,
> >=20
> > In SubjectImplementation::InvokeEvent an observer
> > is executed if it event "the same as" (*observer)->m_Event or=20
> > if event is "before" (*observer)->m_Event
> > (see code below).
> >=20
> > What does the "before" ordering mean?=20
> > Who determines this "before" ordering?
> > Is it consistent across platforms?=20
> >=20
> > 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,=20
> >=20
> > if(typeid(me).before(typeid(you))) // ...=20
> >=20
> > you're asking if me occurs before you in the collation sequence.=20
> > ---------------------------
> > (from http://www.codeguru.com/cpp/tic/tic0270.shtml)
> >=20
> > It's not clear to me what the ordering mean? What=20
> > is a "collation sequence"?
> >=20
> > In my LevelSetShapeDetectionTest I attached an
> > observer that response to the ProgressEvent only.
> >=20
> > 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?
> >=20
> >=20
> > Lydia
> >=20
> >=20
> >=20
> > ----------------------------------------------------------
> > void=20
> > SubjectImplementation::
> > InvokeEvent( const EventObject & event,
> > Object* self)
> > {
> > for(std::list<Observer* >::iterator i =3D m_Observers.begin();
> > i !=3D m_Observers.end(); ++i)
> > {
> > const EventObject * e =3D (*i)->m_Event;
> > if( typeid( *e ) =3D=3D ( 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
> >=20
>=20
> --=20
> 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:=20
> ibanez@cs.unc.edu
> Chapel Hill, NC 27599-7060 =20
http://www.cs.unc.edu/~ibanez