Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   Why do I want RTTI? (http://www.velocityreviews.com/forums/t283405-why-do-i-want-rtti.html)

RM 05-29-2004 11:35 PM

Why do I want RTTI?
 
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



Karthik 05-29-2004 11:55 PM

Re: Why do I want RTTI?
 
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.

Rolf Magnus 05-30-2004 10:22 AM

Re: Why do I want RTTI?
 
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.


Denis Remezov 05-30-2004 12:46 PM

Re: Why do I want RTTI?
 
"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

Steven T. Hatton 05-30-2004 03:39 PM

Re: Why do I want RTTI?
 
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

RM 05-30-2004 04:09 PM

Re: Why do I want RTTI?
 
"Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message
news:xrqdnTyBGfaonSfdRVn-tA@speakeasy.net...
> 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




bartek 05-30-2004 04:51 PM

Re: Why do I want RTTI?
 
"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.

Alf P. Steinbach 05-30-2004 05:00 PM

Re: Why do I want RTTI?
 
* "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?

Jorge Rivera 05-30-2004 06:29 PM

Re: Why do I want RTTI?
 
RM wrote:
> "Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message
> news:xrqdnTyBGfaonSfdRVn-tA@speakeasy.net...
>
>>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



Steven T. Hatton 05-30-2004 06:48 PM

Re: Why do I want RTTI?
 
RM wrote:

> "Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message
> news:xrqdnTyBGfaonSfdRVn-tA@speakeasy.net...
>> 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


All times are GMT. The time now is 03:06 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.