Re: [lmi] Non-null smart pointer

[Vadim Zeitlin]

On Mon, 15 Oct 2018 22:15:52 +0000 Greg Chicares <address@hidden> wrote:

GC> On 13/10/2018 22.54, Vadim Zeitlin wrote:
GC> > On Sat, 13 Oct 2018 22:08:48 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> Does lmi need exactly one kind of smart pointer, or more than one?
GC> > 
GC> >  Right now I can't point to any precise place where we need either
GC> > shared_ptr<> or scoped_ptr<> or even unique_ptr<> which can be null. But
GC> > this doesn't mean there any no such places.
GC> 
GC> We can't demonstrate that there are no such places now, or that none will
GC> be introduced in the future. That's a problem.

 Sorry, but why is this a problem? It would only become a problem if/when
we decided to get rid of shared_ptr<> and unique_ptr<> completely
(replacing the later with not_null_unique_ptr<>), but how is it a problem
right now?

GC> > GC> Do all our smart pointers need to be returnable from a function,
GC> > GC> or only some of them? Do any actually need reference counting?
GC> > 
GC> >  I can try to find the definitive answers to these questions, but it's
GC> > going to take some time and, to be honest, I'm not sure why are they
GC> > important. What matters, IMO, is that we want to have a never null owning
GC> > smart pointer which can be returned from a function and that right now we
GC> > don't have such a thing.
GC> 
GC> If we were to design such a thing now, before figuring out what we
GC> actually need, we might later find that our real needs haven't been met.

 Assume that not_null_unique_ptr<> doesn't meet all our needs, i.e. that we
do need shared_ptr<> and/or that we need unique_ptr<> which may ne null.
How would this change that the fact that we do need not_null_unique_ptr<>?

 I think we should start by adding and using not_null_unique_ptr<> in the
places in which it is better suited than unique_ptr<> (and again, we
already know that this is a non-empty set). We know that it won't be able
to replace all instances where different other smart pointers are used, but
so what?

GC> That's a well-defined bucket, independent of lmi's present use of standard
GC> smart pointers. Is gui_ptr<> small enough to show its implementation here?

 It's trivial. I.e. basically it's just

        template <typename T> using gui_ptr = T*;

As I said, I'm not really sure if it's worth using.


GC> >  So, what's the current state of discussion? Do we decide that we
GC> > 
GC> > 1. Want to use not_null<T*>? And, if so, do we want to take some existing
GC> >    implementation or write our own version (which should be simple enough
GC> >    but OTOH why reinvent even a simple wheel?)?
GC> > 
GC> > 2. Want to use not_null_unique_ptr<T*> which would be used for returning 
GC> >    new objects from functions?
GC> > 
GC> > 3. Or need more time to review all the existing (smart) pointer usage in
GC> >    lmi before making the decision?
GC> 
GC> The third. We have several problems:
GC>  - Dereferencing pointers that might be null.
GC>  - Using shared_ptr where unique_ptr would be better.
GC>  - Using smart pointers where concrete references would be better.

 I'll try to look at all the various cases where shared_ptr<> can be
replaced with unique_ptr<>, but I still think it could be better to start
with a low-hanging not_null_unique_ptr<> fruit rather than trying to revise
all pointers used in lmi. This is a worthwhile task, of course, but it will
take a much longer time to complete and in the meanwhile we still will have
to use unique_ptr<> even for pointers that can't be null, which is a pity.

 Regards,
VZ