Krita shared pointers usage

[Stefano Bonicatti]

> But Krita is 300k lines (or so) and had about 30 different developers
> working on it at different point of time.

Well to me this is a reason to have the objects lifetime cycle clear so
that a new developer doesn't cause issue with it.
Now you may say the very same thing with raw pointers but i still think
they cause more visibile problems that can be solved during development.
However as we said earlier there's a good approach for this (shared
pointers AND weak pointers, not sharing shared pointers everywhere etc).

> And not only the architecture has never been documented, it changes all
the time, in such a situation, real life
> kicks in, and shared pointers are just better.

I do know what you're talking about and still believe that is somewhat
wrong to come to a point where you have a so large codebase with the
architecture undocumented.. at least on an high level.
Especially since there are a lot of developers, a bit of coordination is
needed.
I would prefer writing documentation for my own sake and the others, to
have a larger base of people that can help, instead of spending more time
on implementing new features with the risk of breaking something, and
complicating even more the architecture, because it's undocumented.
When i approach a new project i usually go around the codebase quite a lot
because i'm curious and often there's no documentation ( :-) ), so i would
prefer, as i already said, having a clear memory management instead of
having unpredictable object lifetime.

But this is me, one of the many, it's not my project so can't say much, if
not what i think.
I won't try to push anyone doing anything and in result be annoying, this
is not my point, i do want to help.

And i still went a bit offtopic as always.. :P

> This is a bug, obviously. It should assert if the weak shared pointer is
not
> valid.

Isn't it better to have the shared pointer to be constructed but null?
I don't think it's always wrong to build a shared pointer from a dead weak
pointer, if it's then possible to check for a null value or do you see
problems with this?

2014-12-20 17:55 GMT+01:00 Cyrille Berger <cberger at cberger.net>:

> On Saturday 20 December 2014 13:58:57 Stefano Bonicatti wrote:
> > In general i think the same as him ->
> > http://www.stroustrup.com/C++11FAQ.html#std-shared_ptr, not only
> because he
> > his who he his, but because it actually make sense what he says about
> > making the object lifetime cycle complex when shared pointer are used so
> > often.
>
> The problem of Stroustrup is that he probably never was involved in a very
> large project involving many people who come and go during the years. So
> what
> he says, he is very sound and good at a theoretical level, and I would
> agree
> that in an ideal world I would follow what he says. And I do for small
> project. But Krita is 300k lines (or so) and had about 30 different
> developers
> working on it at different point of time. And not only the architecture has
> never been documented, it changes all the time, in such a situation, real
> life
> kicks in, and shared pointers are just better.
>
> > Maybe having unique_ptr like pointers and shared pointer passed as const
> > references instead of raw pointer would be better,
> Definitely better. But it make the code a bit less readable, unless you
> introduce a typedef. But is it worth the amount of work? (I guess it could
> be
> a new guideline).
>
> > so that it's more
> > explicit the fact that you should not delete it manually and it's
> cheaper,
> > copy wise and with the ref/deref not happening when passed around in code
> > that shouldn't actually prolong its life.
> > You would still have shared pointers around but it would be much easier
> for
> > the memory leak tracker to keep track on who is really holding the
> memory.
>
> When it comes to memory leak and optimisation, I always advise to first
> use a
> profiler to get information and then find solution. If it shows that their
> are
> actual (major) leak and that the referencing/derefencing is a problem.
> Because
> you may spend month trying to fix that doesn't change anything noticeable
> while
> in the same time you could have fixed actual problems.
>
> > > The idea provided by Qt's shared pointers might be very helpful here
> >
> > (Qt's weak shared pointer doesn't allow dereferencing the pointer until
> > upgrade to a real shared pointer)
> >
> > There are a couple of problems with Krita weak pointers i'm facing
> though:
> > 1) If you pass a dead weak pointer to a shared pointer the check to see
> if
> > the weak pointer is valid is done in an assert only after the shared
> > pointers tries to increase the reference count.
> > This works if the weak pointer internal pointer was set to NULL, because
> > shared pointer ref() function checks for that, but if the weak pointer
> > points to deleted memory.. well ref() behaviour is undefined.
>
> This is a bug, obviously. It should assert if the weak shared pointer is
> not
> valid.
>
> --
> Cyrille Berger Skott
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20141220/0db05133/attachment.html>