Designing around shallow constness with inheritance

Question

Background

I'm writing an image handling class. For this question two requirements of the class are of interest:

• Must have "deep" const correctness.
• Must allow sub-image aliases, a.k.a. sections or slicing without performing deep copies of image data.

By deep constness I mean the following. Consider this example class:

class Image{
public:
    ...
    Image(const Image&);

    Image alias(int x0, int y0, int x1, int y1) const;
private:
    Buffer image_data;
};

And assume you have a function that is passed a const reference to a image, like so:

void foo(const Image& im){
    Image alias = im.alias(0,0, 10, 10);
    // Hold on, the mutable alias can modify the data in the const argument!
}

The above alias function call defeats the constness of the argument because the contents of the argument image can be modified through the non-const alias. I can't return a const Image from alias because well that makes no sense really and the copy constructor of Image will happily construct a mutable instance anyway.

My solution (and I've seen it used often so I don't claim originality here) is to introduce two classes (interfaces really, but for the simplicity they are classes in this example and return by value is okay, in reality alias(...) returns a shared_ptr to interface):

class ConstImage{
public:
    ConstImage alias(...) const;
};

class Image{
public:
    Image alias(...);
};

Now the following code:

void foo(const Image& im){ 
    // compile error, cannot convert ConstImage to Image, perfect!
    Image alias = im.alias(...); 
}

And of course you would change the signature to void foo(const ConstImage& im) so that you can accept invocations like foo(const_im.alias(...)) or other ConstImage objects.

Now of course we want foo(const ConstImage& im) to be callable (1) with a mutable Image too and here is where the question comes in.

Question

Using inheritance: class Image : public ConstImage will make all Image types usable through ConstImage references and pointers. It will also facilitate code-reuse between the const and non-const implementations which by necessity are very similar.

This solves the above mentioned problem (1). However if you look at the inheritance relation as an "is a" statement then "a mutable image IS AN immutable image" makes no sense. Which speaks against using inheritance here.

My question is, is this kind of (ab)use of inheritance widely acceptable? Is there some other better solution that I have overlooked? Note that the Image class is more of an interface so naive value conversion from Image to ConstImage isn't possible. Although one could probably come up with something crazy to allow it.

Answer 1

Is there some other better solution that I have overlooked

An Image "is a" ConstImage in the sense that it can always be "treated as const". Using inheritance strictly to model "IS A" relationships is also known as "Liskov substitution principle" (LSP), which is about behaviour. The LSP is fulfilled when an inherited class can always substitute its base class without violating the correctness of the program. And as long as you do not call a non-const method of an Image (which you typically won't do when passing it through a ConstImage reference), an Image will always behave like a ConstImage.

Answer 2

If you accept that Const just means "won't be manipulated from here", as most of your question seems to imply, a const_image isn't immutable.

Seems like your class is a smart-pointer with extra accessors and (if non-const) manipulators.

You might benefit from basing it on std::shared_ptr.

Next, to emulate deep-const, your Image-class needs to do the following:

1. Ensure a const instance lacks manipulators.

   That's easily done, just make sure no manipulator-method is const-qualified, and all inspector-methods are.

   int getX() const; // inspector
   void setX(int);   // manipulator
   

2. Ensure a const instance does not expose any non-deep-const internal state.

   Any inspector-method only returns const-qualified references or equivalent pointers, and only for state which itself emulates deep-const, or does not have any linked state.
   Naturally deep-copies may always be returned. (Deep-copies and Shallow copies are trivially equivalent for state without internal links.)

3. Ensure a non-const instance cannot be constructed from a const instance.

   Now this last point looks like a back-breaker, as C++ unfortuately does not allow making a constructor const.
   Fortunately, we can get around that with more code: Just declare a second class.

struct image;
struct const_image {
    // ctors, dtor, const inspectors
    // no manipulators, and only expose as const_image, other deep-const type or deep-copy
private:
    friend class image;
    // explicitly defaulted (move-)assignment-operators
    // Whatever members are neccessary to maintain the data.
    // Probably only a single shared_ptr and some indices
};

struct image : const_image {
    // delegating ctors for all but copy-construction and move-constructor
    // copy-ctor accepting a non-const image, probably defaulted
    // move-constructor, (move-)assignment-operators
    // additional non-const inspectors (where possible a thin mask over the const ones)
    // these all return Image or manipulatable internal state
    // manipulators
private:
    // if neccessary, optional additional state for supporting manipulation-operations
};

Answer 3

Create an abstract class ReadableImage. Derive both MutableImage and ImmutableImage (and also ImageSlice) from this class. Then the is-a relations hold. Don't take ImmutableImage parameters in functions unless the function actually expects the image to really be immutable, for example because it expects it to not be modified by another thread.

The annoying part of this is slicing, but that's a problem that you always face with class hierarchies representing data in C++.

Answer 4

TL; DR

1. (Personal, unproven idea)
   • "This cptr is const, that mptr is not
2. Almost-proven idea, on top of OpenCV's Mat_<T> design
   • Bake const-ness into the template parameter T, and
   • Make sure all holes are plugged, by making some changes to OpenCV.

---

This is a tough one, and one that even well-known imaging libraries such as OpenCV do not find a perfect solution. Instead most people would live with pragmatism, i.e. be satisfied with whatever they have got.

Here is my unproven idea:

• In each Image class (and Buffer class as well), maintain two raw pointer fields:
  • One is a non-const void (or uchar) pointer.
  • One is a const void (or uchar) pointer. (Meaning that it does not allow one to modify the data being pointed to, via this pointer.)
• In Image instances that need to "enforce const-ness", even if someone has managed to obtain a non-const-qualified reference to that Image, the non-const pointer is intentionally set to nullptr.
  • Before any pixel modifications, someone will have to validate the pointer before proceeding. Typically, if one intends to modify a whole bunch of pixels, one only needs to validate the pointer once, so with proper design this should not become a performance overhead.
  • All modifications will be done via the non-const pointer, and all read-only operations will be done via the const pointer.
  • For mutable images (or, images that allow modifications), the two pointers will always have the same value.

This is just a wild, unproven idea. Feel free to explore and critique. That said, my idea is brewed from long time use of OpenCV and low-level image processing implementations.

---

As a bonus, if you are already familiar with OpenCV, you can try the following two declarations:

const auto sz = cv::Size(3, 3); const uchar fillval = 0U; cv::Mat_<uchar> matMutable1B(sz, fillval); cv::Mat_<const uchar> matImmutable1B(sz, fillval);

Notice that the first one allows modifications via the usual OpenCV style, e.g. mat.at(row, col) = fillval;, mat(row, col) = fillval;, mat.ptr(row)[col] = fillval;, whereas the second one doesn't allow.

This is due to the template parameter <T> being const-qualified by the second declaration.

However, as of currently, this is not foolproof, because someone who obtain the pointer via mat.data will get a uchar*, regardless of the const-qualification of template parameter <T>.

---

One very important distinction about immutability / object state access control versus C++ style notational const-qualification

C++ const-qualification affects code which "come by / obtain" a reference to a certain class. Thus, it passes along const-qualification by something like a chain-of-custody of types. The Image itself cannot find out whether someone owning a reference to it and making a call to it is const-qualified or not. Instead, C++ enforces this when type-checking the caller's code, and blocks the caller's attempt. The Image class never knows.

My idea of using two pointers (const / non-const) and setting the non-const to nullptr is an attempt to solve this issue at runtime. Thus, someone who obtains an Image that is not const-qualified, but its non-const data pointer is nullptr, will face runtime consequences.

---

Ultimately, if this is too difficult to discuss, maybe just spend some time with OpenCV, and try both const-qualify the matrix itself as well as the template parameter, to see which technique satisfies the most of your requirements.

---

Another lesson learned from OpenCV is that you must implement your own reference-counting mechanism in the image class. Failure to do so makes the library user's code very brittle.

Answer 5

Looks like I'm a little late to the party, but hopefully the OP sees this answer. The best solution to your problem is not to use inheritance at all, but rather leave the Image class as is. Instead, what you need are two Alias classes: Alias, and ConstAlias. Then, change all of your functions that don't really need the Image itself, but an alias to take Alias or ConstAlias as appropriate. The alias method has a const and non-const version, which return ConstAlias and Alias types respectively.

Does this sound familiar from somewhere? Replace Image with vector, and Alias with iterator, and you've got... well, half the STL.

It's better to distinguish explicitly between Images and Aliases using the type system, the former is an owner, and the latter is not. Most functionality just requires a view (possibly mutable) of the data, it doesn't need to actually mess with the ownership at all. This makes you think harder about whether your function should take an Image or just an alias. It also allows you to avoid using shared_ptr at all and stick with a much simpler and clearer (and possibly more performant) model of ownership.

Answer 6

I think you'd be better to come at the problem from a slightly different perspective.

C++ in many ways works best with types that act like value types. That is, they behave like built-in types or most STL types. You could make an Image class that acts like an std::vector and is a value type with 'deep' const correctness by simply copying data whenever you copy an image or take an image slice but that would be somewhat inefficient due to all the copying. Those are the semantics you'd ideally like from your Image class however.

You should think of the sharing of image data for efficiency as purely an implementation detail of your class. It's not something the end user should need to know about from an interface point of view. One way to achieve this is by using copy-on-write to give the appearance of a value type while under the hood you are sharing data wherever possible. This used to be a common implementation tactic for std::string although it is not any more, primarily because of thread safety concerns (which you'll have to address too if you want to use your Image class in multi-threaded scenarios).

One implication of this alternative approach is that alias() is a bad name for your image slice function. It exposes an implementation detail in the name of a public API. That function should instead be called slice(). With a copy-on-write implementation you could call slice() on a const Image and get an Image. Behind the scenes the image data would be shared until you tried to write to it, at which point you would make a copy. A more sophisticated implementation might tile the image and only copy tiles that were touched by the write so changing a few pixels wouldn't take a copy of the entire image slice.

Answer 7

This solves the above mentioned problem (1). However if you look at the inheritance relation as an "is a" statement then "a mutable image IS AN immutable image" makes no sense. Which speaks against using inheritance here.

Well ... a mutable image IS an imutable image, with extra capabilities (for mutation) - which makes a lot of sense (just like a surgeon is a doctor with extra capabilities). The fact that the extra capabilities are a distinction between mutable and immutable makes little difference (it's still an immutable image with mutable behavior added to it).

I imagine the confusion that created the question, is the fact that in spoken language, it doesn't make sense to say "a mutable X is an immutable X" (because in rational thinking, either A or non-A, but not both).

This OO "is-a" relationship though, is not really the same "is-a" relationship that you have in spoken English.

Answer 8

The fundamental problem is you are trying to use an unsound model of types. Despite wording in the ISO C++ Standard and wrong ideas expressed by Bjarne in the ARM originally, there is no such thing as a const type. Contrarily, constness is a property of pointers only (and references but lets leave them out for simplicity). Therefore a class representing a const and non-const type is a wrong concept.

Const in C++ itself is an unsound concept, it should have been removed. This is evident in the Standard Library when trying to model the concept generically. It only works one level deep as you have observed. It applies to the access path to an object, but does not propagate to a data structure (linked collection of objects). The simplest example is a singly linked list: a const pointer to a list node immediately yields a non-const next pointer.

In a theoretical model, const and non-const abstractions are distinguished by the absence or presence of mutator methods and are therefore distinct types without any "isA" relation, whatever that is.

My best advice: stop trying to model abstractions with OO techniques because OO is proven to be so highly restricted in applicability it is not suitable for modelling any but the simplest concepts. Learn some functional programming methods instead.