Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Why do I want RTTI?

Reply
Thread Tools

Why do I want RTTI?

 
 
Steven T. Hatton
Guest
Posts: n/a
 
      05-30-2004
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
 
Reply With Quote
 
 
 
 
Luther Baker
Guest
Posts: n/a
 
      05-30-2004
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
 
Reply With Quote
 
 
 
 
Cy Edmunds
Guest
Posts: n/a
 
      05-30-2004
"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/


 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      05-30-2004
* "Cy Edmunds" <(E-Mail Removed)> 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?
 
Reply With Quote
 
Denis Remezov
Guest
Posts: n/a
 
      05-31-2004
"Steven T. Hatton" wrote:
>
> RM wrote:
>
> > "Steven T. Hatton" <(E-Mail Removed)> wrote in message
> > news(E-Mail Removed)...
> >> 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
 
Reply With Quote
 
Steven T. Hatton
Guest
Posts: n/a
 
      05-31-2004
Denis Remezov wrote:

> "Steven T. Hatton" wrote:
>>
>> RM wrote:
>>
>> > "Steven T. Hatton" <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
I want to output all of my STDOUT to a single line....dont want to scroll seancsnyder@gmail.com Perl Misc 4 09-13-2006 04:32 PM
I want to create a link "e-mail this page to a friend" on clicking this link i want to send the URL of that current page to a friend pavi Javascript 0 01-13-2006 12:10 PM
Hi I have one web application and i want to get the number of users who are currently accessing the application. Also I want to get the user details of each user, which is stored in a database. How can I do this? Pls help. Getting No: and anu Java 11 05-12-2005 03:25 PM



Advertisments