Re: Declare class pointer with or without new
Quote:
Originally Posted by
Speedo
In reality, however, it is often not so trivial to implement that simple phrase.
That's why programs such as Purify, BoundsChecker, Insure++, and others exist, and in some cases, sell for very hefty prices. These companies know that solving memory allocation and leak issues is not trivial for most non-trivial applications.
The underlying fact is that professional programmers make mistakes, mistakes that cannot be easily solved by looking at code, or even running in a debugger. When a codebase takes thousands, if not millions of different execution paths depending on data, input, etc. a human being, regardless of their knowledge of C++ and memory handling, may not be able to solve complex memory allocation problems in any reasonable time.
If you're coding your own app that's used in-house, that's one thing. When you're coding an app used by the consumer market or for clients, and you have competition from other vendors, any time wasted debugging could mean money. To avoid, or at the very least, lessen the chances that errors occur, you use the safest techniques that are at your disposal.
When code reviews were given at a company I worked for, whenever the reviewer saw "new/delete", and the reason was not obvious (polymorphism, for example) the reviewer would ask "why are you doing this?". If the question cannot be answered reasonably, or if alternatives existed, the code was given back to you to correct or change. Even if it's so safe to use "new/delete", the code was to be corrected. Things like this:
Code:
void foo()
{
char *p = new char [100];
//....
delete [] p;
}
Code like this, even if it's safe, was thrown back at you to fix, and IMO, for good reason.
Regards,
Paul McKenzie
Re: Declare class pointer with or without new
Quote:
Originally Posted by
Paul McKenzie
When code reviews were given at a company I worked for, whenever the reviewer saw "new/delete", and the reason was not obvious (polymorphism, for example) the reviewer would ask "why are you doing this?". If the question cannot be answered reasonably, or if alternatives existed, the code was given back to you to correct or change.
The C++ programming unsafety of new/delete even gave birth to a new language called Java so why doesn't everyone switch to Java? The reason is that C++ gives you a choise. You can use new/delete when you really need to but you can also use alternatives which makes a C++ program almost as safe as a Java program.
I think the links you provided in a previous post give the wrong impression so I want to emphasize my point again. The issue is not to avoid the use of dynamic memory in C++. Especially in OO you need it because this programming paradigm heavily depends on dynamic object allocations. No, the issue is to avoid using the new/delete pair explicitly in code. Why is that so bad? It's because it's inherently error-prone. Everything that requires exact matching and cannot be checked at compile-time is.
As I see it you should withdraw your post #5 or at least clarify what you meant by posting those links?
Re: Declare class pointer with or without new
Quote:
Originally Posted by
exterminator
I think you took the points posted by Lindley and Paul to a wrong context/interpretation and posted the above. I don't see where they said to avoid dynamic memory.
If you have a look at the second of the links Paul posted it says:
G1.1.1 Minimizing Dynamic Memory Allocation.
It would be interesting to hear Paul elaborate on this. Is this something he recommends really?
Re: Declare class pointer with or without new
Quote:
Originally Posted by
Speedo
Polymorphism works just fine without new. About the only time that new is actually required for it is when you need a container of polymorphic objects.
Well, object slicing can occur in many situations and the best way to avoid it systematically is to treat objects via pointer.
So polymorphism works without new, but it works better and safer with new. That's the consensus view.
Re: Declare class pointer with or without new
Quote:
As I see it you should withdraw your post #5 or at least clarify what you meant by posting those links?
:confused:
You should clarify your post #4. Why is minimizing the usage of new a "strange idea" (your words, not mine)?
Regards,
Paul McKenzie
Re: Declare class pointer with or without new
Quote:
Originally Posted by
Paul McKenzie
:confused:
You should clarify your post #4. Why is minimizing the usage of new a "strange idea" (your words, not mine)?
My post #4 is a question and you answered it in your reply #5.
Are you asking me to now modify my question to better fit your answer?
Re: Declare class pointer with or without new
Quote:
Originally Posted by
nuzzle
My post #4 is a question and you've already answered it (in your reply #5).
So to sum up, the minimizing of using "new" in a C++ program is not a strange idea after all.
Regards,
Paul McKenzie
Re: Declare class pointer with or without new
Quote:
Originally Posted by
Paul McKenzie
So to sum up, the minimizing of using "new" in a C++ program is not a strange idea after all.
Wrong.
The idea that "new" shouldn't be used freely is very strange indeed.
Re: Declare class pointer with or without new
Quote:
Originally Posted by
nuzzle
If you have a look at the second of the links Paul posted it says:
G1.1.1 Minimizing Dynamic Memory Allocation.
It would be interesting to hear Paul elaborate on this. Is this something he recommends really?
I cannot see what's wrong with saying that dynamic memory allocation should be minimized: given two implementations of the same concept that differ only on the amount of dynamic allocation used you should prefer the minimizing one. It seems fair to me.
Re: Declare class pointer with or without new
Quote:
Originally Posted by nuzzle
Wrong.
The idea that "new" shouldn't be used freely is very strange indeed.
I think that you are just being pedantic where the word "explicit" is omitted, since you stated that "it's the explicit use of new/delete that should be avoided because this keyword pair is especially prone to programming errors". Frankly, I regard "explicit" as implicit in what Paul McKenzie stated, and alternative interpretations just do not agree with what has been stated in this thread.