Re: Never ever use a raw pointer when a smart pointer can do the same
job
On Aug 15, 12:49 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Aug 14, 11:44 pm, Ian Collins <ian-n...@hotmail.com> wrote:
Noah Roberts wrote:
One term you should quantify is "application level". You use
it often and I'm not sure where you draw the line.
Me neither. In many ways, it's intentionally vague. As are all
the terms like "usually" or "in most cases". There are no hard
and fast rules, and there is no strict line. By application
level, I mean something along the lines of code which deals with
application level abstractions, things like business logic, or
call handling; things you'd name using names from the
application domain. But it's not a hard and fast line: in most
programs, a class managing an HTTP connection would be part of
the infrastructure, but in a browser or a web server?
But I also do a lot of work with dynamic input data, where
most pointers used will be for dynamic objects. Although
in these cases, the pointers will not be visible to the
"application code", they will be contained within the
objects managing the dynamic memory.
Maybe James' point is "Most, if not all, *naked* pointers
are for navigation only"?
No. What I'm trying to say is that most things that would
be considered a pointer at the application level (naked
pointers or smart pointers) are used for navigation (and
thus should usually be naked pointers, because the smart
pointers I've seen don't buy you anything but trouble when
used for navigation).
I agree, with the exception of container iterators.
Yes. In the measure that STL-style iterators are smart
pointers, you'll use that type of smart pointer at the
application level. But I suspect that I'm in a minority in
considering STL iterators smart pointers, and conceptually, when
I use them, the higher level abstraction that I'm concerned with
isn't a pointer. (In general, when I provide the iterator, it
also provides a GoF interface, which is closer to the
abstraction I'm generally using.)
The issue doesn't have any absolute answer, precisely because
there are so many variables, delimited by vague terms.
Certainly, the application uses a lot of other pointers, but
not directly---I don't consider std::vector a smart pointer,
for example, or std::map.
True. But they do share one attribute with smart pointers:
they manage dynamic memory.
But that's irrelevant, since they don't provide the interface or
the services of a pointer.
While I disagree with the assertion in the subject, I'm a firm
believer in navigation (the pointer is initialised to point to
an existing object) being the only use for naked pointers in
C++ code.
I wouldn't go so far, but in practice, in a lot of applications,
it doesn't matter, since navigation is often just about the only
use of pointers, smart or otherwise. Except, of course, the
this pointer, but you can't use a smart pointer there.
The only time I'd expect to see "new" would be in the
initialisation of a smart pointer or for an object to be
inserted in a managed container.
Really. What about entity objects, which manage themselves.
Often (at least in the code I've seen), the results of the new
expression aren't used at all---it's just:
new MyType( someArguments ) ;
, with the value of the new expression being discarded. When
this isn't the case (which is also fairly often---it depends on
the requirements of the code), the results of new generally will
be used to initial a smart pointer, almost always std::auto_ptr.
But once the necessary arrangements have been made so that you
can navigate to the object, or find it when you need it, which
is generally before the end of the transaction, release() is
called on the auto_ptr. It's a temporary measure, covering you
until all of the proper invariants can be established.
And vice versa. What I really started out by saying is that
both are important tools to have in your tool kit, and you
need to understand when each is important.
I don't think anyone will disagree with that.
So why such a reaction to my original comment:-) ?
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34