Hi!,
I would like to use boost::shared_ptr in a iphone game I'm developing. I know this type of shared pointers have some caveats like heap allocation, have to inherit rom make_shared_for_:this to be able to pass this pointers, etc... I mean, a bunch of things I have no control over.
Do you think it is a good option for consoles/movil developmen with not a bunch of ram and little processing power?.
Thanks in advance.
boost::shared_ptr suitable for iphone games?
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
You are fine to use any of the boost smart pointers, including shared_ptr. The overhead involved is so tiny it almost doesn't even exist.
>> Do you mean it is a good option for consoles/movil developmen with not a bunch of ram and little processing power?.
[/font]You are fine to use any of the boost smart pointers, including shared_ptr. The overhead involved is so tiny it almost doesn't even exist.
shared_ptr pool allocates its data, IIRC, so the overhead is not really all that high. If you are concerned, feel free to use intrusive_ptr instead. Overall I don't have any concerns about using shared_ptr in my code and I've had no problems so far with it. There are waaaay bigger issues to deal with, like the entire render pipeline.
Author
Thank for the answers.
@Promit: I have tried intrusive_pr, but I don' like it not being possible to use weak_ptr with it.
@Promit: I have tried intrusive_pr, but I don' like it not being possible to use weak_ptr with it.
Overhead doesn't exist in a vacuum. You must have something to compare it with. The overhead compared to doing nothing is good, as doing nothing results in memory leaks that will make your program slower and slower over time.
That is assuming this is even a bottleneck. Shared objects generally do not have short lifetimes, so provided you are careful not to force the shared_ptr to do additional work (needless reference counting) it should be fine (e.g. instead of passing shared_ptr<Foo> to functions, pass a const reference to Foo).
That is assuming this is even a bottleneck. Shared objects generally do not have short lifetimes, so provided you are careful not to force the shared_ptr to do additional work (needless reference counting) it should be fine (e.g. instead of passing shared_ptr<Foo> to functions, pass a const reference to Foo).
Author
Hi,
Doesn't is it a bit ugly to pass raw pointers around when you are using shared_ptr to hide them from the naive user?. Wait, you meant references. Something like:
did you meant something like this?
That is assuming this is even a bottleneck. Shared objects generally do not have short lifetimes, so provided you are careful not to force the shared_ptr to do additional work (needless reference counting) it should be fine (e.g. instead of passing shared_ptr<Foo> to functions, pass a const reference to Foo).
Doesn't is it a bit ugly to pass raw pointers around when you are using shared_ptr to hide them from the naive user?. Wait, you meant references. Something like:
void myFuncion( const MyType& a)
{
....
}
boost::shared_ptr<MyType> instance= boost::shared_ptr<MyType> (new MyType);
myFuncion(*instance);
did you meant something like this?
As far as I know, Objective-C's reference counting scheme is intrusive, but shared_ptr allocates from the heap. Considering that c++ objects are potentially MUCH faster than their Objective-C ounterparts, I wouldn't worry about the overhead of storing the reference count separate from the object.
I think std::make_shared allocates the reference count in the same memory block as the object.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
