Declare class pointer with or without new

Hi all,

What are the disadvantages to declaring a C++ class pointer without the new operator? E.g. situation 1:

Code:

---

MyClass* myClass;

---

Situation 2:

Code:

---

MyClass* myClass = new MyClass();

---

I understand that using the new operator declares the object on the heap instead of on the stack. However, when I first saw C++ all class pointers were declared without the new keyword. When I do this and compile with g++ with the -Wall option it gives the following warning:

Code:

---

warning: ‘myClass’ is used uninitialized in this function

---

Sorry if this is obvious; I've searched around a lot for the advantages and disadvantages and the only thing I can find is the bit about the stack vs. the heap, and that you need to delete any object created on the heap. Is using the stack somehow faster in terms of performance? If both ways are acceptable, why does g++ generate a warning?

Thanks!

Sorry, I figured out the problem; the pointer is indeed uninitialized so any attempts to get anything from it leads to a seg fault. So never mind.

There are plenty of reasons why you'd declare a pointer without using new. In fact, in a proper C++ program the usage of new should be minimized, and when you do call it the result should almost always be stored in a smart pointer, not a bare pointer.

The usage of "new" and the usage of pointer variables sometimes go together, but you should absolutely not think of them as intrinsically linked. A pointer is just a pointer; it can point to anything, not just heap-allocated objects. A call to new just heap-allocates an object; where you choose to store the reference to it is up to you. Typically this will be in a pointer of some kind, but perhaps it's intrinsic to a pre-existing struct or class rather than declared at the point of construction, for instance.

Quote:

---

Originally Posted by Lindley

In fact, in a proper C++ program the usage of new should be minimized,

---

Where did you get this strange idea?

Quote:

---

Originally Posted by nuzzle

Where did you get this strange idea?

---

http://www.research.att.com/~bs/bs_f...ml#delete-zero

Quote:

---

If you consider zeroing out pointers important, consider using a destroy function:

template<class T> inline void destroy(T*& p) { delete p; p = 0; }

Consider this yet-another reason to minimize explicit use of new and delete by relying on standard library containers, handles, etc.

---

http://hissa.nist.gov/sw_develop/ir5769/node4.html

Quote:

---

G1.1.1 Minimizing Dynamic Memory Allocation.
Avoid the use of C's malloc and free. Instead use (sparingly) C++'s new and delete operators.

---

Regards,

Paul McKenzie

Interesting discussion in the articles linked and the post above. Thanks for providing the links.

So is it safe to say the use of new should be minimized for multiple reasons, one major reason being that dynamically allocating memory can lead to memory leaks and allocation errors?

I see that there are techniques to get around these issues, such as smart pointers as mentioned above and using initialization lists in a constructor, as referenced in one of the articles.

I'm worried about basic optimization and memory management in an upcoming project that deals with large data sets. Am I correct in stating that the heap has more memory available for allocation than the stack? If so, would it be best practice to allocate large sets on the heap and pass them around by reference so as not to create needless copies of the data?

Quote:

---

Originally Posted by MrMojoRisin

So is it safe to say the use of new should be minimized for multiple reasons, one major reason being that dynamically allocating memory can lead to memory leaks and allocation errors?

---

The articles state that programmers should avoid the explicit use of new/delete. Instead alternatives such as library containers and smart pointers should be preferred. The reason is that the new/delete combination is prone to programmer mistakes and errors. So the less you use them the less you're going to f**k them up so to speak.

But this doesn't mean dynamic memory allocations generally should be avoided in C++. Technically it's no more error prone than any other kind of memory allocation. Any memory allocation can fail. And you're not going to have any memory leaks unless you put them there yourself.

There are situations when dynamic memory allocations shouldn't be used but the reason isn't that programmers may shoot themselves in the foot. The reason is that there are no timing guarantees. You don't know how long a heap allocation/deallocation may take so it cannot be used when you write programs with hard timing constraints.

The object oriented programming style relies heavily on dynamic object allocations. To claim that you should avoid using new is a big joke really. It's the same as saying that C++ cannot handle OO and you better use Java or C# instead.

So by all means, minimize the use of new/delete as much as possible because you're only human and bound to make an error sooner or later. Instead use alternatives such as library containers and smart pointers (or even a garbage collector). But it's a mistake to avoid dynamic memory allocations especially in OO. Dynamic memory allocation is an important part of the C++ language and shouldn't be avoided.

Quote:

---

Originally Posted by MrMojoRisin

I'm worried about basic optimization and memory management in an upcoming project that deals with large data sets. Am I correct in stating that the heap has more memory available for allocation than the stack?

---

Yes, way more.

Quote:

---

If so, would it be best practice to allocate large sets on the heap and pass them around by reference so as not to create needless copies of the data?

---

Yes, instead of passing variables by value, you can pass them as const-reference such that you don't have the overhead of creating a copy, but the semantics are the same.
However, allocating large sets of data on the heap doesn't mean that you have to use new. For example, if you have a dataset of one million doubles, you could use a std::vector<double> to store the values (or whatever data structure suits your needs). The vector will internally use heap allocation to store its data. You don't have to worry about managing memory, because the vector does it for you.

Quote:

---

Originally Posted by nuzzle

The articles state that programmers should avoid the explicit use of new/delete. Instead alternatives such as library containers and smart pointers should be preferred. The reason is that the new/delete combination is prone to programmer mistakes and errors. So the less you use them the less you're going to f**k them up so to speak.

But this doesn't mean dynamic memory allocations generally should be avoided in C++. Technically it's no more error prone than any other kind of memory allocation. Any memory allocation can fail. And you're not going to have any memory leaks unless you put them there yourself.

There are situations when dynamic memory allocations shouldn't be used but the reason isn't that programmers may shoot themselves in the foot. The reason is that there are no timing guarantees. You don't know how long a heap allocation/deallocation may take so it cannot be used when you write programs with hard timing constraints.

The object oriented programming style relies heavily on dynamic object allocations. To claim that you should avoid using new is a big joke really. It's the same as saying that C++ cannot handle OO and you better use Java or C# instead.

So by all means, minimize the use of new/delete as much as possible because you're only human and bound to make an error sooner or later. Instead use alternatives such as library containers and smart pointers (or even a garbage collector). But it's a mistake to avoid dynamic memory allocations especially in OO. Dynamic memory allocation is an important part of the C++ language and shouldn't be avoided.

---

I think you're just repeating Lindley's point.
The only difference I see is that
Lindley strictly tries to adheres to the technicalities,
but you're talking a lot of personal opinions, thus, more biased than Lindley's post.
It's much better to guide the new learners to the unbiased facts,
wouldn't you agree?

Quote:

---

Originally Posted by potatoCode

I think you're just repeating Lindley's point.
The only difference I see is that
Lindley strictly tries to adheres to the technicalities,
but you're talking a lot of personal opinions, thus, more biased than Lindley's post.
It's much better to guide the new learners to the unbiased facts,
wouldn't you agree?

---

Neither Lindley nor Paul McKenzie are posting facts. They're posting views as much as I do. I just have a different writing style. The C++ language standard is fact, the rest is opinion.

My point is that it's not the use of dynamic memory that should be minimized, it's the explicit use of new/delete that should be avoided because this keyword pair is especially prone to programming errors. This is an important distinction I think. So use dynamic memory to your hearts desire but seek alternatives to using new/delete directly. If that's how you read the posts of Lindley and Paul McKenzie then fine because that's how they should be read. :)

of course minimizing memory leaks is very important, but if you can't keep your programming from leaking memory, c++ isn't right for you. the new operator in c++ plays a very important role in its design. polymorhpic classes wouldn't even be the same without new.

Here is some stupid code :D

Code:

---

char* Str = "Wow";
delete [] Str;

---

isn't that just great? or

Code:

---

char* Str = new char[100];
free( Str );

---

or

Code:

---

char* Str = (char*) malloc( sizeof( char ) * 100 );
delete [] Str;

---

or

Code:

---

shared_ptr<char> Str ( new char[100] );

---

or

Code:

---

template<class T> inline void destroy(T*& p) { delete p; p = 0; }
char* Me = new char[100];
destroy( Me );

---

or

Code:

---

void m( char* p )
{
    delete [] p;
    p = new[100];
}

---

All those examples will be undefined behaviour :( I seen worser code than memory leaks :eek:. How about memory corruption?

Code:

---

int t[100];
t[100] = 0;

---

Code:

---

int *t;
*t = 100;

---

Code:

---

char Str[] = {'H', 'e', 'l', 'l', 'o' };
cout << Str << endl;

---

c++ is not a safe language, so it use wisely. the list can go on for miles

Quote:

---

of course minimizing memory leaks is very important, but if you can't keep your programming from leaking memory, c++ isn't right for you.

---

That might be a nice sentiment if it had much basis in reality. Alas, it really doesn't - there have been (and still are) innumerable programs written by experts and professionals that leak memory.

Even C++ for all of its complexities and flaws gives you tools to make memory management less of a problem. Not taking advantage of them when you have the opportunity is simply foolish.

Quote:

---

polymorhpic classes wouldn't even be the same without new.

---

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.

Quote:

---

Originally Posted by Speedo

That might be a nice sentiment if it had much basis in reality. Alas, it really doesn't - there have been (and still are) innumerable programs written by experts and professionals that leak memory.

Even C++ for all of its complexities and flaws gives you tools to make memory management less of a problem. Not taking advantage of them when you have the opportunity is simply foolish.

---

It has alot to do with reality. First off I know professionals make mistakes, but really not on such a basic level. I never said using stl containers is bad and should be avoided. I bet you won't find a professional that wouldn't know how to probably handle memory.

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.

---

and I think polymorphic objects in a container is important and there more reasons new is required than for placing derived objects into a container. Consider a factory design pattern. Alot depends on what is occuring at runtime and loads the specific derived type based on requirements. It would be hard to replace new with a local scoped object. It is possible, but wouldn't look as clean.

Quote:

---

Originally Posted by nuzzle

The articles state that programmers should avoid the explicit use of new/delete. Instead alternatives such as library containers and smart pointers should be preferred. The reason is that the new/delete combination is prone to programmer mistakes and errors. So the less you use them the less you're going to f**k them up so to speak.

But this doesn't mean dynamic memory allocations generally should be avoided in C++. Technically it's no more error prone than any other kind of memory allocation. Any memory allocation can fail. And you're not going to have any memory leaks unless you put them there yourself.

There are situations when dynamic memory allocations shouldn't be used but the reason isn't that programmers may shoot themselves in the foot. The reason is that there are no timing guarantees. You don't know how long a heap allocation/deallocation may take so it cannot be used when you write programs with hard timing constraints.

The object oriented programming style relies heavily on dynamic object allocations. To claim that you should avoid using new is a big joke really. It's the same as saying that C++ cannot handle OO and you better use Java or C# instead.

So by all means, minimize the use of new/delete as much as possible because you're only human and bound to make an error sooner or later. Instead use alternatives such as library containers and smart pointers (or even a garbage collector). But it's a mistake to avoid dynamic memory allocations especially in OO. Dynamic memory allocation is an important part of the C++ language and shouldn't be avoided.

---

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. Of course, its essential. But the point I understand that was being made, was about handling the memory yourself using plain malloc/free, new/delete or whatever allocation/deallocation routines which can be beneficial to beginners (this is an opinion). I don't think they questioned the dynamic memory as such just the way they are handled in a program. These are so called guidelines, if you feel comfortable with fire, of course you are free to tame it.

Quote:

---

Originally Posted by nuzzle

So by all means, minimize the use of new/delete as much as possible because you're only human and bound to make an error sooner or later. Instead use alternatives such as library containers and smart pointers (or even a garbage collector). But it's a mistake to avoid dynamic memory allocations especially in OO. Dynamic memory allocation is an important part of the C++ language and shouldn't be avoided.

---

I don't see a disagreement here, so all's well. :)

Quote:

---

It has alot to do with reality. First off I know professionals make mistakes, but really not on such a basic level. I never said using stl containers is bad and should be avoided. I bet you won't find a professional that wouldn't know how to probably handle memory.

---

That's exactly the point. Knowing how to properly handle memory is trivial. If you know "delete everything you new", then congratulations, technically you know how to handle memory.

In reality, however, it is often not so trivial to implement that simple phrase. For example, making sure that your classes can properly handle dynamic memory during copy or assignment. Making sure that code is exception-safe. Etc, etc. The blunt truth is that a whole lot of C++ programmers, whatever they know about memory management, don't pay a bit of attention to those little details until they run into a problem caused by them.

And that's why so many people preach:
Don't use new unless you have to.
When you have to, take advantage of things like smart pointers.

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

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?

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?

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.

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

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?

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

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.

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.

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.