boost::flyweight and smart pointers

[bitrex]

Say I have a class, call it Bitmap, which holds onto a texture resource,
say "my_bitmap.png" which has to be allocated and deallocated through a
constructor and destructor the "old-fashioned" way via new and delete.

I then want to stick this class in a wrapper class that can be used as a
key-value type for boost::flyweight, using a smart pointer to wrap the
Bitmap class so that all objects in a graphics program that use
"my_bitmap.png" can refer to the one instance, and when all objects that
use it are destroyed the resource is release.

Is it more appropriate to use a std::unique_ptr or a std::shared_ptr in
the wrapper class in this circumstance?

[Alf P. Steinbach]

`std::shared_ptr` implements shared ownership, while `std::unique_ptr`
implements single but transferable ownership.

So ask yourself: do I have a case of shared ownership, or do I have a
case of transferable single ownership?

Or do I have something else, like e.g. automatic cloning on copy?


Cheers & hth.,

- Alf

[bitrex]

Indeed, my point of confusion is about how boost::flyweight is operating
internally.

Instead of looking at the source right now (what a silly idea!) I'll
instead just randomly speculate that the flyweight type is itself
creating a wrapper type which holds a shared reference, and each time a
new class is created with a key that hashes to the same value type it
makes a new wrapper and clones the reference, rather than call the
copy/move constructor on my own.

So I'd guess that I'd want to use a unique_ptr for the resource in my
wrapper, as at the end of the day all flyweights that hash to an
instance of it are finally all referring to the same resource. When all
the flyweights are gone the pointer to my wrapper is released, and along
with it goes the unique_ptr contained within.

[woodb...@gmail.com]

I would start with unique_ptr since it's simpler than shared_ptr.
If you find later that shared_ptr would be helpful, you can switch
to that.


Brian
Ebenezer Enterprises
http://webEbenezer.net

[Öö Tiib]

You got false dichotomy: "look into code" (what a silly idea) versus
"randomly speculate" (what a silly idea). Other usual choices are "try
it out" (can't hurt), ask around (should raise RTFM answers) and
"look into documentation" (good idea but lot of people leave it as
last).

By documentation it seems that how the boost flyweight is behaving
internally can be configured.
http://www.boost.org/doc/libs/1_63_0/libs/flyweight/doc/tutorial/configuration.html
That is quite usual with boost so I already suspected that.

>
> So I'd guess that I'd want to use a unique_ptr for the resource in my
> wrapper, as at the end of the day all flyweights that hash to an
> instance of it are finally all referring to the same resource. When all
> the flyweights are gone the pointer to my wrapper is released, and along
> with it goes the unique_ptr contained within.

Stuff that is contained in that flyweight seems that needs to be copy
assignable and hashable with Boost.Hash by the very same documentation.
Have you tried the thing at all?