C++: Create derived instance by 'extending?' base instance / implement downcast? - c++

Question

I have a C++ class which is essentially a container:
class SimpleContainer {
public:
// Various accessor methods / iterators
private:
// The actual content
}
In addition to the SimpleContainer - I want to create a StrictContainer which extends SimpleContainer semantically by enforcing rules on the content, but using the same content as an existing SimpleContainerinstance.
class StrictContainer : public SimpleContainer {
StrictContainer( const SimpleContainer& simple ) {
// Check content in simple, and raise an exception
// if it is not valid.
}
}
Now - my problem is what kind of relationship there should be between the SimpleContainer and the StrictContainer:
is-a:
seems natural; and that is what I have indicated with the inheritance, but then I will create a StrictContainer instance based on extending SimpleContainer instance post construction - is that possible?
has-a
Alternatively I could implement it as a has-a relationship where the StrictContainer has a SimpleContainer member, but then I would need to implement all the accessors and iterators again in the StrictContainer and forward to the SimpleContainer implementation.
The container is quite large; and I would really not copy the content when creating the StrictContainer. I guess what I would like was a way to implement my own downcast operator:
SimpleContainer simple;
// Fill simpleContainer
{
StrictContainer* strict = downcast<StrictContainer>( simple )
...
}
Where the downcast<StrictContainer> would call a method on the StrictContainer to verify the content of the simple input argument?

Answer 1

is-a would be a disaster. Assume the rule is that SimpleContainer contains integers, and StrictContainer only contains odd integers.
StrictContainer strict;
SimpleContainer simple;
strict.insert(1); // OK value is odd
simple.insert(2); // OK simple doesn't check oddness.
SimpleContainer& sc = strict; // Reference to base.
sc.SimpleContainer::insert(2); // Uh-oh. That will use the simple container version
// of insert (even in the presence of virtual functions)
// and will insert an invalid even number into `simple`.
You need has-a

Answer 2

As a third option, I'd suggest a policy based approach as in the following example:
#include<vector>
#include<cassert>
template<typename T>
struct NoCheck {
static bool isOk(T) {
return true;
}
};
template<typename T>
struct TheAnswer {
static bool isOk(T t) {
return false;
}
};
template<>
struct TheAnswer<int> {
static bool isOk(int t) {
return t == 42;
}
};
template<typename T, template<typename> class C = NoCheck>
struct SimpleContainer {
bool add(T t) {
if(C<T>::isOk(t)) {
vec.push_back(t);
return true;
}
return false;
}
private:
std::vector<T> vec{};
};
int main() {
SimpleContainer<int> c1;
assert(c1.add(42));
assert(c1.add(0));
SimpleContainer<int, TheAnswer> c2;
assert(c2.add(42));
assert(not c2.add(0));
}
If having a common interface is a requirement (it's not clear from the question), you can get it with a factory method and a type-erased internal class still based on a policy.

Answer 3

So, restating your requirements:
The StrictContainer has the same interface as the SimpleContainer,
with additions. (This implies an is-a relationship to the
interface.)
Intstantiating a new StrictContainer should not require
copying the SimpleContainer content. (This implies decomposition using a handle.)
Assuming that the lifetime of the original SimpleContainer spans the StrictContainer, this sounds like the decorator pattern. So, if you're willing to do a bit of decomposition -- how about defining an interface like this?
class MyInterface {
// No contained state needed at all.
public:
virtual ~MyInterface() {}
virtual bool getThing1() const = 0;
virtual int getThing2() const = 0;
// and so on...
};
class MyDecorator : public MyInterface {
MyInterface &m_impl; // Could use a smart pointer, if available.
public:
MyDecorator( MyInterface &impl ): m_impl(impl) {}
bool getThing1() const override { return impl.getThing1(); }
int getThing2() const override { return impl.getThing2(); }
// and so on...
};
Then your concrete implementation:
class SimpleContainer : public MyInterface {
bool m_thing1;
int m_thing2;
... // All the real state goes here.
public:
... // All the interface methods go here.
};
Then, the StrictContainer is a lightweight container that retains a handle to the original SimpleContainer, instead of a full copy.
class StrictContainer : public MyDecorator {
// Additional state, if needed.
public:
StrictContainer( SimpleContainer &base ): MyDecorator(base) {}
// Additional methods (like your additional validation method.
};
There's no need for a special "downcast operator", since you already need to call the constructor for StrictContainer and it already does everything you need.
SimpleContainer simple( ... ); // Construct as normal.
StrictContainer strict = simple; // Assuming no extra arguments needed.
Pretty simple.
And yes, you need to write the delegation operations for each method in the interface once in the decorator class. But you could define multiple variants of the StrictContainer class without having to implement them again (unless you want to override some of them).

Answer 4

I prefer implementing something like this using a combination of Adapter and Strategy (Policy) pattern. You can decouple the StrictContainer (which is the adapter) from the underlying container holding the data entirely. Very similar to how std::queue is implemented as an adapter to another container (like vector). You can then parameterize the StrictContainer-adapter with whatever constraints you want to. Whenever you add an element to your container, it is checked whether the constraint is satisfied. If it is, the element is added to the underlying container, otherwise you can do whatever you prefer to (leave the container unchanged or throw an exception for instance).
template<typename T, typename Container, typename Constraint>
class StrictContainer
{
public:
StrictContainer(const Container& container = {}, Constraint constraint = {})
: container_(container), constraint_(constraint)
{
validateAll();
}
StrictContainer(Container&& container, Constraint constraint = {})
: container_(std::move(container)), constraint_(constraint)
{
validateAll();
}
// container interface ...
void push_back(const T& value)
{
if(!constraint_(value))
throw WhateverException();
container_.push_back(value);
}
private:
void validateAll()
{
for(const auto& value : container_)
{
if(!constraint_(value))
throw WhateverException();
}
}
Container container_;
Constraint constraint_;
};
You can then instantiate the StrictContainer like this:
StrictContainer<int, std::vector<int>, IsEvenConstraint<int>> myContainer;
myContainer.push_back(2);
myContainer.push_back(18);
myContainer.push_back(7); // throws
In this case the StrictContainer uses a std::vector as data store, but you could use whatever container you prefer (like your SimpleContainer). The constraints can then be implemented like this
template<typename T>
struct IsEvenConstraint
{
bool operator()(const T& value)
{
return value % 2 == 0;
}
};
Depending on the classes of containers and constraints you like to support you might have to adjust the interface accordingly. Using variadic templates you can extend the StrictContainer to support multiple constraints. You can use a lambda for the constraint as well.
auto lessThanOne = [](float f) { return f < 1.0f; };
StrictContainer<float, std::vector<float>, decltype(lessThanOne)> myContainer2(std::vector<float>{}, lessThanOne);
myContainer2.push_back(0.1f);
myContainer2.push_back(1.7f); // throws