I think there is a difference between good coding practice and the sort of thing that is enforced through a coding standard.Certainly, if you find yourself having to code an explicit delete, it is a good self discipline that you ask yourself why you aren't using a smart pointer, or even a stack variable.

QuoteOriginally posted by: AlexesDadQuoteOriginally posted by: dirtydroog2Which part didn't you understand?You really are serious aren't you ?????Ok. Let's be generous. Maybe you were in a hurry and pre-occupied with other things. Look at your code and try again.Strong Recommendation : Compile any code BEFORE pasting it hereYou're kidding right, I assumed you'd be intelligent enough to recognise a back-of-envelope snippet from an actual working implementation.Did you really try to compile what I wrote?

Quote You're kidding right, I assumed you'd be intelligent enough to recognise a back-of-envelope snippet from an actual working implementation.Did you really try to compile what I wrote? I have to agree with you - there is no requirement that code should be compilable to post it here.

QuoteOriginally posted by: dirtydroog2You're kidding right, I assumed you'd be intelligent enough to recognise a back-of-envelope snippet from an actual working implementation.I didn't make the mistake of assuming you were intelligent at all.QuoteOriginally posted by: dirtydroog2Did you really try to compile what I wrote?Are you kidding me ?? You can see in 2 seconds this garbage won't compile !So why don't you try pasting a compilable piece of code.

QuoteOriginally posted by: AlexesDadQuoteOriginally posted by: dirtydroog2You're kidding right, I assumed you'd be intelligent enough to recognise a back-of-envelope snippet from an actual working implementation.I didn't make the mistake of assuming you were intelligent at all.QuoteOriginally posted by: dirtydroog2Did you really try to compile what I wrote?Are you kidding me ?? You can see in 2 seconds this garbage won't compile !So why don't you try pasting a compilable piece of code.Let's be friends. Cuddle?

QuoteOriginally posted by: dirtydroog2Your code absolutely cannot have leaks so you put a 'delete iMember' statement in the dtor.Doesn't even make sense. Even if your smart pointer is a good implementation and has the appropriate conversion operator so that it can be the operand of delete , not only do you not need the delete iMember statement it can cause a crash.On one hand you have offloaded the task of cleaning up resources to a smart pointer and then on the other had you are attempting to explicitly do it yourself. What is the point of shooting a corpse ?QuoteOriginally posted by: dirtydroog2Does no harm and is standard practice. Obviously it does, and no it isn't.QuoteOriginally posted by: dirtydroog2Let's say the second allocation fails and and exception is thrown. iMember is cleaned up. The user of your class has also decided to put his instance of your class in a smart_ptr.Well that's just a stupid thing to do.You're trying to justify your view that "never use delete" is nonsense by making a completely inappropriate use of it where it can actually cause a crash.What point have you made exactly ??In my view you have just given further justification why the principle of "never use delete" is in fact a sound principle to have. PS. We'll overlook the fact that you are trying to delete a local variable stored on the stack from the heap

QuoteOriginally posted by: AlexesDadQuoteOriginally posted by: dirtydroog2Your code absolutely cannot have leaks so you put a 'delete iMember' statement in the dtor.Doesn't even make sense. Even if your smart pointer is a good implementation and has the appropriate conversion operator so that it can be the operand of delete , not only do you not need the delete iMember statement it can cause a crash.On one hand you have offloaded the task of cleaning up resources to a smart pointer and then on the other had you are attempting to explicitly do it yourself. What is the point of shooting a corpse ?QuoteOriginally posted by: dirtydroog2Does no harm and is standard practice. Obviously it does, and no it isn't.QuoteOriginally posted by: dirtydroog2Let's say the second allocation fails and and exception is thrown. iMember is cleaned up. The user of your class has also decided to put his instance of your class in a smart_ptr.Well that's just a stupid thing to do.You're trying to justify your view that "never use delete" is nonsense by making a completely inappropriate use of it where it can actually cause a crash.What point have you made exactly ??In my view you have just given further justification why the principle of "never use delete" is in fact a sound principle to have. PS. We'll overlook the fact that you are trying to delete a local variable stored on the stack from the heapwhich local stack variable? "class member"edit: i've had some time to read up more about this and while there are issues to be aware of, it seems possible.I still think it's a silly idea, it's like a chef being afraid to use a sharp knife.*cuddle*

I came up with the "never code delete" rule after realizing that I simply hadn't used it for a couple of years, and this was several years ago. The simple truth is that it never occurs to me to use it directly. In the context of the example above, I would simply have made iMember1 and iMember2 be smart pointers with the correct copying, assignment and destruction behaviour. I then wouldn't have needed any of the "rule of three" special members, and nor would I have needed to do any further thinking. Obviously, "never" is a strong statement and I am sure that there are circumstances where you really need it, but even then I think you'd probably be better off writing a template class that handles the memory stuff for you, rather than putting it into your class directly.

If you allocate resources then most of the time you will wish to release them (on rare occasions this may not be necessary, for example when allocating memory for the life of the program). The question (C++ 101) is whether to release explicitly or implicitly. If you choose to release explcitly then you must be sure to do so in such away that all possible resource leaks are plugged.consider the pseudo code in listing 1I have remembered to release the resource at the end of the function. Is this enough ? For all but the most trivial function the answer is No. You have to ensure every single possible exit point in the function is accounted for. This can not only be VERY difficult but overwhelmingly error prone. Moreover it can be a maintanance headache.Is there a better way ?Yes. You just have to realise 3 things. 1. The compiler is MUCH better at cleaning up resources than you. It's guaranteed to free all local variables stored on the stack at EVERY exit point. 2. In C++, unlike C, user-defined types can be local variables and hence stored on the stack. 3. All user defined types will have their destructor called when they are destroyed. now consider the pseudo code in listing 2Since rc is a local object (on the stack) it will get destroyed for you at every exit point. As a consequence its destructor will be called. As a consequence of THAT, the release statement will be executed. Low and behold, the resource is freed at every exit point.All that you get for free. Indeed you have used the release statement, but you have done so implicitly. This piggy-backing on the back of a destructor of a local variable should not be thought of as a 'trick' but instead as an example of 'working with the language instead of against it'Using delete explicitly means you are attempting to clean up resources (memory) which meanes either that you do not trust the language or you think you are cleverer than the compiler. Either way, its idiotic.The example here is a simplified example of resource de-allocation in function. It wouldn't be very difficult to demonstrate the same principle for resources held by a class.

QuoteOriginally posted by: AlexesDadAll that you get for free. Indeed you have used the release statement, but you have done so implicitly. This piggy-backing on the back of a destructor of a local variable should not be thought of as a 'trick' but instead as an example of 'working with the language instead of against it'Absolutely.And as to the applicability of Mark Joshi's "never use delete" guideline I would say that most quants are in the business of writing C++ libraries. Maybe some applications in C++ above those libraries as well, although Java/C# are often better choices for that layer nowadays. But the production of robust libraries is key to the role of a quant, and by *far* the best way to write C++ libraries that manage resources in a robust fashion in the presence of exceptions is to (in general) tie the lifetime of resources to the lifetime of controlling objects, and (in particular) to tie the lifetime of memory to smart pointers.Personally, when I have been sorting out problematic C++ library code in the past, I've found that a great initial thing to look for is explicit "delete" statements, as they are a very good indicator that the perpetrator doesn't really know what they are doing - so the surrounding code is likely to be problematic in several other ways.That is not to say we can't all make up instances where "delete" is the right thing to do, just to say that such times are in practice rare to the point of non-existence. None of this should be at all controversial. Bjarne Stroustrup has had detailed guidelines on how to write exception-compatible library code out on the web for free for at least 8 years, google for "C++ appendix e".On the other hand I think Herb Sutter made a right pig's ear of explaining about exceptions, massively over-complicating things - perhaps that is why so many people still seem to be confused about it.But if I am checking out someone's C++, I use some idea of how to manage resources robustly as part of an initial sheep-from-goats screen. If you can't sort that stuff out then frankly I don't care how good your stochastic calculus is, since you won't be able to realise your ideas in a form that other people will be able to use.

Whilst I obviously agree with Arkestra, I'd emphasize that the "never code delete" guideline increases robustness even if you don't care about exception safety -- you don't have to do any manual freeing of resources to it's hard to get it wrong.