Why casting necessary?

[alg]

Why is so necessary sometimes in C++ that you have to cast a pointer between
a base object and a derived object? Could you give me some examples for me
to understand this concept deeply?

Thanks for your help!

[Daniel T.]

Re: Why casting necessary?

"alg" <alg36897@yahoo .com> wrote:
[color=blue]
> Why is so necessary sometimes in C++ that you have to cast a pointer between
> a base object and a derived object? Could you give me some examples for me
> to understand this concept deeply?
>
> Thanks for your help![/color]

Here is an example.

<http://www.objectmento r.com/resources/articles/visitor>

The article above discribes the Acyclic Visitor pattern. The ability to
cast a base object to it's specialized derived type is necessary for
this pattern.

[David White]

Re: Why casting necessary?

John Dibling <dib@substitute _my_full_last_n ame_here.com> wrote in message
news:b126hvks8j sd8luolij6at4kp l99i9f6dm@4ax.c om...[color=blue]
> On Mon, 14 Jul 2003 11:49:16 -0700, "Mike Wahler"
> <mkwahler@mkwah ler.net> wrote:
>[color=green]
> >alg <alg36897@yahoo .com> wrote in message
> >news:mzCQa.541 44$3o3.3661490@ bgtnsc05-news.ops.worldn et.att.net...[color=darkred]
> >> Why is so necessary sometimes in C++ that you have to cast a pointer[/color]
> >between[color=darkred]
> >> a base object and a derived object?[/color]
> >
> >Usually, it's because of a poor design.[/color]
>
> One cannot make this claim categorically.[/color]

"Usually" isn't categorical.
[color=blue]
> It is often necesarry and
> proper to cast, although I would agree that casts are easy to use
> inappropriately . In COM programming for example, a very common
> scenario is to have many objects which are similar in nature, but have
> some unique prepoerties. For example, suppose you are writing stock &
> option trading software. Your software might abstract common elements
> in to an interface called IOrder, where attirbutes specific to stock
> trades (such as ticker symbol) are in the derived interface
> IStockOrder, and option-specific attributes (such as OPRA code and
> expiration date) are in the derived interface IOptionOrder. Your
> system would likely need to make available to clients an array of
> "all" orders, in which case the array would be an array of IOrder*'s.
> If you subscribe to the theory that casts are categorically wrong,[/color]

"Usually" isn't categorical.
[color=blue]
> then your only other option is to have one array for IStockOrder*'s
> and another for IOptionOrder*'s . If this were the case, you must have
> duplication of at least some code, which I would argue is much more
> indicitave of a design flaw.[/color]

If I had to use members that belonged only to IStockOrder or IOptionOrder,
then I would probably have one collection of IStockOrder*, another of
IOptionOrder*, and perhaps another of the two mixed up in a collection of
IOrder*. I would use each collection as appropriate. The code would be
cast-free and would execute more efficiently. Ideally, everything would be
done polymorphically through a single collection of IOrder*, but if it can't
be then why use a collection of IOrder* if you are going to have to downcast
them all later?

One potential big problem with downcasts is where the project is large and
you have to add another type, which might force you to wade through all your
code, find all your downcasts, and possibly add another case for the added
type all over the place.

I don't see where the code duplication is in having separate collectoins.
You are doing different things with each collection. That's why they are
separate.

DW