Jump to content
  • Advertisement
Sign in to follow this  
HexDump

boost::shared_ptr suitable for iphone games?

This topic is 2538 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

>> 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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Thank for the answers.

@Promit: I have tried intrusive_pr, but I don' like it not being possible to use weak_ptr with it.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Hi,



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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!