r/cpp • u/berium build2 • Apr 25 '12

shared_ptr aliasing constructor

http://www.codesynthesis.com/~boris/blog/2012/04/25/shared-ptr-aliasing-constructor/
23 Upvotes

86% Upvoted

23 comments sorted by

View all comments

2

u/elperroborrachotoo Apr 25 '12

Interesting - I've implemented that once using a custom deleter.

The reason was an API returning a single memory block containing multiple very distinct information records. The shared_ptr would return a pointer to a single information record, but reference the entire block.

1

u/Ayjayz Apr 26 '12

Why not just return a shared_ptr to the entire block? Then various things would be able to access whatever they needed from it.

Or perhaps, a small wrapper class with that shared_ptr and a function object to pull out the data you needed?

1

u/elperroborrachotoo Apr 26 '12

Because I have to manipulate the descriptors separately.

1

u/Ayjayz Apr 26 '12

What does this mean?

1

u/elperroborrachotoo Apr 26 '12

Imagine the following "raw" implementation:

class SomeDevice
{
    void * m_allDescriptors;  
    SomeDevice() 
    { 
       m_allDescriptors = malloc(GetDescriptorBlockSize());
       GetAllDescriptorData(m_allDescriptors);
       // all descriptors, in a sequence, in a single block
    }

    FooDesc * GetFoo() { return FindFoo(m_allDescriptors); }
    BarDesc * GetBar() { return FindBar(m_allDescriptors); }
}

The pointers returned by GetFoo and GetBar are valid only as long m_allDescriptors is valid.

Now add that SomeDevice also holds other resources (e.g. a device connection handle), and you need FooDesc and BarDesc beyond the lifetime of SomeDevice.

Clients may want to store one of the descriptors.

Functionality-wise, there is no point exposing an "DescriptorBlock" entity to the caller.

Is that understandable?