Yeah I know. I still have in my checkup list the use of smart pointers, since I've seen that's whats being used to ease memory management.
If you're coming from a managed language (and/or aren't proficient/expert at manual memory management that really needs manual memory management), I'd recommend avoid using "new" (and, consequently, "delete") altogether. Make it your habit now, don't put it off (esp. since you need to break the habit of using "new" in your managed language -- note, that in addition to implying manual memory management, the heap allocation usually isn't the only (or even default) choice in C++, where stack-allocated values are common).
I suggest you read the following cover-to-cover, it's up-to-date modern C++11 (and feel free to ignore any materials on dynamic memory management in C++ which start by introducing new/delete before introducing smart pointers -- a pretty good way to tell they're already obsolete): http://www.informit.....aspx?p=1944072
After you read the above, the following is a good follow up:
http://herbsutter.com/gotw/_102/ // pay special attention to the "make_unique" part
http://herbsutter.com/gotw/_103/
http://herbsutter.com/gotw/_104/
In general, instead of using "new":
0. first consider if you shouldn't be using an automatic (stack-allocated) variable instead,
Note: thanks to std::reference_wrapper, the need for dynamic polymorphism is not a valid excuse to allocate on the heap:
// based on http://bryanstamour.com/2012/06/26/need-polymorphism/
Shape s1;
Shape s2;
Square sq1;
using shape_ref = std::reference_wrapper<Shape>;
std::vector<shape_ref> shapes = {
std::ref<Shape>(s1),
std::ref<Shape>(s2),
std::ref<Shape>(sq1)
};
// Assume that we're calling the draw_shapes that
// takes in its argument by-reference.
std::for_each(
begin(shapes),
end(shapes),
draw_shape
);
1. if not, and you don't need shared ownership (consider this as the default case), consider using make_unique,
// note: std::unique_ptr<T> has zero overhead over T* -- that's another reason for it to be your first choice for the heap-allocated variables; however, neither will be as fast as stack-allocated variables (provided you can fit them on the stack, of course -- the only limitation / possible excuse here)
2. if not, and you need shared ownership, use make_shared,
3. forget "delete" and "new" ever existed :-)