C++11 Warning C4150 and shared_ptr usage with Allegro

Started by
11 comments, last by SiCrane 11 years, 1 month ago
Isn't the issue that OP needs to use a custom deleter to dispose of the allegro created pointer with the appropriate allegro function?

i.e.

BitmapList[filePath] = std::shared_ptr<ALLEGRO_BITMAP>(al_load_bitmap(fullPath.c_str()), al_destroy_bitmap);

or whatever
Advertisement

Isn't the issue that OP needs to use a custom deleter to dispose of the allegro created pointer with the appropriate allegro function?

i.e.

BitmapList[filePath] = std::shared_ptr<ALLEGRO_BITMAP>(al_load_bitmap(fullPath.c_str()), al_destroy_bitmap);

or whatever

Yeah that was the answer, but as everyone seems to be saying I'm curious as to why std::make_shared should be used?

make_shared allocates the object and the reference count together in a single allocation. This reduces book keeping overhead and makes things easier to reason about with regards to exception safety. For purists it also has the advantage of getting rid of the keyword new from the code. For objects whose pointers are frequently copied at the same time as the objects are accessed, it also provides favorable cache access patterns.

On the downside, the memory block for the object isn't freed until all weak pointers to the object are destroyed as well. For long lived objects where shared_ptrs aren't frequently copied or have weak_ptrs made, the adjacent reference count information can reduce locality of access. For boost::make_shared on non-C++ compilers you can also have argument forwarding overhead.

This topic is closed to new replies.

Advertisement