Thread: Casting raw ptr to shared_ptr

Did you try running it in a debugger to see where it's actually crashing, and inspect the values of the various things at that time?

Here is main(). just 4 lines of code...

Code:

  double arr[6] {1,2,3,4,5,6}; //create sample data
  BImg<double> img;
  double x {5.0}; //commenting out this unrelated line makes it crash...  
  img.load(arr); //implicitly creates raw double pointer, crashes when assigning member "data"

Here is the class Minimal Example

Code:

template<typename T>
class BImg
{
std::shared_ptr<T> data;
BImg(){} //empty ctor
void load(T*); //see earlier definition
};

What messes me up is: when i declare & initialize some unused double x it doesn't crash.

EDIT:
I just noticed my shared_ptr is probably trying to delete something from the stack... guess I was too optimistic about the smarts of smart pointers sorry.

Well, obviously it's going to crash if you try to assign something to a smart pointer that you did not "new". That's what smart pointers are, after all. There's no sense in assigning something that belongs on the stack, though, as the stack cleans itself up automatically.
You could also use a customer deleter if the data must be freed but does not come from new.

Originally Posted by jiggunjer

guess I was too optimistic about the smarts of smart pointers sorry.

There is no standard way to know whether a pointer was allocated with new or not.

O_o

You are already using a C++11 feature so I'll assume you don't mind more C++11 features.

With that in mind, I'd suggest defaulting to copying the data optionally referencing the data which does require a length.

Code:

template <typename S> void load(S ptr, size_t size);

You can then use `std::ref` to do the informing.

Code:

double arr[6] {1,2,3,4,5,6};
BImg<double> img;
double x {5.0};
img.load(std::ref(arr), 6);

If you write the relevant convenience functions, the interface is very palatable.

Soma

If I don't copy, will a smart pointer to a std::ref wrapper-object delete only the wrapper if it's a reference to a stack variable, but delete the data as well if it's a ref to a heap variable?

Originally Posted by Elkvis

There is no standard way to know whether a pointer was allocated with new or not.

There's hacks, but they are most definitely platform dependent and implementation defined; not portable.

The only way to know, is upon allocation itself, and so if he really wanted, he could create a wrapper that deals with pointers to addresses on the stack vs. heap separately through one single interface... This still relies on the caller properly differentiating between stack and heap pointers though and the implementation of this would get cumbersome to manage. Because it's still the caller's responsibility not to screw things up I would say that this is not much different than the responsibility of using smart pointers, or rather dealing with pointers properly to begin with to ensure that there's no requirement to have to deal with issues like this allocation one.

Just my opinion... I'm sure there are many others out there, and maybe someone else can elaborate on this. I actually think that boost::shared_ptr has an implementation set up for doing such things(?)

I read this on an article on SO:

Code:

template<typename T> void no_delete(T* ptr) { /* do nothing here */ }

class YourDataType; // defined elsewhere
boost::shared_ptr<YourDataType> heap_ptr(new YourDataType()); // delete at scope end

YourDataType  stackData;
boost::shared_ptr<YourDataType> stack_ptr(&stackData, &no_delete); // never deleted

If one chooses to go down this dark path... ^^This is probably the best bet, if you don't choose the better option to just use smart pointers properly.

I'm pretty certain that standard smart pointers operate in the same way. So it's your own responsibility to know that a pointer is pointing to something on the heap or the stack... From that point you can decide whether the smart pointer uses the default deleter, or one of your own:

Code:

template<class T, class D = default_delete<T>> class unique_ptr;

The default deleter's as far as the standard is concerned, means that either delete or delete[] is called for the stored pointer.

The default type for the template parameter D is default_delete. A client-supplied template argument D shall be a function object type(20.9), lvalue-reference to function, or lvalue-reference to function object type for which, given a value d of type D and a value ptr of type unique_ptr<T, D>:: pointer, the expression d(ptr) is valid and has the effect of disposing of the pointer as appropriate for that deleter.

What I'd do is first decide whether or not the class should share ownership of the pointer or not. If not, then the caller is responsible for keeping the pointer alive until the class is destroyed. In that case, take a raw pointer (and don't delete it!). If you want to share ownership, then just take shared pointer.

If you absolutely must have both ways, then you can internally wrap the raw pointer in a no-op shared_ptr. Hence you can have a shared_ptr member in your class as a member to take care of the deletion.

If the user is responsible for deleting the data, then you don't have to worry about that. If you take a shared_ptr, then the user is responsible for providing a correct deleter, which should be automatically determined by the type of T. Still, I'd always use a std::vector or std::array as the type which means you should always use delete.

Originally Posted by cstryx

There's hacks, but they are most definitely platform dependent and implementation defined; not portable.

Which is exactly why I included the word "standard" in my reply. As a general rule, we only discuss standard C++ here, unless the OP asks about a specific library or implementation-defined feature.