I am interested in common practice/implementation of a pattern which I would call "scoped procedure". I even don't know how to name it correctly :)
The thing I am talking about is close to boost::scoped_exit and boost::scoped_connection: a class, which
holds user-provided functor,
shares the functor on object copying,
have a counter to count all objects sharing given functor,
calls the fuctor when the counter becomes 0.
The candidate I can think about is boost::shared_ptr, but it seems to me a bit awkward to store there some fake pointer.
Can you give any suggestion/best practice for this?
The case I want to apply it to is as follows. There is some registry class which stores a collection of records for associated objects of some other class. When an object is "registered" in the collection it receives a registration ID. When the object wants to unregister it just "releases the ID" (by going out of scope or calling a method similar to boost::scoped_connection::disconnect()). On release a user-provided procedure would be called to remove a corresponding record from the collection.
Thank you in advance!
Related
The question is strictly about std::function and not boost::function. See the Update section at the bottom of this question for more details, especially the part about it not being possible to compare non-empty std::function objects per the C++11 standard.
The C++11 std::function class template is great for maintaining a collection of callbacks. One can store them in a vector, for example and invoke them when need be. However, maintaining these objects and allowing for unregistration seems to be impossible.
Let me be specific, imagine this class:
class Invoker
{
public:
void Register(std::function<void()> f);
void Unregister(std::function<void()> f);
void InvokeAll();
private:
// Some container that holds the function objects passed to Register()
};
Sample usage scenario:
void foo()
{
}
int main()
{
std::function<void()> f1{foo};
std::function<void()> f2{[] {std::cout << "Hello\n";} };
Invoker inv;
// The easy part
// Register callbacks
inv.Register(f1);
inv.Register(f2);
// Invoke them
inv.InvokeAll();
// The seemingly impossible part. How can Unregister() be implemented to actually
// locate the correct object to unregister (i.e., remove from its container)?
inv.Unregister(f2);
inv.Unregister(f1);
}
It is fairly clear how the Register() function can be implemented. However, how would one go about implementing Unregister(). Let's say that the container that holds the function objects is vector<std::function<void()>> . How would you find a particular function object that is passed to the Unregister() call? std::function does supply an overloaded operator==, but that only tests for an empty function object (i.e., it cannot be used to compare two non-empty function objects to see if they both refer to the same actual invocation).
I would appreciate any ideas.
Update:
Ideas so far mainly consist of the addition of a cookie to be associated with each std::function object that can be used to unregister it. I was hoping for something that is not exogenous to the std::function object itself. Also, there seems to be much confusion between std::function and boost::function. The question is strictly about std::function objects, and not boost::function objects.
Also, you cannot compare two non-empty std::function objects for equality. They will always compare non-equal per the standard. So, links in the comments to solutions that do just that (and use boost::function objects to boot) are patently wrong in the context of this question.
Since you can't test for element identity in the container, it's probably best to use a container (such as std::list) whose iterators do not invalidate when the container is modified, and return iterators back to registering callers that can be used to unregister.
If you really want to use vector (or deque), you could return the integral index into the vector/deque when the callback is added. This strategy would naturally require you to make sure indexes are usable in this fashion to identify the function's position in the sequence. If callbacks and/or unregistration is rare, this could simply mean not reusing spots. Or, you could implement a free list to reuse empty slots. Or, only reclaim empty slots from the ends of the sequence and maintain a base index offset that is increased when slots are reclaimed off the beginning.
If your callback access pattern doesn't require random access traversal, storing the callbacks in a std::list and using raw iterators to unregister seems simplest to me.
I have an idea for this.
Store the callbacks as std::weak_ptr<std::function<void(argtype1, argtype1)>>. Then the caller is responsible for keeping the corresponding std::shared_ptr alive, and all the caller has to do to unregister the callback is destroy all active std::shared_ptrs to the callback function.
When invoking callbacks, the code has to be careful to check for lock failures on the std::weak_ptr<>s it is using. When it runs across these it can remove them from its container of registered callbacks.
Note that this does not give complete thread safety, as the callback invoker can lock the std::weak_ptr and make a temporarily newly active std::shared_ptr of the callback function that can stay alive after the caller's std::shared_ptr goes out of scope.
I have an Entity class defined by a lib, and Registry which is class that manages Entities registered to it with a map.
What i'm trying to do:
//Registry Signature
void Registry::add(Entity* entity);
//my function (IGameEntity subclasses Entity)
void GameLogic::addEntity(shared_ptr<IGameEntity> entity, GameEntityId id) {
GameEntityId entityId = entity->getId();
gameEntities.push_back(entity);
Framework::Registry::instance()->add(entity); //<-- this doesn't work
}
I'm trying to figure how to handle this, since i'm keeping shared_ptr's and then i'm gonna have to pass a pointer.
Another thing is that if the registry gets destroyed by some reason it will call delete on all entities remaining in the map.
If i pass entity has weak_ptr<Entity>(entity) it works but i'm not fully grasping whats going on in terms of what will happen if Registry calls delete on a weak_ptr.
And if i pass entity has entity.get() what will happen when the reference count reaches zero or the registry tries to delete it.
You have two incompatible ownership schemes.
You need to either change one of them, or clone the object that should be transferred from one scheme to the other.
There is a trick for releasing a shared_ptr when there is only one reference to the object. But you don't want to do that. Even if you know enough about the insides of the library to do it.
So, as a practical solution, change the registry thing.
Make it take a shared_ptr.
I will describe the problem as simple as i can.
alright, here goes the problem;
Lets suppose we have a com component class with 3 of constructors where a constructor takes at least two of parameters. As we already know we instantiate the components via QueryInterface rather calling the classes' constructors therefore it seems it is not possible for a com client to set the constructor's parameters.
alright, here goes the question;
What is the best practical approach to allow a com client to instantiate a com component which requires at least two of parameters to be initialized?
Instead of directly returning object instances, your QueryInterface call can return factories. For example, instead of:
// implements IMyClass1 interface
return new MyClass1();
You would do:
// pointer to member that implements IMyClassFactory interface
return &m_myClassFactory;
// this could also be a static class instead of an object instance
The IMyClassFactory interface would have a create method that takes in the constructor arguments and returns the ultimate MyClass1 instance.
If its a pure COM component, the standard way of handling this is to implement Initialize(foo, bar) methods instead of separate constuctors and then call that immediately after COM instantiation. If the object has no sensible default state, then you can make it a member variable (pointer) in a COM object. From that COM object you will have your Initialize(foo, bar) functions. In each of these initialize function the correct version of your object will be instantiated. Every pass through function in your COM wrapper will need to check that your object is not NULL and return an appropriate HRESULT if it is.
One option would be to use a factory object; the creation functions would be all on the (stateless) factory object (on a different interface, of course), and pass back an initialized instance of the real object.
When I write COM servers, I don't usually allow my components to be instantiated by CoCreateInstance. Instead I export some bare functions (these can be described in IDL as well inside a module) from my DLL which accept the constructor parameters and return an interface pointer to the newly created object in an output parameter.
I like both Ates Goral's answer and Steve's and have upvoted both. Normally I would leave it at that, but I feel that this time I have to spell out my full take.
The "best", "right", "purest", "canonical" way to do this is undoubtely the factory pattern, as described by Ates. If you want to create a clean API, that's the road, hands down.
But... most of us are not busy creating public APIs for commercial products. For small internal projects with non-public APIs, I just want to get the job done. Having to implement an extra object just so I can expose a single factory method sounds rather overkill (particularly in C++). In most practical cases, I would just go for an Initialize(foo, bar) method as described by Steve. I would then make sure that every non-trivial method checks to see if the object has been initialized and returns a failure HRESULT if not.
I am developing a Darwinian evolution simulation. For performance reasons, it's written in C++. The sim is represented by an instance of World. The animals are represented by instances of Animal, a fairly complicated object. World has two important methods:
animal_at(int i)
and
evolve(int n).
animal_at returns a non-null raw pointer to the instance of Animal that represents the i-th animal.
evolve advances the simulation possibly invalidating any pointer returned by animal_at.
I want to make the sim and the animals easily accessible from outside. I have python-specific bindings, but i'm considering learning CORBA or Ice to implement a more generic interface. The problem is how I should expose the animals. I have two ideas, none of which feels satisfactory:
1) Rewrite the code slightly to use shared_ptr instead of a raw ptr and use a middleware that understands shared_ptr semantics.
2) Generate a "deep lazy proxy" that has the same structure as Animal. Its members would be proxies to members of Animal, recursively. animal_at would be actually called in the last moment before referring to the actual data -- the pointer would be used and immediately tossed away. This would implement the "last moment" semantics.
I dislike 1) because I would have to introduce a "zombie" state of the object, which looks inelegant to me.
I dislike 2) because the sole purpose of the proxy is to implement the "last moment" semantics.
I am looking for an automatic non-intrusive way (using code-generation) to achieve this, because I don't want to obscure the meaning of the original code. Is there any "official" name for what I call "last moment" semantics?
There is an option of using boost::weak_ptr. You can pass these around, they have to use lock() to get the underlying shared_ptr so they can see if the object no longer exists.
The lifetime of the object is determined only by the places where a shared_ptr is held. There must therefore be at least one of these at all times during the lifetime of the object, and you need one before you can create a weak_ptr.
Firstly, you might consider xml-rpc instead of CORBA as middleware (more standard use nowadays).
Secondly, external users work with marshalled data. They send a marshalled reference over the middleware and expect marshalled information based on their request and reference, so I don't see how this works together with "last moment" sementics and pointers. You either keep all your temporary animals, so external users can query them or you probably have to send a lot exceptions for not found animals. (or you let them request the "latest" animal)
If your animal_at function returns a pointer that can be invalidated at any point in the future, you might try having it return a smart pointer (I'd suggest a shared_ptr over a weak_ptr here, but you can get away with the weak pointer if you are careful with the implementation). However, instead of pointing directly to an Animal object, have it point to a boost::optional<Animal> object. That way, when you invalidate the pointer, you can set the invalid flag on the pointer and any user of the newly invalidated object have the ability to check to see if they need to get a new pointer.
I don't get why you want to export a pointer instead of exporting an interface which seems exactly the "last moment" semantics that you want. Your animal_at could return an object id, not a pointer, and the interface would give all the required access to the object, like dosomething(id, params). The interface could also include lock/unlock stuff to enable atomic access.
I need suggestions on how to solve the type of problems described below. I'm fairly new at C++ and OO-design.
I've learnt:
Pointers shall be avoided when ever they can be replaced by references.
Objects shall have no knowledge of objects that they don't need to know about.
But when creating objects having references to other objects we must pass these references as input arguments to the constructor. Thus we need to know about objects we should not not know anything about.
But look at the following example:
Suppose I have a object "Menu" that needs to have it's own timer object "Timer". I'd like to implement this association as a reference.
The object MenuHandler aggregates a lot of Menu objects but shall not have any knowledge about Timer objects. But when the MenuHandler creates a Menu object it must pass a Timer reference argument to the constructor. Thus, ****MenuHandler** must know about **Timer****.
Any suggestions on how to treat these kind of problems?
I'd hesitate to bless your choice of words when it comes to the two numbered points. They're a sign you're on the right way learning C++, but they might be misleading to other novices. When I take a look at your concrete examples, this becomes more obvious.
A MenuHandler should not create menus. The content of menus is determined by by the application, so the application object (or the Controller part, if you've implemented Model-View-Controller) should create menus. The MenuHander merely takes ownership of menus created elsewhere.
Also, it may make sense to give each menu its own timer. That means the relation can be described as "Has a"; the menu has a timer. The relationship usually implmented by references can be described as "Knows a" (the inheritance relationship is usally called "Is a"). If each Menu object has a Timer, it can be a member, and initialized by the Menu constructor(s). The Timer object internally may obtain a reference to the system clock in its constructor, but that's not your concern.
Why not simply make the Timer object a member (by value) of the Menu class?
I find that I produce better (more maintainable, faster, etc) code and that I'm more productive using references in C++ than I would be solving the same problem with pointers... I think the traditional answer to your example would be to have a factory object that creates menus. In this way, the MenuHandler doesn't need to know about the Timer class.
The MenuHandler creates a Timer object, passes it into the Menu constructor, and forgets about it. That seems entirely reasonable.
If the MenuHandler unnecessarily kept a reference to the Timer, that would be against the advice point #2.
In a more general case where you need to provide a class to another class in order to do some kind of callback, you avoid mutual dependency (both know each other) by using an interface.
Class A derives from the interface. Class B accepts the interface as paramater in the constructor and calls the virtual function from that interface when needed.
Also check the observer design pattern.
For #1 Be very careful with the lifetime of your objects. References are no that suitable to handle dynamic graph of objets ( like your menu, menuhandler, timer, etc... ). What if you want to change the timer object later ?
It's not a good idea to have references as members in a class if the lifetime of referenced objects is not really known.
Avoiding pointer does not mean using references everywhere, you should have a look at smart pointers which will be more suitable for what you want to do.