Question: I have inherited a pile of C++ code, saturated with std::shared\_ptrs, most [all?] of which are unnecessary and are, I suspect, degrading performance. It is not feasible to change everything in one go, so I'm changing the code in tranches and doing performance tests.

An issue I'm running into is the interface in the method hierarchy between my new "raw" pointer code, and the underlying shared\_ptr stuff. A contrived example (I know it could be simplified...):

```
SomeObject *MyClass::GetSomeObject(const std::string& aString)
{
  //for the underlying shared pointer methods
  std::shared_ptr<std::string> tmpString = make_shared<std::string>(aString);

  //call the method using my local shared pointer
  std::shared_ptr<SomeObject> someObj = GetTheObject(tmpString);

  //The line below gives compiler warning: "The pointer points to memory allocated on the stack" 
  return someObj.get(); // a pointer to an object in std::map
}

```

I **know** that `GetTheObject()` is returning a pointer to an object in a persistent `std::map`, so that memory will be in good standing after we exit `GetSomeObject()` and the shared pointer [and its wrapped raw pointer] have gone out of scope.

I'm not in the habit of ignoring warnings, SO:

**Questions:**

1. Is the warning because the compiler is worried about the scope of the shared pointer rather than the object pointed to? [i.e. could I ignore it in this instance?]
2. If it is a real problem, are there any neat ways around this (that do not involve building wrapper classes and such workarounds...) ?

Answer: 
If I understand you correctly, you're replacing smart pointers with dumb pointers, in 2021, and you're now facing the exact problem that smart pointers intended to solve.

The warning is 100% accurate, and I'm pleasantly surprised the compiler looked deep enough.

The solution is simple: return a `shared_ptr<SomeObject>`. If you want efficiency improvements, there are two *real* improvements possible. C++11 introduced move constructors, and [moving shared\_ptr is faster than copying](https://stackoverflow.com/questions/41871115/why-would-i-stdmove-an-stdshared-ptr). The compiler will use the move ctor for `return someObj;` since `someObj` goes out of scope

Secondly, `shared_ptr` is a heavy-weight alternative to `unique_ptr`. At times, you may be able to downgrade to the latter.
I have similar code in my project. I agree that the proper solution is probably just to commit fully to the smart pointers and use them properly. However, I don't want to churn through piles of perfectly functional code, but I also want the warnings to go away. I was able to work around the warning with something like:

```
SomeObject *MyClass::GetSomeObject(const std::string& aString)
{
  //for the underlying shared pointer methods
  std::shared_ptr<std::string> tmpString = make_shared<std::string>(aString);

  //call the method using my local shared pointer
  std::shared_ptr<SomeObject> someObj = GetTheObject(tmpString);

  SomeObject *pRet = someObj.get();
  return pRet; // a pointer to an object in std::map
}

```

I'm a little worried that at some point the compiler will get smarter and detect that as a warning as well, but it seems OK for now. (Visual Studio 2022 v17.1) Hope that helps!