3

After about 10 years of using managed memory and functional languages, I'm finally coming home to C++, and smart pointers are confusing the heck out of me. Half of the documentation out there is still regarding the deprecated auto_ptr.

I'm trying to implement this fairly straightforward Bullet "hello world" program:

int _tmain(int argc, _TCHAR* argv[])
{
    auto bp = unique_ptr<btBroadphaseInterface>(new btDbvtBroadphase);
    auto cc = unique_ptr<btDefaultCollisionConfiguration>(new btDefaultCollisionConfiguration);
    auto disp = unique_ptr<btDispatcher>(new btCollisionDispatcher(cc));
}

The btCollisionDispatcher constructor wants a btCollisionConfiguration*, but I'm giving it a unique_ptr to one instead.

What do I normally want to do in this case? If there's a way to "de-smart" the pointer, something tells me that unique_ptr isn't the right smart pointer to use.

enter image description here

C++ was my language of choice before I moved to other things. It's a little shocking coming back and seeing that all the patterns and practices have completely changed.

Rei Miyasaka
  • 7,007
  • 6
  • 42
  • 69
  • I think the answer depends on `btCollisionDispatcher` does it want to *share* the ownership or will it *take* ownership? If latter - can you not change it to accept the `unique_ptr`? If the former, you'll have to change this to `shared_ptr` and pass that in. – Nim Mar 28 '12 at 13:32
  • `disp` will be holding onto `cc` and using it until it's destructed. It expects that you'll use it elsewhere, like when I call the `btWorld` constructor later on, but it doesn't share the pointer outside of its own scope, as far as I can tell. – Rei Miyasaka Mar 28 '12 at 13:36
  • It may not be related to your question, but as you say you come from a managed langauge background, just be sure not spam smart pointers too much and always consider automatic storage first. Just a small but important advice, that had to be said. – Christian Rau Mar 28 '12 at 13:56
  • 2
    "What do I normally want to do in this case?" [Read `std::unique_ptr`'s documentation](http://en.cppreference.com/w/cpp/memory/unique_ptr). – Nicol Bolas Mar 28 '12 at 18:26
  • The best thing you can do coming from managed languages is forget all about `new`! – ildjarn Mar 28 '12 at 18:43
  • @ildjarn C++ was my language of choice before I moved to other things, so `new` is pretty familiar. It's just the smart pointer stuff that's got me stumped. – Rei Miyasaka Mar 28 '12 at 23:56
  • My larger point was, automatic storage should suffice 90% of the time. :-] – ildjarn Mar 28 '12 at 23:59
  • @ChristianRau when you say automatic storage, do you mean stack allocation? I'm hearing conflicting opinions on whether or not I should use smart pointers everywhere -- the only thing everyone seems to agree on is not to use them in performance-critical tight loops. – Rei Miyasaka Mar 29 '12 at 00:01
  • @ildjarn Hmm okay so if I'm not mistaken, automatic storage is synonymous with stack allocation... wouldn't I be liable to hastening a stack overflow? – Rei Miyasaka Mar 29 '12 at 00:07
  • If you manage to get a stack overflow via using automatic storage (as opposed to e.g. deep recursion), I'd be quite surprised. But in that case, increase your stack size and continue avoiding `new` as much as possible. – ildjarn Mar 29 '12 at 00:10

2 Answers2

14

There is a get() member function that gives you the raw pointer that is held by the unique_ptr. This does not cause the unique_ptr to relinquish the ownership, though, so proper cleanup will still happen (careful with storing that raw pointer!).

There is also a release() member function, which relinquishes ownership. This means that you're back on dumb pointer land and cleanup is all your responsibility.

I can't fathom why the code is using new in the first place and not just using automatic storage objects, but I'm going to pretend there is a reason...

Community
  • 1
  • 1
R. Martinho Fernandes
  • 228,013
  • 71
  • 433
  • 510
3

The get member function returns the underling pointer and is fine to use with existing code as long as that code doesn't manage the memory you pass in.

rerun
  • 25,014
  • 6
  • 48
  • 78