I use shared_ptr as an instance variable in Objective-C class. So I want to know if memory management is correct.
#interface MyClass () {
#private
std::shared_ptr<vector<pair<pair<float, float>, pair<float, float>>>> _periods; // In real code I use typedefs
}
Objects of this class lives long and happy life. But I must overwrite _periods often.
First I create initial _periods in init with helper function which looks like this.
shared_ptr<vector<pair<pair<float, float>, pair<float, float>>>> periodsScaled(...)
{
auto periods = std::make_shared<RALG::periods>();
// ... fill pairs of points
return periods;
}
Then in MyClass I have generatePeriods function which overwrites instance variable.
- (void)generatePeriods
{
_periods.reset(); // Should I really use reset here to delete existing periods?
_periods = periods(...);
}
Also I have -dealloc implementation
- (void)dealloc;
{
_periods.reset(); // Should I reset shared pointer in dealloc?
// other class-specific routines
}
Is my code correct in terms of shared_ptr memory management? I am quite new to C++
Related
I am a beginner to programming and I am trying to find a way to create a dynamic storage of objects of my pigeon class. Here is my code:
class pigeon {
public:
pigeon(std::string nameI);
void outputInfo();
private:
std::string name;
};
The idea is that I want to be able to add a new object, have a place to store its information, then be able to add another object, and so on. I have no idea where to start with this or even what data structure to use, I have no experience storing objects.
As it was already pointed out in the comments, you should preferably use a container that handles its resources following the RAII/RDID-idiom ( "Resource Acquisition Is Initialisation" / "Resource Destruction is Deletion") so you don't have to worry about it yourself. This is also a simple way of preventing resource leaks when an exception is thrown.
One of the commonly used containers of the C++ standard library is std::vector<>.
You'd use it like this (just to give you an initial idea, please refer to the documentation for further explanation and examples):
#include <vector>
// ...
{
std::vector<pigeon> pigeons;
pigeons.push_back("Karl"); // add three pigeons
pigeons.push_back("Franz"); // at the end of the
pigeons.push_back("Xaver"); // vector
pigeons[1]; // access "Franz"
for(auto /* maybe const */ &p : pigeons) { // iterate over the vector
// do something with pigeon p
}
} // pigeons goes out of scope, its destructor is called which
// takes care of deallocating the memory used by the vector.
Make vector with pointer of your class:
std::vector<pigeon*> pigeons;
Then allocate new pigeon object and push it into your vector:
pigeon * pig = new pigeon("pigeon");
pigeons.push_back(pig);
Summary:
In the example application below, a shared_ptr is being captured in an Objective-C block. The Objective-C block is being assigned to an ivar of a dynamically created class using the Objective-C runtime API object_setIvarWithStrongDefault. When the Objective-C object is deallocated, the shared_ptr is leaking and the C++ object that it is retaining is not deleted. Why is that?
When object_setIvar is used instead, then the leak is prevented but the ivar points to garbage once the block goes out of scope as object_setIvar assumes an assignment of unsafe_unretained.
I assume this has to do with how Objective-C captures C++ objects, copies blocks and how shared_ptr handles being copied, but I was hoping someone could shed some light on this more than the documentation listed below.
References:
Apple's Blocks and Variables Documentation contains a brief section on C++ objects but it's not entirely clear to me how it affects shared pointers.
LLVM's Documentation on Blocks & C++ Support is a bit more detailed than Apple's...
objc-class.mm contains the implementation for object_setIvarWithStrongDefault
Backstory:
This sample code is extracted from a much larger project and has been significantly reduced to the minimum required to show the issue. The project is an Objective-C macOS application. The application contains several monolithic C++ objects that are glorified key/value stores. Each object is an instance of the same class, but templated on the key type. I want to dynamically create an Objective-C class that contains typed property getters which are backed by the C++ class.
(Yes, this could all be done manually by just writing lots-and-lots of getters myself, but I'd prefer not to. The C++ class has enough information to know the names of the properties and their types, thus I'd like to use some meta-programming techniques to "solve" this.)
Notes:
In an ideal world, I'd just be able to define an iVar on an Objective-C class of the appropriate shared_ptr type but I can't figure out how to do that using the Objective-C runtime APIs.
Given this:
std::shared_ptr<BackingStore<T>> backingStore
How do you use this:
class_addIvar and object_setIvar
Since I couldn't figure that out, I decided to just wrap the shared_ptr into an Objective-C block since blocks are first-class objects and can be passed around where an id is expected.
Sample Application:
(Copy/paste into something like CodeRunner to see output)
#import <Foundation/Foundation.h>
#import <objc/runtime.h>
#import <memory>
typedef NSString* (^stringBlock)();
/**
* StoreBridge
*
* Objective-C class that exposes Objective-C properties
* which are "backed" by a C++ object (Store). The implementations
* for each property on this class are dynamically added.
*/
#interface StoreBridge : NSObject
#property(nonatomic, strong, readonly) NSString *storeName;
#end
#implementation StoreBridge
#dynamic storeName;
- (void)dealloc {
NSLog(#"StoreBridge DEALLOC");
}
#end
/**
* BackingStore
*
* C++ class that for this example just exposes a single,
* hard-coded getter function. In reality this class is
* much larger.
*/
class BackingStore {
public:
BackingStore() {
NSLog(#"BackingStore constructor.");
}
~BackingStore() {
NSLog(#"BackingStore destructor.");
}
NSString *name() const {
return #"Amazon";
}
// Given a shared_ptr to a BackingStore instance, this method
// will dynamically create a new Objective-C class. The new
// class will contain Objective-C properties that are backed
// by the given BackingStore.
//
// Much of this code is hard-coded for this example. In reality,
// a much larger number of properties are dynamically created
// with different return types and a new class pair is
// only created if necessary.
static id makeBridge(std::shared_ptr<BackingStore> storePtr) {
// For this example, just create a new class pair each time.
NSString *klassName = NSUUID.UUID.UUIDString;
Class klass = objc_allocateClassPair(StoreBridge.class, klassName.UTF8String, 0);
// For this example, use hard-coded values and a single iVar definition. The
// iVar will store an Objective-C block as an 'id'.
size_t ivarSize = sizeof(id);
NSString *ivarName = #"_storeNameIvar";
NSString *encoding = [NSString stringWithFormat:#"%s#", #encode(id)];
SEL selector = #selector(storeName);
// Implementation for #property.storeName on StoreBridge. This
// implementation will read the block stored in the instances
// iVar named "_storeNameIvar" and call it. Fixed casting to
// type 'stringBlock' is used for this example only.
IMP implementation = imp_implementationWithBlock((id) ^id(id _self) {
Ivar iv = class_getInstanceVariable([_self class], ivarName.UTF8String);
id obj = object_getIvar(_self, iv);
return ((stringBlock)obj)();
});
// Add iVar definition and property implementation to newly created class pair.
class_addIvar(klass, ivarName.UTF8String, ivarSize, rint(log2(ivarSize)), #encode(id));
class_addMethod(klass, selector, implementation, encoding.UTF8String);
objc_registerClassPair(klass);
// Create instance of the newly defined class.
id bridge = [[klass alloc] init];
// Capture storePtr in an Objective-C block. This is the block that
// will be stored in the instance's iVar. Each bridge instance has
// its own backingStore, therefore the storePtr must be set on the
// instance's iVar and not captured in the implementation above.
id block = ^NSString* { return storePtr->name(); };
Ivar iva = class_getInstanceVariable(klass, ivarName.UTF8String);
// Assign block to previously declared iVar. When the strongDefault
// method is used, the shared_ptr will leak and the BackingStore
// will never get deallocated. When object_setIvar() is used,
// the BackingStore will get deallocated but crashes at
// runtime as 'block' is not retained anywhere.
//
// The documentation for object_setIvar() says that if 'strong'
// or 'weak' is not used, then 'unretained' is used. It might
// "work" in this example, but in a larger program it crashes
// as 'block' goes out of scope.
#define USE_STRONG_SETTER 1
#if USE_STRONG_SETTER
object_setIvarWithStrongDefault(bridge, iva, block);
#else
object_setIvar(bridge, iva, block);
#endif
return bridge;
}
};
int main(int argc, char *argv[]) {
#autoreleasepool {
std::shared_ptr<BackingStore> storePtr = std::make_shared<BackingStore>();
StoreBridge *bridge = BackingStore::makeBridge(storePtr);
NSLog(#"bridge.storeName: %#", bridge.storeName);
// When USE_STRONG_SETTER is 1, output is:
//
// > BackingStore constructor.
// > bridge.storeName: Amazon
// > StoreBridge DEALLOC
// When USE_STRONG_SETTER is 0, output is:
//
// > BackingStore constructor.
// > bridge.storeName: Amazon
// > BackingStore destructor.
// > StoreBridge DEALLOC
}
}
Let's jump in a time machine real quick, C.A. 2010. It's a simpler time, before having to deal with multi-architecture slices, 64 bits, and other fancy things, like importantly ARC.
In this seemingly distant world to today, when you had memory, you had to release it yourself gasp. This meant, that if you had an iVar on your class, you had to explicitly, inside dealloc call release on it.
Well, this doesn't actually change with ARC. The only thing that changes is that the compiler generates all of those nice release calls for you inside of dealloc, even if you don't define the method. How nice.
The problem here, however, is that the compiler doesn't actually know about your iVar containing the block - it's completely defined at runtime. So how could the compiler release the memory?
The answer is it doesn't. You'll need to do some magic to make sure that you release this stuff at run-time. My suggestion would be to iterate over the iVars of the class, and set them to nil, rather than call objc_release directly (as it causes much weeping and gnashing of teeth if you're using ARC).
Something like this:
for (ivar in class) {
if ivar_type == #encode(id) {
objc_setIvar(self, ivar, nil)
}
}
Now, if you ever go in and add an intentionally __unsafe_unretained ivar to this class you'll possibly have more issues. But you really shouldn't be inheriting from classes like this, mmkay?
I have a point cloud defined as pcl::PointCloud<pcl::PointXYZI> cloud_xyzi_;. Sometime later, I read in data from a file and push it back into this point cloud; everything works fine. My task however requires me to filter the point cloud, and the filtering methods require pointers.
Can I simply replace my above declaration with something like this pcl::PointCloud<pcl::PointXYZI>::Ptr cloud_xyzi_p;, initialise it in the constructor of the class and then have a pointer on its own, rather than creating a pointer just to pass it to a function? Of course change the . to -> when I use it otherwise. I ask this because I am getting unexpected behaviour when trying to implement this.
Here is my abridged class, with the current code which seems both redundant and not working great.
class P400toPointcloud {
public:
P400toPointcloud():
callback_counter_(0),
sensor_model_created_(false)
{
// Setup pointers for later use
cloud_xyzi_p = cloud_xyzi_.makeShared();
cloud_xyzi_fp = cloud_xyzi_f.makeShared();
}
~P400toPointcloud()
{
}
private:
pcl::PointCloud<pcl::PointXYZI> cloud_xyzi_;
pcl::PointCloud<pcl::PointXYZI> cloud_xyzi_f;
pcl::PointCloud<pcl::PointXYZI>::Ptr cloud_xyzi_p;
pcl::PointCloud<pcl::PointXYZI>::Ptr cloud_xyzi_fp;
std::vector<unsigned int> value_idx_;
};
The code that you have in the constructor have a different effect from what you probably expect:
// Setup pointers for later use
cloud_xyzi_p = cloud_xyzi_.makeShared();
cloud_xyzi_fp = cloud_xyzi_f.makeShared();
The call to makeShared() allocates memory for a new point cloud, copies the contents of the old one inside, wraps the pointer to the new cloud into boost::shared_ptr and returns. Effectively, you get a completely independent copy that can be used in functions that accept pointers. Any modifications done to it will not affect the original cloud.
Since you know you will need to work with the point cloud via its pointer, you should just have a pcl::PointCloud<pcl::PointXYZI>::Ptr. But don't forget to allocate memory for it in the constructor:
class P400toPointcloud {
public:
P400toPointcloud():
callback_counter_(0),
sensor_model_created_(false),
cloud_xyzi_(new pcl::PointCloud<pcl::PointXYZI>),
cloud_xyzi_f(new pcl::PointCloud<pcl::PointXYZI>)
{
// From now on you pass
// cloud_xyzi_ to functions that expect pointer to a point cloud
// *cloud_xyzi_ to functions that expect (raw) point cloud
}
~P400toPointcloud()
{
}
private:
pcl::PointCloud<pcl::PointXYZI>::Ptr cloud_xyzi_;
pcl::PointCloud<pcl::PointXYZI>::Ptr cloud_xyzi_f;
std::vector<unsigned int> value_idx_;
};
I'm not quite sure that I need an object pool, yet it seems the most viable solution, but has some un-wanted cons associated with it. I am making a game, where entities are stored within an object pool. These entities are not allocated directly with new, instead a std::deque handles the memory for them.
This is what my object pool more or less looks like:
struct Pool
{
Pool()
: _pool(DEFAULT_SIZE)
{}
Entity* create()
{
if(!_destroyedEntitiesIndicies.empty())
{
_nextIndex = _destroyedEntitiesIndicies.front();
_destroyedEntitiesIndicies.pop();
}
Entity* entity = &_pool[_nextIndex];
entity->id = _nextIndex;
return entity;
}
void destroy(Entity* x)
{
_destroyedEntitiesIndicies.emplace(x->id);
x->id = 0;
}
private:
std::deque<Entity> _pool;
std::queue<int> _destroyedEntitiesIndicies;
int _nextIndex = 0;
};
If I destroy an entity, it's ID will be added to the _destroyedEntitiesIndicies queue, which will make it so that the ID will be re-used, and lastly it's ID will be set to 0. Now the only pitfall to this is, if I destroy an entity and then immediately create a new one, the Entity that was previously destroyed will be updated to be the same entity that was just created.
i.e.
Entity* object1 = pool.create(); // create an object
pool.destroy(object1); // destroy it
Entity* object2 = pool.create(); // create another object
// now object1 will be the same as object2
std::cout << (object1 == object2) << '\n'; // this will print out 1
This doesn't seem right to me. How do I avoid this? Obviously the above will probably not happen (as I'll delay object destruction until the next frame). But this may cause some disturbance whilst saving entity states to a file, or something along those lines.
EDIT:
Let's say I did NULL entities to destroy them. What if I was able to get an Entity from the pool, or store a copy of a pointer to the actual entity? How would I NULL all the other duplicate entities when destroyed?
i.e.
Pool pool;
Entity* entity = pool.create();
Entity* theSameEntity = pool.get(entity->getId());
pool.destroy(entity);
// now entity == nullptr, but theSameEntity still points to the original entity
If you want an Entity instance only to be reachable via create, you will have to hide the get function (which did not exist in your original code anyway :) ).
I think adding this kind of security to your game is quite a bit of an overkill but if you really need a mechanism to control access to certain parts in memory, I would consider returning something like a handle or a weak pointer instead of a raw pointer. This weak pointer would contain an index on a vector/map (that you store somewhere unreachable to anything but that weak pointer), which in turn contains the actual Entity pointer, and a small hash value indicating whether the weak pointer is still valid or not.
Here's a bit of code so you see what I mean:
struct WeakEntityPtr; // Forward declaration.
struct WeakRefIndex { unsigned int m_index; unsigned int m_hash; }; // Small helper struct.
class Entity {
friend struct WeakEntityPtr;
private:
static std::vector< Entity* > s_weakTable( 100 );
static std::vector< char > s_hashTable( 100 );
static WeakRefIndex findFreeWeakRefIndex(); // find next free index and change the hash value in the hashTable at that index
struct WeakEntityPtr {
private:
WeakRefIndex m_refIndex;
public:
inline Entity* get() {
Entity* result = nullptr;
// Check if the weak pointer is still valid by comparing the hash values.
if ( m_refIndex.m_hash == Entity::s_hashTable[ m_refIndex.m_index ] )
{
result = WeakReferenced< T >::s_weakTable[ m_refIndex.m_index ];
}
return result;
}
}
This is not a complete example though (you will have to take care of proper (copy) constructors, assignment operations etc etc...) but it should give you the idea what I am talking about.
However, I want to stress that I still think a simple pool is sufficient for what you are trying to do in that context. You will have to make the rest of your code to play nicely with the entities so they don't reuse objects that they're not supposed to reuse, but I think that is easier done and can be maintained more clearly than the whole handle/weak pointer story above.
This question seems to have various parts. Let's see:
(...) If I destroy an entity and then immediately create a new one,
the Entity that was previously destroyed will be updated to be the
same entity that was just created. This doesn't seem right to me. How
do I avoid this?
You could modify this method:
void destroy(Entity* x)
{
_destroyedEntitiesIndicies.emplace(x->id);
x->id = 0;
}
To be:
void destroy(Entity *&x)
{
_destroyedEntitiesIndicies.emplace(x->id);
x->id = 0;
x = NULL;
}
This way, you will avoid the specific problem you are experiencing. However, it won't solve the whole problem, you can always have copies which are not going to be updated to NULL.
Another way is yo use auto_ptr<> (in C++'98, unique_ptr<> in C++-11), which guarantee that their inner pointer will be set to NULL when released. If you combine this with the overloading of operators new and delete in your Entity class (see below), you can have a quite powerful mechanism. There are some variations, such as shared_ptr<>, in the new version of the standard, C++-11, which can be also useful to you. Your specific example:
auto_ptr<Entity> object1( new Entity ); // calls pool.create()
object1.release(); // calls pool.destroy, if needed
auto_ptr<Entity> object2( new Entity ); // create another object
// now object1 will NOT be the same as object2
std::cout << (object1.get() == object2.get()) << '\n'; // this will print out 0
You have various possible sources of information, such as the cplusplus.com, wikipedia, and a very interesting article from Herb Shutter.
Alternatives to an Object Pool?
Object pools are created in order to avoid continuous memory manipulation, which is expensive, in those situations in which the maximum number of objects is known. There are not alternatives to an object pool that I can think of for your case, I think you are trying the correct design. However, If you have a lot of creations and destructions, maybe the best approach is not an object pool. It is impossible to say without experimenting, and measuring times.
About the implementation, there are various options.
In the first place, it is not clear whether you're experiencing performance advantages by avoiding memory allocation, since you are using _destroyedEntitiesIndicies (you are anyway potentially allocating memory each time you destroy an object). You'll have to experiment with your code if this is giving you enough performance gain in contrast to plain allocation. You can try to remove _destroyedEntitiesIndicies altogether, and try to find an empty slot only when you are running out of them (_nextIndice >= DEFAULT_SIZE ). Another thing to try is discard the memory wasted in those free slots and allocate another chunk (DEFAULT_SIZE) instead.
Again, it all depends of the real use you are experiencing. The only way to find out is experimenting and measuring.
Finally, remember that you can modify class Entity in order to transparently support the object pool or not. A benefit of this is that you can experiment whether it is a really better approach or not.
class Entity {
public:
// more things...
void * operator new(size_t size)
{
return pool.create();
}
void operator delete(void * entity)
{
}
private:
Pool pool;
};
Hope this helps.
Is there a way to manually increment and decrement the count of a shared_ptr in C++?
The problem that I am trying to solve is as follows. I am writing a library in C++ but the interface has to be in pure C. Internally, I would like to use shared_ptr to simplify memory management while preserving the ability to pass a raw pointer through the C interface.
When I pass a raw pointer through the interface, I would like to increment the reference count. The client will then be responsible to call a function that will decrement the reference count when it no longer needs the passed object.
Maybe you are using boost::shared_ptr accross DLL boundaries, what won't work properly. In this case boost::intrusive_ptr might help you out. This is a common case of misuse of shared_ptr people try to work around with dirty hacks... Maybe I am wrong in your case but there should be no good reason to do what you try to do ;-)
ADDED 07/2010: The issues seem to come more from DLL loading/unloading than from the shared_ptr itself. Even the boost rationale doesn't tell much about the cases when boost::intrusive_ptr should be preferred over shared_ptr. I switched to .NET development and didn't follow the details of TR1 regarding this topic, so beware this answer might not be valid anymore now...
In your suggestion
The client will then be responsible to decrement the counter.
means that the client in question is responsible for memory management, and that your trust her. I still do not understand why.
It is not possible to actually modify the shared_ptr counter... (hum, I'll explain at the end how to...) but there are other solutions.
Solution 1: complete ownership to the client
Hand over the pointer to the client (shared_ptr::release) and expect it to pass the ownership back to you when calling back (or simply deleting the object if it is not really shared).
That's actually the traditional approach when dealing with raw pointers and it apply here as well. The downside is that you actually release ownership for this shared_ptr only. If the object is actually shared that might prove inconvenient... so bear with me.
Solution 2: with a callback
This solution means that you always keep ownership and are responsible to maintain this object alive (and kicking) for as long as the client needs it. When the client is done with the object, you expect her to tell you so and invoke a callback in your code that will perform the necessary cleanup.
struct Object;
class Pool // may be a singleton, may be synchronized for multi-thread usage
{
public:
int accept(boost::shared_ptr<Object>); // adds ptr to the map, returns NEW id
void release(int id) { m_objects.erase(id); }
private:
std::map< int, boost::shared_ptr<Object> > m_objects;
}; // class Pool
This way, your client 'decrementing' the counter is actually your client calling a callback method with the id you used, and you deleting one shared_ptr :)
Hacking boost::shared_ptr
As I said it is possible (since we are in C++) to actually hack into the shared_ptr. There are even several ways to do it.
The best way (and easiest) is simply to copy the file down under another name (my_shared_ptr ?) and then:
change the include guards
include the real shared_ptr at the beginning
rename any instance of shared_ptr with your own name (and change the private to public to access the attributes)
remove all the stuff that is already defined in the real file to avoid clashes
This way you easily obtain a shared_ptr of your own, for which you can access the count. It does not solve the problem of having the C code directly accessing the counter though, you may have to 'simplify' the code here to replace it by a built-in (which works if you are not multi-threaded, and is downright disastrous if you are).
I purposely left out the 'reinterpret_cast' trick and the pointer offsets ones. There are just so many ways to gain illegit access to something in C/C++!
May I advise you NOT to use the hacks though? The two solutions I presented above should be enough to tackle your problem.
You should do separation of concerns here: if the client passes in a raw pointer, the client will be responsible for memory management (i.e. clean up afterwards). If you create the pointers, you will be responsible for memory management. This will also help you with the DLL boundary issues that were mentioned in another answer.
1. A handle?
If you want maximum security, gives the user a handle, not the pointer. This way, there's no way he will try to free it and half-succeed.
I'll assume below that, for simplicity's sake, you'll give the user the object pointer.
2. acquire and unacquire ?
You should create a manager class, as described by Matthieu M. in his answer, to memorize what was acquired/unacquired by the user.
As the inferface is C, you can't expect him to use delete or whatever. So, a header like:
#ifndef MY_STRUCT_H
#define MY_STRUCT_H
#ifdef __cplusplus
extern "C"
{
#endif // __cplusplus
typedef struct MyStructDef{} MyStruct ; // dummy declaration, to help
// the compiler not mix types
MyStruct * MyStruct_new() ;
size_t MyStruct_getSomeValue(MyStruct * p) ;
void MyStruct_delete(MyStruct * p) ;
#ifdef __cplusplus
}
#endif // __cplusplus
#endif // MY_STRUCT_H
Will enable the user to use your class. I used a declaration of a dummy struct because I want to help the C user by not imposing him the use of the generic void * pointer. But using void * is still a good thing.
The C++ source implementing the feature would be:
#include "MyClass.hpp"
#include "MyStruct.h"
MyManager g_oManager ; // object managing the shared instances
// of your class
extern "C"
{
MyStruct * MyStruct_new()
{
MyClass * pMyClass = g_oManager.createMyClass() ;
MyStruct * pMyStruct = reinterpret_cast<MyStruct *>(pMyClass) ;
return pMyStruct ;
}
size_t MyStruct_getSomeValue(MyStruct * p)
{
MyClass * pMyClass = reinterpret_cast<MyClass *>(p) ;
if(g_oManager.isMyClassExisting(pMyClass))
{
return pMyClass->getSomeValue() ;
}
else
{
// Oops... the user made a mistake
// Handle it the way you want...
}
return 0 ;
}
void MyStruct_delete(MyStruct * p)
{
MyClass * pMyClass = reinterpret_cast<MyClass *>(p) ;
g_oManager.destroyMyClass(pMyClass) ;
}
}
Note that the pointer to MyStruct is plain invalid. You should not use it for whatever reason without reinterpret_cast-ing it into its original MyClass type (see Jaif's answer for more info on that. The C user will use it only with the associated MyStruct_* functions.
Note too that this code verify the class does exist. This could be overkill, but it is a possible use of a manager (see below)
3. About the manager
The manager will hold, as suggested by Matthieu M., a map containing the shared pointer as a value (and the pointer itself, or the handle, as the key). Or a multimap, if it is possible for the user to somehow acquire the same object multiple times.
The good thing about the use of a manager will be that your C++ code will be able to trace which objects were not "unacquired" correctly by the user (adding info in the acquire/unacquire methods like __FILE__ and __LINE__ could help narrow the bug search).
Thus the manager will be able to:
NOT free a non-existing object (how did the C user managed to acquire one, by the way ?)
KNOW at the end of execution which objects were not unaquired
In case of unacquired objets, destroy them anyway (which is good from a RAII viewpoint)
This is somewhat evil, but you could offer this
As shown in the code above, it could even help detect a pointer does not point to a valid class
I came across a use case where I did need something like this, related to IOCompletionPorts and concurrency concerns. The hacky but standards compliant method is to lawyer it as described by Herb Sutter here.
The following code snippet is for std::shared_ptr as implemented by VC11:
Impl File:
namespace {
struct HackClass {
std::_Ref_count_base *_extracted;
};
}
template<>
template<>
void std::_Ptr_base<[YourType]>::_Reset<HackClass>(std::auto_ptr<HackClass> &&h) {
h->_extracted = _Rep; // Reference counter pointer
}
std::_Ref_count_base *get_ref_counter(const std::shared_ptr<[YourType]> &p) {
HackClass hck;
std::auto_ptr<HackClass> aHck(&hck);
const_cast<std::shared_ptr<[YourType]>&>(p)._Reset(std::move(aHck));
auto ret = hck._extracted; // The ref counter for the shared pointer
// passed in to the function
aHck.release(); // We don't want the auto_ptr to call delete because
// the pointer that it is owning was initialized on the stack
return ret;
}
void increment_shared_count(std::shared_ptr<[YourType]> &sp) {
get_ref_counter(sp)->_Incref();
}
void decrement_shared_count(std::shared_ptr<[YourType]> &sp) {
get_ref_counter(sp)->_Decref();
}
Replace [YourType] with the type of object you need to modify the count on. It is important to note that this is pretty hacky, and uses platform specific object names. The amount of work you have to go through to get this functionality is probably indicative of how bad of an idea it is. Also, I am playing games with the auto_ptr because the function I am hijacking from shared_ptr takes in an auto_ptr.
Another option would be to just allocate dynamically a copy of the shared_ptr, in order to increment the refcount, and deallocate it in order to decrement it. This guarantees that my shared object will not be destroyed while in use by the C api client.
In the following code snippet, I use increment() and decrement() in order to control a shared_ptr. For the simplicity of this example, I store the initial shared_ptr in a global variable.
#include <iostream>
#include <boost/shared_ptr.hpp>
#include <boost/make_shared.hpp>
#include <boost/scoped_ptr.hpp>
using namespace std;
typedef boost::shared_ptr<int> MySharedPtr;
MySharedPtr ptr = boost::make_shared<int>(123);
void* increment()
{
// copy constructor called
return new MySharedPtr(ptr);
}
void decrement( void* x)
{
boost::scoped_ptr< MySharedPtr > myPtr( reinterpret_cast< MySharedPtr* >(x) );
}
int main()
{
cout << ptr.use_count() << endl;
void* x = increment();
cout << ptr.use_count() << endl;
decrement(x);
cout << ptr.use_count() << endl;
return 0;
}
Output:
1
2
1
fastest possible concurrent lockless manager (if you know what you are doing).
template< class T >
class shared_pool
{
public:
typedef T value_type;
typedef shared_ptr< value_type > value_ptr;
typedef value_ptr* lock_handle;
shared_pool( size_t maxSize ):
_poolStore( maxSize )
{}
// returns nullptr if there is no place in vector, which cannot be resized without locking due to concurrency
lock_handle try_acquire( const value_ptr& lockPtr ) {
static value_ptr nullPtr( nullptr );
for( auto& poolItem: _poolStore ) {
if( std::atomic_compare_exchange_strong( &poolItem, &nullPtr, lockPtr ) ) {
return &poolItem;
}
}
return nullptr;
}
lock_handle acquire( const value_ptr& lockPtr ) {
lock_handle outID;
while( ( outID = try_acquire( lockPtr ) ) == nullptr ) {
mt::sheduler::yield_passive(); // ::SleepEx( 1, false );
}
return outID;
}
value_ptr release( const lock_handle& lockID ) {
value_ptr lockPtr( nullptr );
std::swap( *lockID, lockPtr);
return lockPtr;
}
protected:
vector< value_ptr > _poolStore;
};
std::map is not so fast, requires additional search, extra memory, spin-locking.
But it grants extra safety with handles approach.
BTW, hack with manual release/acquire seems to be a much better approach (in terms of speed and memory usage). C++ std better add such a functionality in their classes, just to keep C++ razor-shaped.