4 ms·
Why are you using delete so often in C++...? 'delete' should be rare in your code.
by wfunction 12y ago
Why are you using delete so often in C++...? 'delete' should be rare in your code.
- robododo 12y agoYou still need delete for some things. Smart pointers are not a panacea.
- Aldo_MX 12y agoWhy shouldn't you? You don't always have control over the code you are writing, an example that comes to my mind quickly is ffmpeg.
- vinkelhake 12y agoHow does ffmpeg relate to this, isn't it written in C?
- shadowfox 12y agoHe may be talking about interfacing with C code of that nature. (You can still localize most of your new/deletes in to the wrapper classes though)
- nly 12y agoBecause using new and delete bare makes writing exception safe, leak-free code about 10 times harder. And I'm pretty sure ffmpeg is written in C.
- vickychijwani 12y agoSomeone over on Reddit asked the same thing. My reply: You're exactly right. But there are multiple complications: - unique_ptr and shared_ptr are only available in C++11 onwards, we're still to migrate to a new compiler - auto_ptr is a joke [1] - I've got to live with `delete` in our gargantuan codebase at work - I could (and should) use boost's smart pointers, and indeed I do when possible. But I admit I sometimes even forget to use those and end up with naked pointers instead. [1]: http://stackoverflow.com/a/111531/504611 http://stackoverflow.com/a/111531/504611
- ajross 12y agoPromiscuous use of smart pointers is almost as bad a code smell as manually newing and deleting stuff. Ownership should be object lifetime, and it's really not hard to arrange member objects to make that work. And if you really can't, and you need a container that automatically frees its contents when destroyed, just stick it in a STL vector.
- nostrademons 12y agoPromiscuous use of shared pointers is a code smell. std::unique_ptr (or its predecessor, boost:scoped_ptr if you don't have access to C++11) should be used all over the place. There are many reasons why you may not want by-value containment of objects, and std::unique_ptr gives you object-lifetime ownership of pointers.
- wfunction 12y ago> There are many reasons why you may not want by-value containment of objects I'm interested in reading them actually, would you mind listing them?
- nostrademons 12y agoNullability - a scoped_ptr or unique_ptr can be null, a value object can never be. Polymorphism - a value object is always exactly its static type, but you can substitute in different derived types for a unique_ptr. The previously-held object is automatically destroyed when you do this. This is essential for the State and Strategy patterns. Reassignment/swap - reassigning a unique_ptr destroys its previous value and transfers ownership of the new one. Reassigning a value object invokes operator=. The former can (sometimes, not always) be faster than the latter - think about cases where you just want a quick pointer swap inside the object, rather than having to shuffle all the bits in a large struct around. Release - unique_ptr has a member function to release ownership of the object, while this concept doesn't apply to value objects. Where might this be useful? Well, imagine trying to achieve exception safety inside a factory function with complex construction logic, and then transferring ownership to the caller. It's common to immediately assign the new object to a unique_ptr upon construction (so if an exception is ever thrown, it is destroyed properly), perform your logic, and then return ptr.release().