Why do I want RTTI?

Discussion in 'C++' started by RM, May 30, 2004.

  1. RM

    RM Guest

    Help me understand why would anyone want RTTI.
    Would it RTTI be considered a violation of OO concept?

    Secondly, I like to know how popular is Exception and namespace in C++.

    Troll: I hate exceptions especially user-defined exceptions (but I am ok
    with built-in exceptions). I still prefer functions returning error code.
    And Namespace seems to be largely ignored.

    Thanks
     
    RM, May 30, 2004
    #1
    1. Advertising

  2. RM

    Karthik Guest

    RM wrote:

    > Help me understand why would anyone want RTTI.


    Primarily for debugging purposes, I suppose.

    > Would it RTTI be considered a violation of OO concept?


    One place where you can (theoretically ) is reinterpret_cast. But
    that is way too dangerous.

    >
    > Secondly, I like to know how popular is Exception and namespace in C++.
    >
    > Troll: I hate exceptions especially user-defined exceptions (but I am ok
    > with built-in exceptions).


    That is strange, since from a programmer point of view, it is
    totally transparent anyway. Assume you are writing an imaging library,
    where the user tries to access beyond the boundaries of width and height
    of the image, would you prefer to return different values (remember, the
    return value would depend on the type of the function, 0 for ints, ""
    for char *). A cleaner way might be to throw a custom exception and ask
    the user to catch it. That might be more cleaner.

    But I do agree that it has got a runtime overhead. But unless you are
    programming for systems where memory footprint ought to be low ( for
    embedded sys, like that), there is no reason why you should not use
    exceoptions.


    > I still prefer functions returning error code.
    > And Namespace seems to be largely ignored.



    >
    > Thanks
    >
    >



    --
    Karthik.
    Humans please 'removeme_' for my real email.
     
    Karthik, May 30, 2004
    #2
    1. Advertising

  3. RM

    Rolf Magnus Guest

    RM wrote:

    > Help me understand why would anyone want RTTI.


    It can be useful in some places.

    > Would it RTTI be considered a violation of OO concept?


    Yes. Interestingly, newer OO languages like java make heavy use of it.

    > Secondly, I like to know how popular is Exception and namespace in
    > C++.


    Exceptions haven't been used for quite a long time. It seems that they
    get used more nowadays, but still there are lots of projects that don't
    use exceptions. With namespaces, it seems to be similar.

    > Troll: I hate exceptions especially user-defined exceptions (but I am
    > ok with built-in exceptions). I still prefer functions returning
    > error code.


    IMHO, exceptions are useful in some places, but classic error return
    codes are often preferable.

    > And Namespace seems to be largely ignored.


    I'm using them now in all my C++ projects. But it seems I'm part of a
    minority in this regard.
     
    Rolf Magnus, May 30, 2004
    #3
  4. "Steven T. Hatton" wrote:
    >
    > Rolf Magnus wrote:
    >
    > > RM wrote:
    > >
    > >> Help me understand why would anyone want RTTI.

    > >
    > > It can be useful in some places.

    >
    > Suppose you have a collection of objects derived from a particular base
    > class, for example CanvasItem. CanvasItems are form the content of some
    > kind of graphical image and consist of Rectangles, ComplexPolygons,
    > PixMaps, etc. These might all get pushed into a CanvasItemVector<> that
    > only knows them as CanvaItems. Later you want to do something with all the
    > PixMaps. You can use RTTI to select the PixMaps fromm the CanvasItemVector
    > contents.
    >


    You can but only should do so if you have first considered virtual functions
    and ruled them out for a compelling reason (such reason cannot be seen from
    your example). Maybe it's just me, but for the number of times I have used
    dynamic_cast, I have seen it being abused many times more.

    Denis
     
    Denis Remezov, May 30, 2004
    #4
  5. Rolf Magnus wrote:

    > RM wrote:
    >
    >> Help me understand why would anyone want RTTI.

    >
    > It can be useful in some places.


    Suppose you have a collection of objects derived from a particular base
    class, for example CanvasItem. CanvasItems are form the content of some
    kind of graphical image and consist of Rectangles, ComplexPolygons,
    PixMaps, etc. These might all get pushed into a CanvasItemVector<> that
    only knows them as CanvaItems. Later you want to do something with all the
    PixMaps. You can use RTTI to select the PixMaps fromm the CanvasItemVector
    contents.

    >> Would it RTTI be considered a violation of OO concept?

    >
    > Yes.


    I don't really see why it would be considered a violation of OO. Care to
    elaborate.

    > Interestingly, newer OO languages like java make heavy use of it.


    Java certainly does provide and use a powerful introspection and reflection
    facility.

    >> Secondly, I like to know how popular is Exception and namespace in
    >> C++.

    >
    > Exceptions haven't been used for quite a long time. It seems that they
    > get used more nowadays, but still there are lots of projects that don't
    > use exceptions.


    Part of the reason is that they are hard to understand. They are frequently
    treated as an afterthought in C++ text books.

    > > With namespaces, it seems to be similar.


    That seems to be due to the problem that not all compilers implement(ed)
    RTTI until recently. Trolltech's documentation mentions this problem.

    >> I hate exceptions especially user-defined exceptions (but I am
    >> ok with built-in exceptions). I still prefer functions returning
    >> error code.

    >
    > IMHO, exceptions are useful in some places, but classic error return
    > codes are often preferable.


    I believe exceptions should be use far more frequently, and both the
    understand and the support for exceptions in C++ needs to be improved.
    'Traditional' error returns seem potentially limiting from my perspective.
    I'll have to wait for the coffee to kick in before I try to explain that.

    >> And Namespace seems to be largely ignored.

    >
    > I'm using them now in all my C++ projects. But it seems I'm part of a
    > minority in this regard.


    Again, there seem to be a history of partial support, as well as a problem
    of understanding. Namespaces, in combination with the use of headers and
    #includes can lead to some bizarre results. I've tried to use namespaces
    in my code as much as seems reasonable. It really does require a lot more
    work than the comperable use of packages, for example, in Java.
    --
    STH
    Hatton's Law: "There is only One inviolable Law"
    KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
    Mozilla: http://www.mozilla.org
     
    Steven T. Hatton, May 30, 2004
    #5
  6. RM

    RM Guest

    "Steven T. Hatton" <> wrote in message
    news:...
    > Rolf Magnus wrote:
    >
    > > RM wrote:
    > >
    > >> Help me understand why would anyone want RTTI.

    > >
    > > It can be useful in some places.

    >
    > Suppose you have a collection of objects derived from a particular base
    > class, for example CanvasItem. CanvasItems are form the content of some
    > kind of graphical image and consist of Rectangles, ComplexPolygons,
    > PixMaps, etc. These might all get pushed into a CanvasItemVector<> that
    > only knows them as CanvaItems. Later you want to do something with all

    the
    > PixMaps. You can use RTTI to select the PixMaps fromm the

    CanvasItemVector
    > contents.
    >
    > >> Would it RTTI be considered a violation of OO concept?

    > >
    > > Yes.

    >
    > I don't really see why it would be considered a violation of OO. Care to
    > elaborate.
    >


    I may be wrong but this is how I see it.
    The main reason why we have CanvasItemVector in the first place, is we want
    to deal with all CanvasItem object transparently - Polymorphism ?. If we
    need to know the object type, we no longer have Polymorphism. The problem
    is what happen when we introduce a new class derived from CanvasItem; the
    new class will have to be handled in many different places whereever RTTI
    appeared.


    > > Interestingly, newer OO languages like java make heavy use of it.

    >
    > Java certainly does provide and use a powerful introspection and

    reflection
    > facility.
    >
    > >> Secondly, I like to know how popular is Exception and namespace in
    > >> C++.

    > >
    > > Exceptions haven't been used for quite a long time. It seems that they
    > > get used more nowadays, but still there are lots of projects that don't
    > > use exceptions.

    >
    > Part of the reason is that they are hard to understand. They are

    frequently
    > treated as an afterthought in C++ text books.
    >
    > > > With namespaces, it seems to be similar.

    >
    > That seems to be due to the problem that not all compilers implement(ed)
    > RTTI until recently. Trolltech's documentation mentions this problem.
    >
    > >> I hate exceptions especially user-defined exceptions (but I am
    > >> ok with built-in exceptions). I still prefer functions returning
    > >> error code.

    > >
    > > IMHO, exceptions are useful in some places, but classic error return
    > > codes are often preferable.

    >
    > I believe exceptions should be use far more frequently, and both the
    > understand and the support for exceptions in C++ needs to be improved.
    > 'Traditional' error returns seem potentially limiting from my perspective.
    > I'll have to wait for the coffee to kick in before I try to explain that.
    >
    > >> And Namespace seems to be largely ignored.

    > >
    > > I'm using them now in all my C++ projects. But it seems I'm part of a
    > > minority in this regard.

    >
    > Again, there seem to be a history of partial support, as well as a problem
    > of understanding. Namespaces, in combination with the use of headers and
    > #includes can lead to some bizarre results. I've tried to use namespaces
    > in my code as much as seems reasonable. It really does require a lot more
    > work than the comperable use of packages, for example, in Java.
    > --
    > STH
    > Hatton's Law: "There is only One inviolable Law"
    > KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
    > Mozilla: http://www.mozilla.org
     
    RM, May 30, 2004
    #6
  7. RM

    bartek Guest

    "RM" <I_am_not_@_home.com> wrote in
    news:qHnuc.624696$oR5.537544@pd7tw3no:

    (...)

    > I may be wrong but this is how I see it.
    > The main reason why we have CanvasItemVector in the first place, is we
    > want to deal with all CanvasItem object transparently - Polymorphism
    > ?. If we need to know the object type, we no longer have
    > Polymorphism. The problem is what happen when we introduce a new
    > class derived from CanvasItem; the new class will have to be handled
    > in many different places whereever RTTI appeared.


    This is exactly where you want the visitor pattern. It's a "strictly OO"
    way of doing double dispatch in C++.

    Though, visitor's got problems of its own, and sometimes looks cumbersome
    if there are lots of types to dispatch. Neverthless, visitor can help
    guarantee that every type in a, say, CanvasItemVector will be 'serviced',
    or else you'll get a compile-time error -- something that doesn't really
    happen with switches.
     
    bartek, May 30, 2004
    #7
  8. * "RM" <I_am_not_@_home.com>:
    >
    > Help me understand why would anyone want RTTI.


    One example is when implementing the Visitor pattern (google it).


    > Would it RTTI be considered a violation of OO concept?


    That's not a meaningful question. Is a 'for'-loop a violation of
    OO concepts?



    > Secondly, I like to know how popular is Exception and namespace in C++.


    Standard C++ is based on exceptions and namespaces.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, May 30, 2004
    #8
  9. RM

    Jorge Rivera Guest

    RM wrote:
    > "Steven T. Hatton" <> wrote in message
    > news:...
    >
    >>Rolf Magnus wrote:
    >>
    >>
    >>>RM wrote:
    >>>
    >>>
    >>>>Help me understand why would anyone want RTTI.
    >>>
    >>>It can be useful in some places.

    >>
    >>Suppose you have a collection of objects derived from a particular base
    >>class, for example CanvasItem. CanvasItems are form the content of some
    >>kind of graphical image and consist of Rectangles, ComplexPolygons,
    >>PixMaps, etc. These might all get pushed into a CanvasItemVector<> that
    >>only knows them as CanvaItems. Later you want to do something with all

    >
    > the
    >
    >>PixMaps. You can use RTTI to select the PixMaps fromm the

    >
    > CanvasItemVector
    >
    >>contents.
    >>
    >>
    >>>>Would it RTTI be considered a violation of OO concept?
    >>>
    >>>Yes.

    >>
    >>I don't really see why it would be considered a violation of OO. Care to
    >>elaborate.
    >>

    >
    >
    > I may be wrong but this is how I see it.
    > The main reason why we have CanvasItemVector in the first place, is we want
    > to deal with all CanvasItem object transparently - Polymorphism ?. If we
    > need to know the object type, we no longer have Polymorphism. The problem
    > is what happen when we introduce a new class derived from CanvasItem; the
    > new class will have to be handled in many different places whereever RTTI
    > appeared.
    >


    Usually that is a design flaw, and hence the notion of RTTI being useless.

    However, consider this example...

    class Event
    {
    ..... // Don;t care about details right now
    };

    Class EventHandler
    {
    ....// HEre goes everything you need for the mechanism
    protected:
    virtual bool handleEvent(Event* anEvent)=0;
    };


    Now, your specific message handler only know how to handle a specific
    type of request. However, the APi dictates that every EventHandler must
    handle Event objects. Eg.

    class MyEvent : public Event
    {
    };

    class MyHandler : public EventHandler
    {
    protected:
    virtual bool handleEvent(Event* myEvent);
    }

    Here we may want to guarantee that only events of type MyEvent are
    caught be MeHandler.

    Hence your handleEvent may end-up looking like this...

    bool MyHandler::handleEvent(Event* myEvent)
    {
    if(!dynamic_cast<MyEvent*>(myEvent))
    ; // Can't handle this event. Logic flaw....
    }


    There may be better designs to solve this. However, here RTTI allows
    your specific handlers to determine weather the received event is
    something they can handle.

    This does not pollute the original design in any way, as RTTI is only
    used for specific handlers. You can still treat MyHandler as any other
    type of event handler...

    JLR
     
    Jorge Rivera, May 30, 2004
    #9
  10. RM wrote:

    > "Steven T. Hatton" <> wrote in message
    > news:...
    >> I don't really see why it would be considered a violation of OO. Care to
    >> elaborate.


    > I may be wrong but this is how I see it.
    > The main reason why we have CanvasItemVector in the first place, is we
    > want
    > to deal with all CanvasItem object transparently - Polymorphism ?.


    In that particular instance, we /do/ want all of them to act generically.
    We don't care about the details of each CanvasItem. I think of it like
    passengers on a train. All the conductor cares about is whether you have a
    ticket. (And that you behave yourself). He doesn't care if you are a
    doctor, computer programmer, etc. IF you happen to get to an international
    border, there will be questions regarding your national citizenship.
    That's when the passenger needs to produce some kind of 'type information'.

    Polymorphism, like many OO terms, does not have a single, universal
    definition. Budd provides a few definition. I'll use this from his Intro
    to OOP: "In programming languages, a polymorphic object is any entity, such
    as a variable or function argument, that is permitted to hold values of
    differing types during the course of exectution."


    > If we
    > need to know the object type, we no longer have Polymorphism.


    I'm not sure that is really correct. Polymorphism seems to be a
    circumstantial characteristic which is not required for all instances in
    which the object exhibiting polymorphism is used.

    > The problem
    > is what happen when we introduce a new class derived from CanvasItem; the
    > new class will have to be handled in many different places whereever RTTI
    > appeared.


    That may, or may not, be a problem. If the objects of the newly introduced
    type are used in many different parts of the program, and require different
    treatment due to their unique characteristics, that's just the nature of
    programming. You can't really get away from that unless you put the
    variant functionality in the object itself. There are often two options to
    implementing functionality for manipulating objects. Either the
    functionality is internal to objects so they /act for themselves/, or it is
    implemented outside of the class, and the objects are /acted on/. In the
    latter case, if you need different behavior per class, it the manipulator
    needs to know what kind of object it is acting on. Sometimes it is not
    reasonable (or even possible) to put functionality into the class. In such
    cases, RTTI is a reasonable way to discriminate between object types.

    I think it's important to keep in mind that OO principles do not require
    that all objects and or functions be polymorphic. It's also important to
    remember that C++ was not designed as a strictly OOPL. Furthermore, IMO,
    what matters in the final analysis is not whether the program adheres
    strictly to some set of definitions considered as OOP, but rather, whether
    the program does what it was designed to do, is reasonably efficient,
    reliable, robust, and above all maintainable.

    --
    STH
    Hatton's Law: "There is only One inviolable Law"
    KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
    Mozilla: http://www.mozilla.org
     
    Steven T. Hatton, May 30, 2004
    #10
  11. Denis Remezov wrote:

    > "Steven T. Hatton" wrote:


    >> Suppose you have a collection of objects derived from a particular base
    >> class, for example CanvasItem. CanvasItems are form the content of some
    >> kind of graphical image and consist of Rectangles, ComplexPolygons,
    >> PixMaps, etc. These might all get pushed into a CanvasItemVector<> that
    >> only knows them as CanvaItems. Later you want to do something with all
    >> the
    >> PixMaps. You can use RTTI to select the PixMaps fromm the
    >> CanvasItemVector contents.
    >>

    >
    > You can but only should do so if you have first considered virtual
    > functions and ruled them out for a compelling reason (such reason cannot
    > be seen from
    > your example).


    My example was directly taken from Qt's Canvas Module:
    http://doc.trolltech.com/3.3/canvas.html

    It doesn't always make sense to put functionality inside objects. For
    example, say you want to produce an animation that changes the behavior of
    a certain class of objects after a given number of frames. If you try to
    program that behavior into each class, the classes will be very complicated
    and specialized. The could not be used without modification in another,
    similar animation.

    > Maybe it's just me, but for the number of times I have
    > used dynamic_cast, I have seen it being abused many times more.


    Perhaps. My experience has been that a lot of C++ code has workarounds for
    things that could better be handled by features of the language, but were
    not available on all target platforms or compilers.
    --
    STH
    Hatton's Law: "There is only One inviolable Law"
    KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
    Mozilla: http://www.mozilla.org
     
    Steven T. Hatton, May 30, 2004
    #11
  12. RM

    Luther Baker Guest

    Steven T. Hatton wrote:

    ....
    >
    >
    > That may, or may not, be a problem. If the objects of the newly introduced
    > type are used in many different parts of the program, and require different
    > treatment due to their unique characteristics, that's just the nature of
    > programming. You can't really get away from that unless you put the
    > variant functionality in the object itself. There are often two options to
    > implementing functionality for manipulating objects. Either the
    > functionality is internal to objects so they /act for themselves/, or it is
    > implemented outside of the class, and the objects are /acted on/. In the
    > latter case, if you need different behavior per class, it the manipulator
    > needs to know what kind of object it is acting on.


    GoF Mediator pattern.

    > Sometimes it is not
    > reasonable (or even possible) to put functionality into the class. In such
    > cases, RTTI is a reasonable way to discriminate between object types.
    >
    > I think it's important to keep in mind that OO principles do not require
    > that all objects and or functions be polymorphic. It's also important to
    > remember that C++ was not designed as a strictly OOPL. Furthermore, IMO,
    > what matters in the final analysis is not whether the program adheres
    > strictly to some set of definitions considered as OOP, but rather, whether
    > the program does what it was designed to do, is reasonably efficient,
    > reliable, robust, and above all maintainable.


    Nice thread.

    -Luther
     
    Luther Baker, May 30, 2004
    #12
  13. RM

    Cy Edmunds Guest

    "RM" <I_am_not_@_home.com> wrote in message
    news:R69uc.621770$Ig.109542@pd7tw2no...
    > Help me understand why would anyone want RTTI.
    > Would it RTTI be considered a violation of OO concept?


    RTTI has gotten a bad rap based on code like this:

    Car *pcar = dynamic_cast<Car*>(pvehicle);
    if (pcar)
    ...
    else
    Boat *pboat = dynamic_cast<Boat*>(pvehicle);
    if (pboat)
    ...
    else
    ...

    ad nauseum. However that is hardly the only possible use of RTTI. In many
    object oriented systems an object is allowed to export multiple interfaces,
    some of which may not be implemented. RTTI is how to find out. That is
    hardly a "violation of OO concept" in my book.

    >
    > Secondly, I like to know how popular is Exception and namespace in C++.


    They're pretty popular in my neighborhood.

    >
    > Troll: I hate exceptions especially user-defined exceptions (but I am ok
    > with built-in exceptions). I still prefer functions returning error code.


    I would advise you to make the transition from C to C++. The kind of code
    you prefer winds up looking like a bunch of error checks with the actual
    functionality buried in a blizzard of if tests. Exceptions help us keep
    normal program flow and error checking as separate as possible.

    Your dislike of user-defined exceptions really surprises me. Do you also
    dislike user defined functions and classes? That's where the power is! But I
    would agree that they should all be derived from std::exception if that's
    what you mean.

    > And Namespace seems to be largely ignored.


    In so far as that's true I'm sorry to hear it.

    >
    > Thanks
    >
    >


    --
    Cy
    http://home.rochester.rr.com/cyhome/
     
    Cy Edmunds, May 30, 2004
    #13
  14. * "Cy Edmunds" <> schriebt:
    > >
    > > Troll: I hate exceptions especially user-defined exceptions (but I am ok
    > > with built-in exceptions). I still prefer functions returning error code.

    >
    > I would advise you to make the transition from C to C++. The kind of code
    > you prefer winds up looking like a bunch of error checks with the actual
    > functionality buried in a blizzard of if tests.


    Just say no to error checking. ;-)


    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, May 30, 2004
    #14
  15. "Steven T. Hatton" wrote:
    >
    > RM wrote:
    >
    > > "Steven T. Hatton" <> wrote in message
    > > news:...
    > >> I don't really see why it would be considered a violation of OO. Care to
    > >> elaborate.

    >
    > > I may be wrong but this is how I see it.
    > > The main reason why we have CanvasItemVector in the first place, is we
    > > want
    > > to deal with all CanvasItem object transparently - Polymorphism ?.

    >
    > In that particular instance, we /do/ want all of them to act generically.
    > We don't care about the details of each CanvasItem. I think of it like
    > passengers on a train. All the conductor cares about is whether you have a
    > ticket. (And that you behave yourself). He doesn't care if you are a
    > doctor, computer programmer, etc. IF you happen to get to an international
    > border, there will be questions regarding your national citizenship.
    > That's when the passenger needs to produce some kind of 'type information'.
    >


    (Also in response to your other reply):
    A visitor pattern may be appropriate here (with the Conductor being a Visitor).
    True, it would involve some additional abstraction, but instead of switching
    based on the dynamic type (which could become a mess) you would have just two
    virtual calls.

    One downside of the GoF-style VP with two virtual calls is a circular dependency
    between the participants. In a tightly coupled system this should not be a
    concern; otherwise, another layer of abstraction might be in order. At some
    point (e.g. interfacing two disparate systems) a dynamic_cast would become
    quite justified.

    [...snip...]

    Denis
     
    Denis Remezov, May 31, 2004
    #15
  16. Denis Remezov wrote:

    > "Steven T. Hatton" wrote:
    >>
    >> RM wrote:
    >>
    >> > "Steven T. Hatton" <> wrote in message


    >
    > (Also in response to your other reply):
    > A visitor pattern may be appropriate here (with the Conductor being a
    > Visitor). True, it would involve some additional abstraction, but instead
    > of switching based on the dynamic type (which could become a mess) you
    > would have just two virtual calls.
    >
    > One downside of the GoF-style VP with two virtual calls is a circular
    > dependency
    > between the participants. In a tightly coupled system this should not be
    > a
    > concern; otherwise, another layer of abstraction might be in order. At
    > some point (e.g. interfacing two disparate systems) a dynamic_cast would
    > become quite justified.
    >
    > [...snip...]
    >


    This is what GoF have to say about the visitor pattern:

    "Adding new ConcreteElement classes is hard. The Visitor pattern makes it
    hard to add new subclasses of Element. Each new ConcreteElement gives rise
    to a new abstract operation on Visitor and a corresponding implementation
    in every ConcreteVisitor class. Sometimes a default implementation can be
    provided in Visitor that can be inherited by most of the ConcreteVisitors,
    but this is the exception rather than the rule."

    "So the key consideration in applying the Visitor pattern is whether you are
    mostly likely to change the algorithm applied over an object structure or
    the classes of objects that make up the structure. The Visitor class
    hierarchy can be difficult to maintain when new ConcreteElement classes are
    added frequently. In such cases, it's probably easier just to define
    operations on the classes that make up the structure. If the Element class
    hierarchy is stable, but you are continually adding operations or changing
    algorithms, then the Visitor pattern will help you manage the changes."
    ....

    Known Uses:
    ....

    "IRIS Inventor [Str93] is a toolkit for developing 3-D graphics
    applications. Inventor represents a three-dimensional scene as a hierarchy
    of nodes, each representing either a geometric object or an attribute of
    one. Operations like rendering a scene or mapping an input event require
    traversing this hierarchy in different ways. Inventor does this using
    visitors called "actions." There are different visitors for rendering,
    event handling, searching, filing, and determining bounding boxes.

    To make adding new nodes easier, Inventor implements a double-dispatch
    scheme for C++. _*The_scheme_relies_on_run-time_type_information_* and a
    two-dimensional table in which rows represent visitors and columns
    represent node classes. The cells store a pointer to the function bound to
    the visitor and node class."

    --
    STH
    Hatton's Law: "There is only One inviolable Law"
    KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
    Mozilla: http://www.mozilla.org
     
    Steven T. Hatton, May 31, 2004
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Harrison

    Re: RTTI

    John Harrison, Jul 14, 2003, in forum: C++
    Replies:
    2
    Views:
    473
    John Harrison
    Jul 14, 2003
  2. Zeng Dinghao
    Replies:
    3
    Views:
    500
    Andrey Tarasevich
    Nov 11, 2004
  3. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    996
    Mark Rae
    Dec 21, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,266
    Smokey Grindel
    Dec 2, 2006
  5. Replies:
    30
    Views:
    1,378
    Noah Roberts
    Aug 27, 2012
Loading...

Share This Page