Re: Class hierarchies and concepts
On 2011-12-15 00:22, kelvSYC wrote:
Suppose I have a class hierarchy, whose root class is Foo. Is there a
way to formally prescribe that subclasses of Foo has to export a
type? That is:
This depends very much on what you exactly mean by "has to export a type". Such details become crucial once you reflect upon situations where subclasses of existing subclasses are formed, e.g.
struct Foo1 : public Foo {
typedef ... BarType;
};
struct Foo3 : public Foo1 {};
Does Foo3 satisfy the contract as well?
Further: When you want to impose these requirements. When do you depend on them? Is it just about ensuring that code conventions are checked by code? Or will the developer have to call a function or use a class template anyway?
class Foo { // abstract base class
// Subclasses must export a type BarType, possibly with a
consistent interface - none exists for Foo itself
};
struct Foo1 : public Foo {
typedef ... BarType;
};
struct Foo2 : public Foo {
struct BarType { ... };
};
// So Foo1::BarType and FooType::BarType are valid, and Foo::BarType
could be any of these two
If such a thing exists, is it possible to declare an abstract method
in Foo that returns BarType (where subclasses return their own
BarType)?
You didn't say much about BarType in the beginning. Is this necessarily a class type? Do subclasses need to provide derived types? Anyway, even if the answer to the last two questions is "true", this wouldn't help much, except if you would need this function anyway. See below for ideas in a different direction.
If not, is there a good workaround?
This is hard to say from the information you provided so far. My impression is that you want to combine strict compile-time properties
with dynamic polymorphism. I don't understand why these are coupled. E.g. if you need at some code place the requirement that
a) The type is derived from Foo, and
b) It has some public, unambiguous member type named BarType (with some further properties that you need to be clear about)
you could use std::is_base_of (or the corresponding boost version) to check the first property and define a has_BarType trait that validates that this type has such a member type - you could use BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF here from boost mpl:
http://www.boost.org/doc/libs/1_48_0/libs/mpl/doc/refmanual/has-xxx-trait-named-def.html
to implement that easily.
If there does not exist a "natural" way to validate your requirements (e.g there could be a template, that needs to be instantiated by any provide of a class), you have no 100% guarantee that someone defines a subclass that does not satisfy the wanted criteria. You could make it just harder for someone to forget this. E.g. you could provide a test function that every subclass has to pass. Assume you have both traits mentioned above available you could define a test template "test":
template<class T>
typename std::enable_if<,
std::is_base_of<Foo, T>::value && has_BarType<T>::value,
std::true_type>::type
test_internal(int);
template<class>
std::false_type
test_internal(...);
template<class T>
void test() {
typedef decltype(test_internal<T>(0)) type;
static_assert(type::value, "Incorrect subclass of Foo");
}
[It is simple to replace above tests by equivalent ones valid in pure C++03 code based on sizeof]
Programmers are supposed to instantiate it. If programmers forget this, you could invent a type registry that everyone has to use to register the sub classes (This idiom is often used for different reasons that most developers understand already, e.g. to make the types available for factories and the like). Within this registry you would instantiate test() or would simply move the static assertion into the corresponding class (template) definition.
Developers might still forget to register, but there seems to be little that you can do to prevent that anyway. At some point you need to trust what coworkers are doing or you have to get rid of them ;-)
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]