[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Safe and consistent dereferencing and casting [Was: Code revie

From: Evgeniy Tarassov
Subject: Re: [lmi] Safe and consistent dereferencing and casting [Was: Code review: product editor]
Date: Mon, 26 Mar 2007 12:45:13 +0200

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]