129 lines
4.3 KiB
Markdown
129 lines
4.3 KiB
Markdown
---
|
|
title: "Polymorphic Flyweight in C++"
|
|
date: 2020-07-22T16:16:39+0200
|
|
draft: false # I don't care for draft mode, git has branches for that
|
|
description: "A no-boilerplate flyweight pattern"
|
|
tags:
|
|
- design pattern
|
|
- C++
|
|
categories:
|
|
- programming
|
|
series:
|
|
- Generic flyweight
|
|
favorite: false
|
|
---
|
|
|
|
Coming back from our last post about [generic flyweights in C++]({{< relref
|
|
"generic-flyweight-cpp.md" >}}), we can write a flyweight that can be used with
|
|
any abstract base classes.
|
|
|
|
<!--more-->
|
|
|
|
## Motivation
|
|
|
|
I was writing a raytracer in C++, and used an abstract base class to represent
|
|
textures. Having to potentially instantiate numerous identical textures, I
|
|
wanted to avoid that problem and instead use a flyweight for my textures.
|
|
|
|
I first thought about using the generic flyweight scheme that I presented last
|
|
time, however to do so I need a way to store and compare my objects.
|
|
|
|
I needed some infrastructure to extend the technique to be useful for my new
|
|
use case.
|
|
|
|
## RTTI and order
|
|
|
|
My textures' interface are the way I want to manipulate them in my raytracer,
|
|
I cannot have access to the underlying type, and do not want to have to juggle
|
|
their types outside of the implementation.
|
|
|
|
I also want to use RAII effectively, to avoid the headache of juggling
|
|
lifetimes.
|
|
|
|
To this effect, I need to store some `std::unique_ptr<TextureInterface>` inside
|
|
my set. However, to do so I need to come up with a way to totally order my
|
|
values behind the `TextureInterface`.
|
|
|
|
[std::type_info](https://en.cppreference.com/w/cpp/types/type_info) comes to
|
|
the rescue: more specifically its sibling class
|
|
[std::type_index](https://en.cppreference.com/w/cpp/types/type_info/before).
|
|
|
|
I could order my textures by their `std::type_index` to order them first by
|
|
chunks of types, and then sort the values inside the chunks by calling an
|
|
ordering method on my polymorphic objects.
|
|
|
|
|
|
## Implementation
|
|
|
|
The abstract class looked like this:
|
|
|
|
```cpp
|
|
class AbstractTexture {
|
|
// Abstract method to compare two instances of the same class
|
|
virtual bool less_than(const AbstractTexture& other) = 0;
|
|
|
|
public:
|
|
virtual ~AbstractTexture() = default; // Abstract class => virtual destructor
|
|
|
|
friend operator<(const AbstractTexture& lhs, const AbstractTexture& rhs) {
|
|
const std::type_index lhs_i(lhs);
|
|
const std::type_index rhs_i(rhs);
|
|
if (lhs_i != rhs_i)
|
|
returh lhs_i < rhs_i;
|
|
// We are now assured that both classes have the same type
|
|
return less_than(rhs);
|
|
}
|
|
};
|
|
```
|
|
|
|
And one of its children should be implemented like this:
|
|
|
|
```cpp
|
|
class UniformTexture : public AbstractTexture {
|
|
Color color_;
|
|
|
|
bool less_than(const AbstractTexture& other) override {
|
|
// We are assured that 'other' is of the same type at this point
|
|
const auto& rhs = dynamic_cast<const UniformTexture&>(other);
|
|
return color_ < rhs.color_; // Return appropriate order
|
|
}
|
|
};
|
|
```
|
|
|
|
We can now create a flyweight texture class by doing:
|
|
|
|
```cpp
|
|
// Nice alias for a pointer to AbstractTexture
|
|
using texture_ptr = std::unique_ptr<AbstractTexture>;
|
|
|
|
// An implementation of the 'less_than' comparison for 'texture_ptr'
|
|
class TextureCmp {
|
|
bool operator()(const texture_ptr& lhs, const texture_ptr& rhs) {
|
|
return *lhs < *rhs; // Proxy to operator< for AbstractTexture
|
|
}
|
|
}
|
|
|
|
class Texture : Unique<texture_ptr, TextureCmp> {
|
|
// Implement using the underlying AbstractTexture interface
|
|
};
|
|
```
|
|
|
|
## Conclusion
|
|
|
|
I have now showed you this technique to implement a flyweight for any abstract
|
|
class you might want to use it for. Having neither seen anybody use an `std::set`
|
|
to store flyweights, nor anybody writing tutorials about storing polymorphic
|
|
objects in flyweights, I had a blast trying to figure out an elegant solution to
|
|
this problem.
|
|
|
|
My first implementation was complicated by the use of `std::type_info`
|
|
directly, basically re-implementing `std::type_index` because I had missed it
|
|
while reading the docs.
|
|
|
|
We could specialise our `Unique` class to avoid the double dereferencing when
|
|
storing pointers in our set (instead of having the Unique store a pointer to
|
|
the stored smart-pointer). We could also automatise the use of a comparison
|
|
functor similar to the `TextureCmp` class defined above when storing
|
|
pointer-like values in the set. Both of those are left as an exercise to the
|
|
reader :winking_face:
|