3

The project that I'm currently working on uses an older compiler that does not support C++11, so no unique_ptr or shared_ptr is available.

Should I use the now deprecated auto_ptr instead or should I just drop using smart pointers altogether?

Q-bertsuit
  • 3,223
  • 6
  • 30
  • 55
  • 1
    If you decide to use `std::auto_ptr` make sure you understand why the issues with it. One example: http://www.gotw.ca/gotw/042.htm – Richard Critten Sep 28 '18 at 10:28
  • 1
    i would still use auto_ptrs instead, if the system is already using it. – Yucel_K Sep 28 '18 at 10:28
  • Take a look at [this](https://stackoverflow.com/questions/4554162/is-there-any-reason-to-use-auto-ptr) – user3738870 Sep 28 '18 at 10:30
  • 1
    You can still use RAII techniques to manage memory, and follow good practices like "a class should either own exactly one resource, xor perform some functionality". `auto_ptr` will work, just be extra careful and understand its limitations. There isn't really a way to create a good "single owner" smart pointer before move semantics, but there are plenty of libraries providing shared pointers. – BoBTFish Sep 28 '18 at 10:30

3 Answers3

7

If you can use Boost, it has provided shared_ptr since long before it was standardized in C++11, so a suitably old version of Boost should be able to provide this in an '03-compatible way.

Alex Celeste
  • 12,824
  • 10
  • 46
  • 89
3

I'd recommend you move away from std::auto_ptr as it's scheduled for deprecation.

But I would shy away from using bare pointers.

Pre C++11, you could use the smart pointer classes available in Boost (www.boost.org). Failing that, you could roll your own versions with a view to removing them once they are available in your standard library. Note that std::shared_ptr is easier to implement than std::unique_ptr, in the latter case I believe you'd have to give up portability since it requires move semantics to implement correctly.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • 1
    downvoters should leave a comment here so that we know why its been downvoted.. it seems a perfect answer to me 0.0 – Yucel_K Sep 28 '18 at 10:31
  • @RichardCritten: Formally yes, but we are relaxing portability here. – Bathsheba Sep 28 '18 at 10:32
  • I don't think it's about portability. AFAIK, C++03 has no way to distinguish between an rvalue and an lvalue, which is needed for implementing transferable unique ownership. If you have a way around that limitation, it would be a good idea to include that in the answer. – Angew is no longer proud of SO Sep 28 '18 at 10:39
  • @Angew: I'll have a look through some of the old StlPort experimental stuff if I get the time, particularly if the OP comes back and says it would be useful to have `unique_ptr` functionality prior to C++11. I also think that Boost were working on something similar. – Bathsheba Sep 28 '18 at 10:42
  • @Bathsheba IIRR, Boost has `scoped_ptr` which is non-assignable, and then `shared_ptr`. – Angew is no longer proud of SO Sep 28 '18 at 10:43
  • @Angew: Yes, that's my recollection too, but I think they were working on a unique style pointer in the early 2000s. May well have been dreaming though. – Bathsheba Sep 28 '18 at 10:45
  • @all sorry, had the last bit the wrong way round. It's unique_ptr that's the trickly one to implement pre C++11. – Bathsheba Sep 28 '18 at 10:49
1

Maybe you can use std::tr1::shared_ptr.

tr1: C++ Technical Report 1 - Wikipedia

Xeonacid
  • 11
  • 3