Re: [lmi] Safe and consistent dereferencing and casting [Was: Code review: product editor]

[Evgeniy Tarassov]

On 3/24/07, Greg Chicares <address@hidden> wrote:
> Copying a one-line idiom is okay, but copying a five-line idiom
> ten times doesn't sound right. Here's a different idea:
>
> -    return dynamic_cast<wxFrame&>(*GetFrame());
> +    return safely_dereference_as<wxFrame>(GetFrame());
>
> Please tell me your opinion, because I'm thinking of implementing
> that soon. It seems clear to read. The function template can deduce
> its argument type. Using RTTI for the two types in the error message
> would make it easy to find the offending code: the only case that
> RTTI wouldn't suffice to disambiguate is

Personally I really like it -- to implement a repeating pattern with a
single line. I was thinking about such a template before, but only for
the type checking (without dereferencing the pointer). And it was not
compelling enough -- to introduce it only as a replacement for
dynamic_cast with additional debugging information.

IMHO the only tiny disadvantage is that the pointer dereference is now
hidden. Looking at:
 return safely_dereference_as<wxFrame>(GetFrame());
I catch myself thinking that the result is still a pointer, even
though the template name says otherwise.

> and there I was wondering whether static type checking would be
> possible, e.g.:
>
> -    Windows axis_choice_wins_;
> +    std::vector<MultiDimAxisAnyChoice*> axis_choice_wins_;

Currently the code does not force an axis to use a wxChoice as a
widget for its value selection. It could use anything. On another hand
lmi does not have (yet?) an axis which which is more complicated than
a list of values and the default wxChoice approach is used for every
in 'lmi' axis. If you think that we do not benefit from such a feature
(being generic) and that it brings too much of pointers joggling, then
removing this 'feature' we will simplify the code a lot (since we will
be able to move the value selection code from axis directly into
MultiDimGrid, which will eliminate couple of helper functions and
another couple of virtuals).

--
With best wishes,
Evgeniy Tarassov