Re: printing in C++
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 should
be raw pointers.
Why? For navigation there are usually iterators. While standard allow=
s
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).
There are often containers with pointers to the object, to
implement 1->n relationships. But these would contain raw
pointers.
* 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.
* Classes that navigate all over the place (like Visitor) usually use
references. like 'visit(CocncreteObject&)' to avoid pointless
nullptr navigations.
I'm not talking about the sort of navigation vistors do. These
are short lived objects, and I don't think it would occur to
anyone to use smart pointers here. In the unlikely case where
you might want to assign vistors, then you might use raw
pointers, so that you could support assignment, but generally,
vistors are polymorphic and noncopyable, so references are just
fine.
* 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).
Smart pointers have they uses, but they still
correspond to exceptional cases, rather than the usual case.
Pointer has several usages: container (array), iterator of container,=
optional object and for polymorphic object. It is best alternative=
for none of the tasks.
Pointers are mainly used for navigation (or not used at all).
There are exceptions: polymorphic objects, and iterating over
C style arrays, and optional arguments (or unsuccessful return
values) are good examples. In the case of temporary polymorphic
objects, smart pointers often are appropriate. But certainly
*not* in the other two cases. (And short lived polymorphic
objects aren't that common.)
I see no problems with polymorphic objects and smart pointers.
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.
There must be some special issue that I haven't met.
C style array is not needed with std::array<>.
String literals are *not* std::array<> (nor std::string). And
std::array<> doesn't allow the compiler to count the
initializers, and determine the length without me counting them.
In my own code, C style arrays will still be more frequent than
std::array. (But this probably is application dependent.)
--
James