More generally, when any number of essential facts will not be
known until runtime. One of the most frequent reasons I use new
is because the actual type of the object will not be known until run-time.

More generally, when you need exact control of the lifetime of
the object, and the desired lifetime doesn't correspond to
dynamic scope. On some (admittedly very rare) occasions, I've
used new to shorten the lifetime of an object.

Most of the cases I can remember from Design Patterns involved
cases where the actual type was not known until runtime. The
Design Patterns are full of dynamic polymorphism.


There can be several reasons for this: the actual type isn't
known until runtime, the new'ed object may be shared between copies, etc.


I don't think I've ever seen this -- in the general case, it
cannot be made to work.


This is, of course, a reason as well. The compilation firewall
idiom uses a new where the type, number and scope are fully
known at compile time, simply to be able to use a forward
declaration rather than the full definition.

I'm not sure which exact cases you are talking about, but on
large projects, the compilation firewall idiom applies almost
automatically on everything but the most trivial objects.

The simple rule is to use values when you can, and pointers when
you must. In practice, however, there are a lot of cases where
you cannot use values.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

ulrich eckhardt

This isn't one, as that's what containers exist for.


Yes. The alternative might be copying/return by value.


There's a point in this. I would not try to alloc 20MiB on the stack, but
on the heap that presents no problem. I also know that e.g. Linux (I mean
the kernel itself, not programs running on top of it) has a stack limit of
only 4 or 8 KiB. Else, most modern OSs grow the stack dynamically on demand, I believe.

I'm not sure about the examples in "Design Patterns". I don't think it is
very sophisticated C++ code in there though, but that's not the point of
the book, I'd say.

PIMPL pattern or some other kind of plugin?

If there are more than two pointers involved, not even that is safe,
because the order is not necessarily 'new1, smart_ptr1, new2, smart_ptr2',
it could also be 'new1, new2(throws here), smart_ptr1, smart_ptr2'.

This would fall into the area of PIMPL. Yes, this is a common way. Note btw
that this not only reduces compile time but also serves to decouple the
implementation of e.g. a library from its interface.

I believe that is the most important place. When I only have some kind of
handle to the baseclass/interface, I only have (smart-)pointers or
references as choice for them; usually, using (smart-)pointers is the way
to go then, in particular when you need to create a container<baseclass>
indirectly by using container<baseclass*>. I wonder, doesn't this apply to
many of the examples in "Design Patterns" above?


One comment in general: there are incredible amounts of code out there that
are badly written, so it might simply be that.
In particular, when people convert from Java to C++ they tend to use new
much too often and without understanding it, or when converting from C
when they fail to make proper use of the standardlibrary and instead treat
new as a replacement for malloc. Also, using e.g. the Qt toolkit, you will
see lots of unbalanced new/delete calls for widgets, but that isn't wrong
(in that context!) but only a characteristic of this particular toolkit.


Optional things is indeed another big use of pointers (though not
necessarily with new). In many cases, I'd use boost:ptional<> though,
but opinions may vary.
Another use of new is when using placement new, but I don't think you had
that in mind when asking.

Uli

--
Questions ?
see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first !


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

seungbeom kim

Using a pointer to a component as a member instead of directly embedding
the component does help to reduce compilation dependency, because the
compiler need not know the full definition of the embedded object.

#include "component.h"
class whole {
component c_;
};

can be replaced with

class component;
class whole {
component* c_;
};

Some authors advocate *always* using pointers (not necessarily raw) as
members because it's more flexible: a directly embedded component cannot
be removed at run-time, nor can it be specialised without changing the
class declaration and causing recompilation. It's simpler and more
efficient, though.

However, I've often seen codes cluttered with unnecessary new and delete
(e.g. in a function body) where they can simply be replaced with an object
declaration, which seems to be a phenomenon effected by Java.

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

jakacki

Post an example.


By declaring 'XBase* _x' instead of 'XBase _x' :

- you can make '_x' point to another object later,
perhaps of a class different than X (cf. Strategy pattern),

- you don't have to expose 'XBase' declaration at the
point where you declare '_x' (and if this is in a
header you reduce compile-time dependencies),


Perhaps ctor stores the pointer for later use. I don't get
what alternatives do you see? Something like this:

x = foo(X(), ...);
x.do_something();

would have very different meaning, when x.do_something()
executes, the temporary created by X() is already destroyed.


Not the main reason, I would say.

I don't think so.

BR
Grzegorz

--
Free C++ frontend library: http://opencxx.sourceforge.net
China from the inside: http://www.staryhutong.com
Myself: http://www.dziupla.net/gj/cv

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]