Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualCornstalks

Posted 29 January 2013 - 06:18 PM

It should compile, I would be interested in knowing why it doesnt for you.

Well, the obvious one is that new temp() should be new some_class(). It's also missing a right parenthesis. I can't comment on the bind business, I just checked it with a C++11 compiler and simply passed nullFunc instead of binding anything.

 

As for (properly) using smart pointers, once you get this to compile, it works really nicely for C libraries (with the appropriate deleter func added) without needing to wrap loads of stuff in C++ classes. Though the problem in this thread isnt perhaps the best use-case for it.

That might be a neat trick for cleaning up pointers from C APIs, but I hope you're very clear with documentation if you do that because it's not what people really expect with a shared_ptr. Additionally, you could just wrap the thing up in a proper class or struct and do the freeing in the destructor (which is probably more idiomatic). Anyway, the real problem I have with that snippet is that it's encouraging him to leak memory and completely negating the benefits of shared_ptr. I think that might be a useful trick (and thanks for this explanatory paragraph), but you're last sentence is the key. The "job" discussed in this thread requires a hammer, not a screw driver smile.png Telling someone to use a screw driver to nail something in (even if you have good intentions) is just... yeah...


#1Cornstalks

Posted 29 January 2013 - 06:17 PM

It should compile, I would be interested in knowing why it doesnt for you.

Well, the obvious one is that new temp() should be new some_class(). It's also missing a right parenthesis. I can't comment on the bind business, I just checked it with a C++11 compiler and simply passed nullFunc instead of binding anything.

 

As for (properly) using smart pointers, once you get this to compile, it works really nicely for C libraries (with the appropriate deleter func added) without needing to wrap loads of stuff in C++ classes. Though the problem in this thread isnt perhaps the best use-case for it.

That might be a neat trick for cleaning up pointers from C APIs, but I hope you're very clear with documentation if you do that because it's not what people really expect with a shared_ptr. Additionally, you could just wrap the thing up in a proper class or struct and do the freeing in the destructor (which is probably more idiomatic). Anyway, the real problem I have with that snippet is that it's encouraging him to leak memory and completely negating the benefits of shared_ptr. I think that might be a useful trick (and thanks for this explanatory paragraph), but you're last sentence is the key. The "job" discussed in this thread requires a hammer, not a screw driver smile.png


PARTNERS