Possible Duplicate:
In C++, why shouldnewbe used as little as possible?
Is it really a bad idea to use 'new' in instantiating a class in C++? Found here.
I get that using raw pointers is ill-advised, but why have a 'new' keyword at all when it's such bad practice? Or is it?
The point is that new, much like a pregnancy, creates a resource that is managed manually (i.e. by you), and as such it comes with responsibility.
C++ is a language for library writing, and any time you see a responsibility, the "C++" approach is to write a library element that handles this, and only this, responsibility. For dynamic memory allocation, those library components already exist and are summarily referred to as "smart pointers"; you'll want to look at std::unique_ptr and std::shared_ptr (or their TR1 or Boost equivalents).
While writing those single-responsibility building blocks, you will indeed need to say new and delete. But you do that once, and you think about it carefully and make sure you provide the correct copy, assignment and destruction semantics. (From the point of exception safety, single responsibility is crucial, since dealing with more than one single resource at a time is horribly unscalable.)
Once you have everything factored into suitable building blocks, you compose those blocks into bigger and bigger systems of code, but at that point you don't need to exercise any manual responsibility any more, since the building blocks already do this for you.
Since the standard library offers resource managing classes for the vast majority of use cases (dynamic arrays, smart pointers, file handles, strings), the point is that a well-factored and crafted C++ project should have very little need for any sort of manual resource management, which includes the use of new. All your handler objects are either automatic (scoped), or members of other classes whose instances are in turn scoped or managed by someone.
With this in mind, the only time you should be saying new is when you create a new resource-managing object; although even then that's not always necessary:
std::unique_ptr<Foo> p1(new Foo(1, 'a', -2.5)); // unique pointer
std::shared_ptr<Foo> p2(new Foo(1, 'a', -2.5)); // shared pointer
auto p3 = std::make_shared<Foo>(1, 'a', -2.5); // equivalent to p2, but better
Update: I think I may have addressed only half the OP's concerns. Many people coming from other languages seem to be under the impression that any object must be instantiated with a new-type expression. This is in itself a very unhelpful mindset when approaching C++:
The crucial distinction in C++ is that of object lifetime, or "storage class". This can be one of: automatic (scoped), static (permanent), or dynamic (manual). Global variables have static lifetime. The vast majority of all variables (which are declared as Foo x; inside a local scope) have automatic lifetime. It is only for dynamic storage that we use a new expression. The most important thing to realize when coming to C++ from another OO language is that most objects only ever need to have automatic lifetime, and thus there is never anything to worry about.
So the first realization should be that "C++ rarely needs dynamic storage". I feel that this may have been part of the OP's question. The question may have been better phrased as "is it a really bad idea to allocate objects dynamically?". It is only after you decide that you really need dynamic storage that we get to the discussion proper of whether you should be saying new and delete a lot, or if there are preferable alternatives, which is the point of my original answer.
Avoiding new as much as possible, means many benefits, such as:
First and foremost, you also avoid delete statements.Though smart pointers can help you here. So this is not that strong point.
You avoid Rule of Three (in C++03), or Rule of Five (in C++11). If you use new when designing a class, that is, when your class manages raw memory internally, you probably have to consider this rule.
It's easy to implement exception-safe code when you don't use new. Otherwise, you've to face hell lot of problems, making your code exception-safe.
Using new unnecessarily means you're inviting problems. I've seen when an inexperienced programmer uses new, he has often better alternatives, such as usage standard containers, and algorithms. Use of standard containers avoids most problems which comes with explicit use of new.
It's not bad, but everything you allocate with new, has to be deallocated with a delete. This is not always trivial to do, especially when you take into account exceptions.
I think that is what that post meant.
It's not a "bad idea to use new" -- the poster misstated his case rather badly. Rather, using new and not give you two different things.
new gives you a new, separately allocated instance of the class, and returns a pointer to that instance.
Using the class name without new creates an automatic instance of the class that will go "poof" when it passes out of scope. This "returns" the instance itself, not a pointer (and hence the syntax error in that other thread).
If you use new in the referenced case and added * to pass the compiler, it would result in a leaked object. If, on the other hand, you were passing a parameter to a method that was going to store it somewhere, and you passed a non-newed instance, making it work with &, you'd end up with a dangling pointer stored.
new what you delete, and free what you malloc (don't mix them, you'll get into trouble). Sometimes you have to use new, as data allocated with new will not fall out of scope... unless the data pointer is lost, which is the entire issue with new.
But that is err on the side of the programmer, not the keyword.
It depends on what the code needs. It the reply you refer to, the vector contains client instances, not pointers to client instances.
In C++, you can create object directly on the stack, without using new, like V1 and V2 in the code below:
void someFct()
{
std::vector<client> V1;
//....
std::vector<client*> V2;
}
When using V2, you will have to create new client instance with the new operation, but the client objects will not be released (deleted) when V2 will go out of scope. There is no garbage collector. You have to delete the objects before leaving the function.
To have the created instances deleted automatically, you can use std::shared_ptr. That make the code a bit longer to write, but it is simpler to maintain in the long term:
void someFct()
{
typedef std::shared_ptr<client> client_ptr;
typedef std::vector<client_ptr> client_array;
client_array V2;
V2.push_back(client_ptr(new client()));
// The client instance are now automatically released when the function ends,
// even if an exception is thrown.
}
Is it really a bad idea to use 'new' in instantiating a class in C++?
It’s often bad because it’s not necessary, and code gets much easier when you’re not using it spuriously. In cases where you can get away without using it, do so. I’ve written whole libraries without once using new.
I get that using raw pointers is ill-advised, but why have a 'new' keyword at all when it's such bad practice? Or is it?
It’s not universally bad, just unnecessary most of the time. But there are also times when it’s appropriate and that’s why there is such a keyword. That said, C++ could have gotten away without the keyword, since new conflates two concepts: 1. it allocates memory, and 2. it initialises the memory to an object.
You can decouple these processes by using other means of memory allocation, followed by a constructor invocation (“placement new”). This is actually done all over the place, such as the standard library, via allocators.
On the other hand, it’s rarely (read: never) meaningful for client code to manage uninitialised memory so it makes sense not to decouple these two processes. Hence the existence of new.
