Re: Get Derived (templated class) from Base pointer?
On Sat, 8 Dec 2007 02:54:05 CST, Ulrich Eckhardt <doomster@knuut.de> wrote:
Quoting a quote from a recent posting by Jerry Coffin:
"Each name that contains a double underscore (_ _) or begins with an
underscore followed by an upper-case letter (2.11) is reserved to the
implementation for any use." ($17.4.3.1.2).
Thanks. Noted.
Now I need to store all of these CDerived objects in a generic container.
Since CDerived is a template class, I can't do this straight away. I have
to create a base class, CBase, that is not templated.
No, you can also use value wrappers like e.g. boost::any or boost::variant<>
if the variance of the types is limited. At least I would use smart
pointers to solve the problem of resource management.
My problem with a discriminated union is that the variance of types is not
limited due to the significantly templated nature of CDerived. My problem with
boost::any is that I need to know the specific type of CDerived or the value it
holds beforehand before I can get the value out of the boost::any object.
I tried adding an additional virtual function to CBase:
virtual CBase* GetPtr() = 0;
and then creating a typedef in CDerived that is it's current type and
overriding GetPtr():
typedef CDerived<TValue, TPolicy1, TPolicy2> tThis;
tThis* GetPtr()
{
return this;
}
This still does not work.
Using covariant return types...
CBase and CDerive compile fine, because you are allowed to change the
return type in a virtual function if it is compatible with the return
type from the base class, and CDerived<>* is compatible with CBase*
since CDerived is derived from CBase.
What does not work is that GetPtr() in CDerived still returns a CBase
pointer, so I get an error from the compiler that basically "GetValue()
is not a member of CBase".
No, sorry, but this can't work. The point is that if you invoke it on the
baseclass, you still only have the static interface of the baseclass. All
those types are _static_ and determined at compile time. No trick or magic
will raise those barriers.
That's my frustration: that typeid() seems to have some trick or magic at
runtime because I can do typeid(*pBase).name() and it will tell me, for example,
CDerived<std::string, MyPolicy1, My Policy2>. If RTTI is compiled into the
executable, typeid() has the necessary magic to figure out the derived type,
(because the actual object was a specific, templated CDerived object), but the
user of the language does not have this same magic available.
This isn't a critical point for me; it can be gotten around by putting extra
burden on the user to keep track of types, but I was hoping to create something
truly "generic" where the user doesn't have to do the work of keeping track of
the specific CDerived types.
So, I think that my ultimate problem is that: given only a CBase*, is
there any way I can get a CDerived* that is immediately callable, without
having to case CBase* to a specific CDerived* (of which I don't know the
exact type, because CDerived is a template class).
You want to use the interface of a derived class without wanting to know
which derived class that is. If this would work, how would you or the
compiler know what that function returns and what to store it in? After
all, it could be _any_ instantiation of the template or even a totally
unrelated class. IOW, there is no way except redesigning what you want.
The compiler should know because the object pointed to is actually some specific
templated variant of CDerived. The compiler does know to the extent that
typeid() can figure it out. It shouldn't be an unrelated class unless I did
some kind of scary cast from some totally unrelated class to a CBase pointer.
If a user of the library did that, they would get what they deserve.
Another way would be to specify the type when retrieving the object from the
container. The container would then perform a dynamic_cast and return the
object or throw.
container<base> cont;
cont.insert(new derived1);
derived1* p = cont.get<derived1>(0);
This is basically what I am doing know; I was just hoping to find a way that
knowing the specific derived type was not necessary to ease the burden on the
user. What I'm experimenting with is holding the value in a Value object (from
Volker Simonis, http://www.progdoc.de/papers.htm) in the base class. One
advantage of his Value object is that assignment/copying out to an arbitrary
variable/object does not require a cast like boost::any does, e.g., this should
work if the CBase at vec[0] holds a std::string or a value compatible with
std::string:
std::string t;
try
{
t = vec[0].GetValue();
}
catch(Incompatible_Type_Exception e)
{
// do something here, notify the user
}
It seems to me that the concepts of "generic programming" (templates) and
containers do not play well at all together when the templated objects
need to be in the containers rather than being the containers.
It's not that, it's totally unrelated to the objects in the container being
template. If they were not templates and derived from a baseclass you would
face the same problems.
True, but the only reason I need a base class in the first place is because
containers require homogeneous objects, which templates are not. Ultimately,
all of my problems would be solved quite elegantly if there was a way I could do
what typeid() does and get the actual derived object/pointer pointed to by a
base pointer.
It might be possible to give better suggestions if you described a bit how
you expect the user to use your library.
Uli
Uli, thank you for taking the time to think about this and look into it. I
don't disagree with anything you said. My basic conclusion is that I can't do
what I'd like to do given the current state of the language, even though
typeid() can apparently do it. That is the source of my frustration!
The library is a framework for storing/retrieving/displaying/editing application
settings. The goal is to give the user a UI framework that is at once flexible,
easily customizable, and functional with any arbitrary settings "objects" with
the minimum amount of work on the part of the user.
I'm breaking down the displaying/editing of a "Property" into it's component
parts and allowing the user to create their own small custom classes to
customize any of the parts, e.g.:
template<
typename TValue,
typename TDrawName = CDrawString,
typename TDrawValue = CDrawString,
typename TEditCtrl = CNoEdit,
typename TValidate = CNoValidate,,
typename TData = CNoData,
BOOL CATEGORY = FALSE>
class CProperty : public CPropertyBase
and then "Properties" and all of their appearance and editing behaviors are
built using simple typedefs, e.g.:
typedef CProperty<std::string, CDrawString, CDrawString, CEditCtrl, CNoValidate,
CNoData> CStringProperty;
typedef CProperty<std::string, CDrawString, CDrawString, CComboBoxCtrl,
CNoValidate, CStringList> CStringListProperty;
I will probably create a separate CPropertyTraits class that is templated for
all of the various policy classes so that CProperty would become:
template<typename TValue, typename TTraits>
class CProperty : public CPropertyBase
Each of the individual "policy classes" is typically quite small and easy to
write and maintain, and the more complex "Property" objects are just constructed
from the various simpler pieces.
If a user wants to customize anything in the PropertiesCtrl for any given type
of property, they write their own custom drawing class (if needed) to draw the
value and their own custom editing, validating, and data classes (if needed) to
be able to edit that type of value in the UI. For example, they want to allow
the user to edit a RECT, so they create a class to draw the rect in the UI
(maybe just express it as a string, like "(122, 78, 156, 150)" and call
CDrawString, or maybe do something else), and a class to edit a rect, which may
provide a dropdown where they can choose each metric or may spawn 4 new
'subproperties" with numeric-only edit boxes, or whatever they like.
One workhorse of the UI is a custom combobox that will drop down any custom
control the user wishes to create, including dialogs. This makes it easier for
the user to create their own editor controls for arbitrary objects.
The UI for displaying/editing properties is CPropertiesCtrl (a subclassed
ListBox). It holds a pointer to each property and calls that property to draw
itself in the listbox or edit itself. Currently, the ListBox holds
CPropertyBase pointers (well, DWORDs that I cast to CPropertyBase*).
I'm not in a bind in the UI with storing the Value in the derived class, because
all of the drawing, editing, validating occurs via virtual functions in the base
class with fixed signatures. These are overridden in the derived class, which
knows the exact type of the held value and the exact policy classes, so the
derived class makes the calls to the policy classes and passes the value to them
as a function parameter (templated in the policy class methods with
specialization as needed, or alternatively the policy class assigned for, say,
editing, must be appropriate for the type of value held by the Property).
The only frustration is for getting properties out of the CPropertiesCtrl in a
generic way. In order to get the value out, the user needs an actual CProperty
pointer because only CProperty knows the type of the value whereas CPropertyBase
does not. Sure, the user can wire up set/get code that does the appropriate
casts, though part of idea behind the library is that the CPropertyCtrl is just
another storage object for the properties collection with the same interface as,
say, .ini file storage, xml file storage, registry storage, encrypted storage,
etc., and that the user need not write any get/set code but just store the app
settings to the properties control for displaying/editing and then retrieve them
back, update the app settings objects, and write them to the real storage when
the application user saves the settings. In order for setting/getting to work
in a generic way in this case, I need to get the value out of a property without
knowing the exact type of the templated CProperty because all I have is a base
pointer.
I guess I'll have to store the values in the base class in something like Mr.
Simonis' Value class to make this work, but it would be so sweet if typeid()
allowed you to get a pointer to the derived object or there was a typeof()
operator that did that.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]