From 5b5a9bbd5d18798020a16e61d9e2d99430f75efc Mon Sep 17 00:00:00 2001 From: Bruno BELANYI Date: Thu, 27 Aug 2020 17:32:51 +0200 Subject: [PATCH] posts: generic-flyweight: fix lint issues --- content/posts/generic-flyweight-cpp.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/posts/generic-flyweight-cpp.md b/content/posts/generic-flyweight-cpp.md index f10b06e..303b3db 100644 --- a/content/posts/generic-flyweight-cpp.md +++ b/content/posts/generic-flyweight-cpp.md @@ -86,10 +86,12 @@ cannot keep the `vector` sorted to do binary searches and insertion, because the flyweights rely on their index inside the vector being stable. Instead, I'd recommend you use an `std::set` for the following reasons: + - its semantic implies an ordering relationship, without duplication - it has an (asymptotically) efficient insertion. - it has stable iterators/pointers on insertion: a flyweight can just refer to a pointer to the object contained inside the `std::set`. + That last bullet point is the reason why I'd recommend using a `set` instead of a sorted `vector`. @@ -110,13 +112,13 @@ public: ``` The little `&(*instances_.emplace(c))` does all the work for us: + - `instances_.emplace(c)` creates the corresponding metadata only if it isn't in the set already. - We get an iterator back to the inserted element from this operation - We dereference it (`*`) to get a `GlyphMetadata&` - We take the address of that reference for our flyweight (`&()`). - ### Templating This scheme with an `std::set` is easily templatable: indeed we can imagine a