Re: printing in C++
On Tuesday, 19 March 2013 22:22:46 UTC, =D6=F6 Tiib wrote:
On Tuesday, 19 March 2013 20:16:37 UTC+2, James Kanze wrote:
On Monday, 18 March 2013 21:15:13 UTC, =D6=F6 Tiib wrote:
On Monday, 18 March 2013 19:25:35 UTC+2, James Kanze wrote:
On Saturday, 16 March 2013 22:35:44 UTC, =D6=F6 Tiib wrote:
On Sunday, 17 March 2013 00:17:48 UTC+2, James Kanze wrote:
On Saturday, March 16, 2013 4:56:16 PM UTC, =D6=F6 Tiib wrote:
I
have strong belief that after C++11 we really do not need to
use any naked pointers in everyday programming.
Most pointers in well written C++ are for navigation, and shoul=
d
be raw pointers.
Why? For navigation there are usually iterators. While standard a=
llows
raw pointers as iterators all modern implementations use special=
classes that are as efficient and lot safer.
How can you navigate using iterators. The target objects aren't
necessarily in any particular sequence.
Some thoughts of mine ...
* Most numerous objects are not just freely floating around but
are in containers.
I'm not sure what you mean by "just freely floating around". If
the object isn't "freely floating around" in some sense of the
word, there's no need to allocate it dynamically (usually).
I mean that if the objects are not polymorphic and are numerous then they
are usually directly in container (like 'std::vector<T>' ). If the object=
s
are polymorphic and numerous then they can be in intrusive containers or
in pointer containers. Pointer container can be special (like boost::ptr_=
vector<T>') or standard (like 'std::vector<std::unique_ptr<T>>').
The life-time of object is bound to such containers but most numerous
objects usually have their lifetime bound to something else.
There are objects and there are objects. Value objects, which
can be copied, are not a problem, since you don't normally have
pointers (smart or raw) to them, anywhere. Entity objects do
have identity, and you can (usually) navigate between them.
They normally have their own lifetime, defined by the
application logic, however, and aren't in containers, per se.
(Pointers to them may be in containers, for navigation purposes,
of course.)
There are often containers with pointers to the object, to
implement 1->n relationships. But these would contain raw
pointers.
Depends on type of relation. Components can be in container of
std::unique_ptr or boost::ptr_somethings and contain reference
to composite. Other 1->N associations can be made using
containers of std::shared_ptr, std::weak_ptr or boost::intrusive
containers.
None of these smart pointers implement relationships correctly.
A raw pointer does, sort of. (You still need an observer,
because there's a good chance that an object which has a pointer
to you will want to know when you are destructed.)
* There must be some way to sequence the objects of application.
Otherwise it may be difficult to serialize, unserialize, dump,
roll back, undo, redo and the like.
You create temporary collections of objects on an as needed
basis. You have to be able to navigate to the objects. But
this is best done, once again, using raw pointers.
What sort of navigation you mean? I usually use visitor or memento
pattern and those do not use pointers but either references or
templates. For observers I use slots and signals, current favorite
is boost::signals2. In interface they use references and function
pointers (I do not mind function pointers).
Navigation, like going from one object to another. Implementing
the application specific relationships between objects. In
a GUI, for example, a container will know about its
sub-components, the sub-components will know about the
container. You can navigate in either direction (and in some
cases, accross).
I'm not talking about the sort of navigation visitors do.
I am still unsure what sort of navigation you mean. Visitors navigate
fine with references. Containers navigate fine with iterators.
Polymorphic objects are fine with smart pointers. Observers work fine
with references and functions.
Observers are a perfect example. Observers can't use
references, since they have a dynamic lifetime. In a typical
implementation, the Observee will have a vector of raw pointers
to the Observers. How else could you implement it. You can't
use references (a vector can't contain references). You can't
use unique_ptr (because the observer objects exist outside of
the observee). You can't use shared_ptr (because the observer
objects manage their own lifetime, and will auto-destruct). You
can't use weak_ptr, because there cannot be any shared_ptr to
the object. You can't use iterators, because the object itself
isn't in any container.
A long time ago, I worked with a firm which had designed
a managed_ptr; a pointer which was, itself, an observer, and
reset itself to null when the pointed to object was deleted.
This was designed to solve a very special case, and worked well
there, but experimentation soon revealed that it wasn't
a general solution. Whoever had a pointer to the object usually
needed to know when the object was destructed anyway, so it
could reconfigure itself to function without the object. And
once you have the observer, any additional baggage just to
manage the pointer is just added complexity.
* The objects whose life-time must end exactly at certain
moment are better in intrusive containers. The containers of raw
pointers are less suitable since the object has to have knowledge
of being in those for to exit those. With intrusive containers it
has such knowledge more naturally.
The object obviously has to know about all of the objects which
reference it, in order to inform them of its demise. This is
the observer pattern. I've yet to find any smart pointer which
handles this correctly. Espcially as the objects which
reference it will usually have other actions to take when it
disappears (e.g. switch to a backup).
std::vector can not be made observer of objects that it contains.
Of course not. std::vector is a low level implementation
detail. It only exists to be used by higher level objects.
So there must be some sort of helper object that manages it.
Obviously. An application isn't defined in terms of
std::vector.
Now lets look
at boost::intrusive::auto_unlink_hook. The element will be removed from=
a container when element is destroyed and no characters need to be typed.=
If
it is in several containers then it has to have several hooks. Very tidy.=
Note that the intrusive containers can be polymorphic without pointers
needed and lifetime of object is not bound to lifetime of container in an=
y
way.
It might help in a few cases, but it still doesn't solve the
larger problem. Removing the pointer from a vector or a map is
one thing; telling the object which contained the vector or map
that something is happening that it needs to know about is
another. And once you've solved this second problem, you don't
need a solution specialized in removing the pointer from
a container.
And intrusive containers suppose that the object knows about all
of the containers it might be inserted into. Which is
fundamentally impossible, because it is an open set.
[...]
That's what I said. For short lived object (e.g. temporary
agents), reference counted pointers are fine; this is where
I first used them (about 20 years ago), and this is one of the
few places where I still use them systematically. In many ways,
logically, it would make more sense to copy the objects, but
copy and polymorphism don't work well together.
Polymorphic objects are usually not copy-able but often clone-able
and are fine with smart pointers.
Some polymorphic objects, yes. Larger, entity objects will
contain pointers to other objects, which in turn contain
pointers back to the original object, and have their own
specific lifetimes.
One usage (may-be worth mentioning) are opaque pointers (or more often
called "handles"). The smart pointers of C++11 produce such things also
very well (unlike std::auto_ptr).
The smart pointers of C++ are *not* in any way opaque. In my
external interfaces, I make extensive use of opaque pointers:
void*. That's the only opaque pointer in C++. (But of course,
I don't want opaque pointers internally. They're only used for
information hiding at the boundary level.)
[...]
In my own code, C style arrays will still be more frequent than
std::array. (But this probably is application dependent.)
I have to admit that I also have several C style arrays that are
entirely immutable. It is because they work and I have other things to
worry about.
Most of the time (in my applications, at least), if I'm not
using std::vector, it's because I have a static array with
static initializers, and I want the compiler to count the
initializers for me. Replacing them with std::array won't work.
(And yes, they're always const.)
In other applications... The cost of using an std::vector with
three elements) for the coordinates of a Point3D, when you have
thousands of them, and are constantly copying them, could be
prohibitive. In this case, std::array could be an option
(although I'm not sure what it really buys you over a C style
array with 3 elements).
I am not saying that things can not be made with naked pointers. I know=
very lot of developers who use C as their choice of language. They just
make smaller applications.
The applications I'm talking about where you need mostly raw
pointers tend to be the larger ones.
Efficiency of the C++ alternatives to naked pointers is fine and safety
is better.
It depends on what you're doing. shared_ptr is extremely
dangerous if used inappropriately. And naked pointers are
perfectly safe when used for navigation.
Only shared_ptr and weak_ptr have overhead, other things are
as good as naked pointers. Safety is important because better developers
are very heavily head-hunted. Less experienced guys are more productive=
and make less mistakes without having to deal with naked pointers.
The problem is that smart pointers are in many cases *more*
dangerous than naked pointers. (Especially with auto. Consider
what happens with:
auto objPtr = somePtrVector[i];
If somePtrVector contains unique_ptr, you're in for a surprise.)
--
James