«

On Sunday, 17 March 2013 01:01:18 UTC+2, Paavo Helde wrote:
> Also, a raw pointer is only needed if it can be NULL or must support
> reseating, otherwise one should use references to reduce the complexity
> of the code. For example, navigation could often be done via references
> only. Not quite sure if Tiib or James included references in the notion
> of naked pointers or not.

Reference is not pointer because it is not so loose. Reference is great
as function parameter or for naming and extending life-span of temporary
in code. As data member it is useful if there is need to store a reference
to a composite in component. The only dangerous usage of reference is as
return value and that is fault of compilers. All cases of returning
reference to a local or temporary must be very apparent to compilers,
so compiling such things silently feels criminal.

Öö Tiib wrote:

> Why? For navigation there are usually iterators.

Iterators aren't automatically generated in custom classes/containers. In
those cases, pointers are either used directly (no need to waste time adding
and debugging custom iterators/generators) or indirectly (shoved under the
hood).

Plus, pointers are a fundamental type. Increasing the complexity of a piece
of software is only justified if something really good can come out of it.
When complexity is mindlessly added for no reason whatsoever and with
dubious returns then we are wasting our time (and other people's time as
well) with counterproductive practices.

People involved in software development should always bear in mind that
ultimately the job of a software developer is to manage complexity.
Mindlessly advocating alternatives which are needlessly complex over the
simplest alternatives may well be the exact opposite of what is expected
from a competetent software developer.


Rui Maciel

On Sunday, 17 March 2013 09:41:26 UTC+2, Rui Maciel wrote:
> Öö Tiib wrote:
> > Why? For navigation there are usually iterators.
>
> Iterators aren't automatically generated in custom classes/containers. In
> those cases, pointers are either used directly (no need to waste time adding
> and debugging custom iterators/generators) or indirectly (shoved under the
> hood).

Iterator on common case is not "shoving pointer under hood" but "erasing all the
broken interface" of pointer and "replacing it with useful interface". It is well
worth the time and the tests are trivial. Not doing it is like not erasing copy
constructor and assignment operator from a class that is not meant to be
copyable.

> Plus, pointers are a fundamental type. Increasing the complexity of a piece
> of software is only justified if something really good can come out of it..
> When complexity is mindlessly added for no reason whatsoever and with
> dubious returns then we are wasting our time (and other people's time as
> well) with counterproductive practices.

Complexity can not be added by erasing complexity. Complexity can be added
by not following rule of three. Complexity can be added by not following RAII.
Complexity can be added by not caring about thread or exception safety.
Complexity can be added by exposing naked pointers.

> People involved in software development should always bear in mind that
> ultimately the job of a software developer is to manage complexity.

Exactly. Easiest way to manage it is to erase most things that mean undefined
behavior from the interface of a class or a module. Every pointer has majority
of its interface either very confusing or undefined behavior.

> Mindlessly advocating alternatives which are needlessly complex over the
> simplest alternatives may well be the exact opposite of what is expected
> from a competetent software developer.

Exactly. Mindlessly advocating exposure of needlessly complex and error prone
constructs is unexpected from "competetent" software developer. Pointer is the
thing in C++ that is on most cases the very reason behind software defects.

Öö Tiib wrote:

> On Sunday, 17 March 2013 09:41:26 UTC+2, Rui Maciel wrote:
>> Öö Tiib wrote:
>> > Why? For navigation there are usually iterators.
>>
>> Iterators aren't automatically generated in custom classes/containers.
>> In those cases, pointers are either used directly (no need to waste time
>> adding and debugging custom iterators/generators) or indirectly (shoved
>> under the hood).
>
> Iterator on common case is not "shoving pointer under hood" but "erasing
> all the broken interface" of pointer

This is obviously false, because even standard C++ iterators were defined
with the express purpose of mimicking C++ pointers.

> and "replacing it with useful
> interface". It is well worth the time and the tests are trivial. Not doing
> it is like not erasing copy constructor and assignment operator from a
> class that is not meant to be copyable.

Its cruft that needlessly needs to be added, and an extra abstraction layer
that needs to be tested in validated. Worse, it's one which is designed to
mimic the pointer syntax. So, in essence, it requires time and effort to
end up precisely where you were already. That's pretty much the definition
of an anti-pattern.

In addition, C++11 introduced standard language features which already
support fundamental data types, such as pointers and references, as
iterators.


>> Plus, pointers are a fundamental type. Increasing the complexity of a
>> piece of software is only justified if something really good can come out
>> of it. When complexity is mindlessly added for no reason whatsoever and
>> with dubious returns then we are wasting our time (and other people's
>> time as well) with counterproductive practices.
>
> Complexity can not be added by erasing complexity.

You don't erase complexity by shoving cruft to a module by needlessly
implementing interfaces which are redundant and useless.


>> People involved in software development should always bear in mind that
>> ultimately the job of a software developer is to manage complexity.
>
> Exactly. Easiest way to manage it is to erase most things that mean
> undefined behavior from the interface of a class or a module. Every
> pointer has majority of its interface either very confusing or undefined
> behavior.

Pointers are one of C++'s fundamental types. They are one of the first
things that are taught to C++ programmers in any programming101 course,
right after introducing hello world. References are more complex and are
more nuanced than pointers, and nevertheless newbies tend to grasp the
basics with little to no effort whatsoever.

If someone who claims to be a C++ programmer states that they find pointers
to be "very confusing" then that person's competency is rather questionable.


>> Mindlessly advocating alternatives which are needlessly complex over the
>> simplest alternatives may well be the exact opposite of what is expected
>> from a competetent software developer.
>
> Exactly. Mindlessly advocating exposure of needlessly complex and error
> prone constructs is unexpected from "competetent" software developer.
> Pointer is the thing in C++ that is on most cases the very reason behind
> software defects.

There are bugs of all sorts. If someone managed to find a bug which
involved iterators, that would say nothing about about iterators as a
feature.

You may find pointers to be "very confusing", and thus prefer to run away
from them like they were the plague instead of simply doing what every C++
did at one point in his life and learn about them. Yet, that doesn't mean
that somehow they are the bane of every living C++ programmer. Far from it.
In some cases there might be alternatives which are more appropriate, but in
other cases using a pointer is perfectly fine, and it may even be the best
possible way to go.

Knowing what we're doing is always a better option than basing a set of
beliefs in a set of arguments which are entire irrational and baseless.


Rui Maciel

On Sunday, 17 March 2013 19:27:51 UTC+2, Rui Maciel wrote:
> Öö Tiib wrote:
> > Iterator on common case is not "shoving pointer under hood" but "erasing
> > all the broken interface" of pointer
>
> This is obviously false, because even standard C++ iterators were defined
> with the express purpose of mimicking C++ pointers.

Are you joking? Why to make more pointers?

> > and "replacing it with useful
> > interface". It is well worth the time and the tests are trivial. Not doing
> > it is like not erasing copy constructor and assignment operator from a
> > class that is not meant to be copyable.
>
> Its cruft that needlessly needs to be added, and an extra abstraction layer
> that needs to be tested in validated.

Erasing constructor and assignment operator from non-copyable is cruft or
adding iterators to containers is cruft?

> > Complexity can not be added by erasing complexity.
>
> You don't erase complexity by shoving cruft to a module by needlessly
> implementing interfaces which are redundant and useless.

Go propose then to erase that "cruft" from standard library.

> > Exactly. Easiest way to manage it is to erase most things that mean
> > undefined behavior from the interface of a class or a module. Every
> > pointer has majority of its interface either very confusing or undefined
> > behavior.
>
> If someone who claims to be a C++ programmer states that they find pointers
> to be "very confusing" then that person's competency is rather questionable.

I did not say that pointers are confusing. Read again.

Every pointer is used in one of several roles. Pointer that is used for storing
address of first element of array, pointer that is used for storing addressof
optional object, pointer that is used to store address to polymorphic interface
of object, etc. I said that if pointer is in one of such roles then most ofits
*interface* (meant for other roles) is very clearly *undefined* *behavior* or
its usage is very confusing when it is not undefined behavior.

For example if 'p' is pointer to polymorphic base sub-object then yes you can
convert it to reference to that sub-object by using 'p[0]' but that is very
confusing to anyone reading your code.

> Knowing what we're doing is always a better option than basing a set of
> beliefs in a set of arguments which are entire irrational and baseless.

It is you who push here emotional nonsense about how non-mindless
competent, rational, adequate and what not you are without iterators and
how pointless, mindless, irrational and baseless cruft are iterators and
anyone suggesting those.

Take a breath, look at things clearly for a moment. Iterators are fine.
Iterators do not mimic pointers. Iterators are for navigation in containers.. I
do not know where iterators did hurt you but ... your iteratorphobia is
quite ... uncommon.

On Saturday, 16 March 2013 22:24:37 UTC, Ian Collins wrote:
> James Kanze wrote:
> > On Saturday, March 16, 2013 4:56:16 PM UTC, Öö Tiib wrote:
> >> On Saturday, 16 March 2013 17:55:23 UTC+2, Seungbeom Kim 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. Smart pointers have they uses, but they still
> > correspond to exceptional cases, rather than the usual case.

> One of the most common constructs in my code is containers of smart
> pointers, so I don't see from where you derive that generalisation.

What's a legitimate use case for containers of smart pointers?
I can think of one, off hand, but it's a very special case, only
relevant when implementing Excel plug-ins. There are a few
others. But by far the most frequent use of containers of
pointers is for navigation, in which case, raw pointers are more
appropriate.

In general, use of smart pointers is an advanced technique.
std::shared_ptr is particularly tricky to use correctly; I tend
to avoid it except in special circumstances.

--
James

On Saturday, 16 March 2013 22:35:44 UTC, Öö 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, Öö 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 allows
> 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.

> >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.)

--
James

James Kanze wrote:
> On Saturday, 16 March 2013 22:24:37 UTC, Ian Collins wrote:
>> James Kanze wrote:
>>> On Saturday, March 16, 2013 4:56:16 PM UTC, Öö Tiib wrote:
>>>> On Saturday, 16 March 2013 17:55:23 UTC+2, Seungbeom Kim 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. Smart pointers have they uses, but they still
>>> correspond to exceptional cases, rather than the usual case.
>
>> One of the most common constructs in my code is containers of smart
>> pointers, so I don't see from where you derive that generalisation.
>
> What's a legitimate use case for containers of smart pointers?
> I can think of one, off hand, but it's a very special case, only
> relevant when implementing Excel plug-ins. There are a few
> others. But by far the most frequent use of containers of
> pointers is for navigation, in which case, raw pointers are more
> appropriate.

In my case, XML DOM and JSON objects.

I also do a lot of parsing and processing with LDAP data. In the this
case, entries are shared between containers,

> In general, use of smart pointers is an advanced technique.
> std::shared_ptr is particularly tricky to use correctly; I tend
> to avoid it except in special circumstances.

It is the most convenient tool to implement DOM, where nodes can appear
in multiple lists.

--
Ian Collins

On Monday, 18 March 2013 19:25:35 UTC+2, James Kanze wrote:
> On Saturday, 16 March 2013 22:35:44 UTC, Öö 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, Öö 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 allows
> > 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.
* 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.
* Classes that navigate all over the place (like Visitor) usually use
references. like 'visit(CocncreteObject&)' to avoid pointless
nullptr navigations.
* 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.

> > >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.
There must be some special issue that I haven't met.
C style array is not needed with std::array<>. Need for optional
arguments can be first reduced with overloads that do not have
the argument. The smart pointers are as optional as naked
pointers. There are various "optional" and "fallible" templates
too for pass-by-value cases. Very rarely happening failures
can be cheaper to signal using exceptions.

On 3/18/2013 6:20 PM, James Kanze wrote:
> What's a legitimate use case for containers of smart pointers?

When you want a polymorphic collection.