Always avoid "new"

[seesaw]

Is it right thing to always avoid using "new" to create objects? What if
after starting the application, then decide which and how many objects to
create? (Seems like under such situation is there no other choice but using
"new")

 

[Frane Roje]

Is it right thing to always avoid using "new" to create objects? What if
after starting the application, then decide which and how many objects to
create? (Seems like under such situation is there no other choice but using
"new")

I have never heared of such a thing. Making new object using new or malloc
is very common and I don't see why you shouldn't use them.
1)You can allocate much more space using new on the heap rather than on
stack.
2)You can allocate exactly how much you need(
example
You need to read alot of information into an array, the maximum number of
possible elements is let's say 1 000 000. So the user inputs the first
number which
is the number of elements and then you allocate the needed space. Don't
forget to delete afterwards. And 1 more thing I don't thing you could
allocate that much space on stack.
)


HTH

--
Frane Roje

Have a nice day

Remove (*dele*te) from email to reply

 

[John Harrison]

Is it right thing to always avoid using "new" to create objects? What if
after starting the application, then decide which and how many objects to
create? (Seems like under such situation is there no other choice but using
"new")

If new was never to be used why would it have been added to the language?

That said newbies often do use new when they don't need to, which results in
more complex and often less efficient code. A good principle to follow is
don't use new unless you can't see any other way of doing something. The
situation you quote is one such example. Another is when you want the
created object to have an indefinite lifetime (i.e. you only want the object
to be destroyed when you explicitly delete it, not when you exit the scope
in which it was declared)

john

 

[Karthik]

Is it right thing to always avoid using "new" to create objects? What if
after starting the application, then decide which and how many objects to
create? (Seems like under such situation is there no other choice but using
"new")

It would make a worthy if you argue to use new or malloc. The biggest
difference is new calls the constructor of the object whereas malloc
does not ( good ol' C )- it just allocates memory , thatz abt it.


Now, one place where you can argue for / against new is something like here.

void myfun () {
int * a = new int;
*a = 45;
// Thatz it . I am not doing anything with this.
delete a;
// God !! Why did I allocate this on the heap now.
// I didn't pass the variable around , it is so small anyway.
// I could have done this on stack !!!
}


But as you would have discovered, this is more a pedagogical case than a
practical one.

Other than this case, I dont find anything wrong against new.

HTH.

- Karthik.

 

[Niels Dybdahl]

Is it right thing to always avoid using "new" to create objects? What if

after starting the application, then decide which and how many objects to
create? (Seems like under such situation is there no other choice but using
"new")

I do actually avoid "new" as much as possible. The reason is this: The
destructor and deallocator are not called automatically, so to prevent
memory leaks other methods are needed such as try, catch or destructors from
other objects.

Of course if I need a variable number of objects, then I use new and store
the objects in a vector and let the vector do the cleanup. Or in those cases
where I do not store the object(s) in a vector, I store them in some other
object and make that objects destructor ensure cleanup.

An additional advantage of allocating on the stack instead of the heap, is
that if you have tested your application and thereby verified that there is
enough space on the stack, then you can be sure that there will always be
enough space on the stack for your objects (unless you depend on recursion).
With the heap you can not be sure that there is enough space and you risk
exceptions on that account.

Niels Dybdahl

 

[JKop]

seesaw posted:

Is it right thing to always avoid using "new" to create objects? What
if after starting the application, then decide which and how many
objects to create? (Seems like under such situation is there no other
choice but using "new")

Am I the only one that thinks this is stupid?

It's like saying "Always avoid rollerblades". Why the hell would I be
wearing the rollerblades in anyway? I myself wear shoes 99.999999999% of the
time. There would be times when I _would_ wear rollerblades though, although
I'm not gonna have rollerblades on all day.

 

[DaKoadMunky]

Of course if I need a variable number of objects, then I use new and store

the objects in a vector and let the vector do the cleanup.

Are you saying that you allocate T objects with the new operator and then store
the resulting pointers in an std::vector<T*>?

If that is the case then you are probably not getting the cleanup you expect.
Please see http://www.cuj.com/documents/s=7990/cujcexp1910austern/.

 

[Andrew Koenig]

Is it right thing to always avoid using "new" to create objects?

"Always" is a little strong, but in practice there are good reasons to avoid
using "new" for creating more than one object at a time.

What if after starting the application, then decide which and how many
objects to create? (Seems like under such situation is there no other
choice but using "new")

Use a vector. In other words, instead of

T* tp = new T[n];

(after which you have to remember to say "delete[] tp"), say

vector<T> tv(n);

after which the elements of tv will be destroyed automatically when tv goes
out of scope.

In addition to this property, vectors have the advantage that they are easy
to resize, and they also support an efficient append operation.

 

[Andrew Koenig]

If new was never to be used why would it have been added to the language?

Never is too strong -- but in my opinion, the most important use of new
(aside from allocating single objects, which is essential for many forms of
object-oriented programming) is as an implementation vehicle for library
data structures.

Remember that the standard-library containers came along a number of years
after "new"; if they had existed earlier, it is entirely possible that "new"
would never have entered the language.

 

[private name]

Is it right thing to always avoid using "new" to create objects? What if
after starting the application, then decide which and how many objects to
create? (Seems like under such situation is there no other choice but using
"new")

I think you are saying the memory manager should be avoided. Which is
a good thing. Use the stack as much as possible. It makes your
programs much more robust and immune from most of C/C++s biggest
problems imho. Greatly reducing memory fragmentation, memory leaks,
and debugging time. However totally avoiding the memory manager is
often impossible.

Perhaps somebody will write a book on how to avoid the memory manager.
Giving lots of good finely tuned examples of how to take all common
patterns and move them to the stack...

 

[Bill Seurer]

Is it right thing to always avoid using "new" to create objects?

Of course not. You shouldn't use new to allocate if you can do without
it though because you can avoid a whole class of memory errors.

 

[Claudio Puviani]

Never is too strong -- but in my opinion, the most important use of new
(aside from allocating single objects, which is essential for many forms of
object-oriented programming) is as an implementation vehicle for library
data structures.

Remember that the standard-library containers came along a number of years
after "new"; if they had existed earlier, it is entirely possible that "new"
would never have entered the language.

And wouldn't _that_ have been a mistake! The standard containers are a great
facility to have, but I doubt you honestly think that they're sufficient for all
needs and that mechanisms to create alternatives would have been removed from the
language even had containers been present from day one. Even the addition of
reasonable smart pointers wouldn't obviate the need for manual dynamic allocation
in certain contexts.

Claudio Puviani

 

[Default User]

Is it right thing to always avoid using "new" to create objects? What if
after starting the application, then decide which and how many objects to
create? (Seems like under such situation is there no other choice but using
"new")

I'd certainly agree that new C++ programmers use dynamic array-like
things too often, usually the fault of bad tutorials or instructors. So
I'd say to avoid new[] as much as possible, but not new.

Creating objects via new is of course very important in using
polymorphism and design patterns such as Abstract Factory.

Vectors of pointers allow polymorphic containers, but carry with them
the responsibility for cleaning up the allocated objects, unless a
third-party smart pointer system is used (not currently part of ISO
standard C++). When I do that, I use a wrapper class, which has as part
of its destructor routines to walk the container and deallocate the
individual pointers.




Brian Rodenborn

 

[Rob Williscroft]

Claudio Puviani wrote in
in comp.lang.c++:

And wouldn't _that_ have been a mistake! The standard containers are a
great facility to have, but I doubt you honestly think that they're
sufficient for all needs and that mechanisms to create alternatives
would have been removed from the language even had containers been
present from day one. Even the addition of reasonable smart pointers
wouldn't obviate the need for manual dynamic allocation in certain
contexts.

With template variadic arguments:

T *ptr = std::new< T >( /* whatever */ );

Even better:

std::smart_ptr< T > ptr = std::new< T >( /* whatever */ );

Rob.

 

[Andrew Koenig]

And wouldn't _that_ have been a mistake! The standard containers are a great
facility to have, but I doubt you honestly think that they're sufficient for all
needs and that mechanisms to create alternatives would have been removed from the
language even had containers been present from day one.

Whether it would have been a mistake must surely depend on what facilities
were put in place instead for library implementations. My point is mostly
that the definition of "new" is fairly strongly connected to the nature of
the language at the time of its introduction.

 

[jeffc]

Is it right thing to always avoid using "new" to create objects? What if
after starting the application, then decide which and how many objects to
create? (Seems like under such situation is there no other choice but using
"new")

Of course you should use "new" if you need to wait until runtime to decide
which objects, and how many, to create.

 

[jeffc]

I do actually avoid "new" as much as possible. The reason is this: The
destructor and deallocator are not called automatically, so to prevent
memory leaks other methods are needed such as try, catch or destructors from
other objects.

Yes, that's fine. But the OP said "always avoid using" it.

 

[jeffc]

"Always" is a little strong, but in practice there are good reasons to avoid
using "new" for creating more than one object at a time.


Use a vector.

But of course, if *you* were the one having to implement the vector, you'd
have to use new.

 

[Andrew Koenig]

But of course, if *you* were the one having to implement the vector, you'd
have to use new.

Not really; I'd use std::allocator instead, because it gives me
finer-grained control over construction and destruction than new does.

 

[Bobo]

Is it right thing to always avoid using "new" to create objects? What if
after starting the application, then decide which and how many objects to
create? (Seems like under such situation is there no other choice but using
"new")

Well, I would better say: Always avoid new[].