Over the last week I have been investigating into Bug 361012, on the undo history of the modification of guides. But from the very beginning I mixed up the two terms "guides" and "assistants," so I decided to work on both. The work with guides is a lot simpler and will not be covered here, though.

As I write this post, the master branch of Krita does not create any undo commands for the document. I first added undo commands for adding and removing assistants, which seems the easiest. The editing of them is a bit more difficult, as the dragging operations involve the movement of many "handles," the movable round buttons that define the position of one or more assistants. The source code on master for implementing such actions is quite complicated and involves a great number of cases. It would be another great endeavour to put all these bunches of code into a KUndo2Command. But, another thing I have experimented with and I will be working on will immediately clear the clouds.

So I just thought of the copy-on-write mechanism, and yes, why not? Though COW itself is not actually implemented for the guides, it does seem inspiring. I mean, we can just save a copy of all assistants and, when needed, restore that.

The main problem here is the handles. They are represented as shared pointers in individual assistants and may be shared between different ones (e.g. two perspectives share two corner handles and one side handles). When we take a clone of the list of assistants it will be necessary to keep this kind of relationship. My solution is to use a QMap of pointers, which seems to coincide with the logic of exporting to xml, but I had yet to read that part of the code when writing mine so I did not know about that. The logic is to check, for every handle, whether there is a mapping relationship in the map. If there is, we reuse that handle, and if not, we create a new one with the same position and record that relationship in our QMap.

But some display properties are not to be recorded into the undo history. Such properties include the changing of color, visibility, etc. To resolve this problem, I put these data into a shared pointer and, when we are cloning an assistant for undo/redo, we will reuse that pointer. When we replace the assistant list with the one recorded, all the display properties will remain since the data are shared.

And for the next several weeks I will move onto the Snapshot Docker.

Recently I have been researching into possibilities to make members of KoShape copy-on-write. At first glance, it seems enough to declare d-pointers as some subclass of QSharedDataPointer (see Qt's implicit sharing) and then replace pointers with instances. However, there remain a number of problems to be solved, one of them being polymorphism.

polymorphism and value semantics

In the definition of KoShapePrivate class, the member fill is stored as a QSharedPointer:

QSharedPointer<KoShapeBackground> fill;

There are a number of subclasses of KoShapeBackground, including KoColorBackground, KoGradientBackground, to name just a few. We cannot store an instance of KoShapeBackground directly since we want polymorphism. But, well, making KoShapeBackground copy-on-write seems to have nothing to do with whether we store it as a pointer or instance. So let's just put it here -- I will come back to this question at the end of this post.

d-pointers and QSharedData

The KoShapeBackground heirarchy (similar to the KoShape one) uses derived d-pointers for storing private data. To make things easier, I will here use a small example to elaborate on its use.

derived d-pointer

class AbstractPrivate
{
public:
    AbstractPrivate() : var(0) {}
    virtual ~AbstractPrivate() = default;

    int var;
};

class Abstract
{
public:
    // it is not yet copy-constructable; we will come back to this later
    // Abstract(const Abstract &other) = default;
    ~Abstract() = default;
protected:
    explicit Abstract(AbstractPrivate &dd) : d_ptr(&dd) {}
public:
    virtual void foo() const = 0;
    virtual void modifyVar() = 0;
protected:
    QScopedPointer<AbstractPrivate> d_ptr;
private:
    Q_DECLARE_PRIVATE(Abstract)
};

class DerivedPrivate : public AbstractPrivate
{
public:
    DerivedPrivate() : AbstractPrivate(), bar(0) {}
    virtual ~DerivedPrivate() = default;

    int bar;
};

class Derived : public Abstract
{
public:
    Derived() : Abstract(*(new DerivedPrivate)) {}
    // it is not yet copy-constructable
    // Derived(const Derived &other) = default;
    ~Derived() = default;
protected:
    explicit Derived(AbstractPrivate &dd) : Abstract(dd) {}
public:
    void foo() const override { Q_D(const Derived); cout << "foo " << d->var << " " << d->bar << endl; }
    void modifyVar() override { Q_D(Derived); d->var++; d->bar++; }
private:
    Q_DECLARE_PRIVATE(Derived)
};

The main goal of making DerivedPrivate a subclass of AbstractPrivate is to avoid multiple d-pointers in the structure. Note that there are constructors taking a reference to the private data object. These are to make it possible for a Derived object to use the same d-pointer as its Abstract parent. The Q_D() macro is used to convert the d_ptr, which is a pointer to AbstractPrivate to another pointer, named d, of some of its descendent type; here, it is a DerivedPrivate. It is used together with the Q_DECLARE_PRIVATE() macro in the class definition and has a rather complicated implementation in the Qt headers. But for simplicity, it does not hurt for now to understand it as the following:

#define Q_D(Class) Class##Private *const d = reinterpret_cast<Class##Private *>(d_ptr.data())

where Class##Private means simply to append string Private to (the macro argument) Class.

Now let's test it by creating a pointer to Abstract and give it a Derived object:

int main()
{
    QScopedPointer<Abstract> ins(new Derived());
    ins->foo();
    ins->modifyVar();
    ins->foo();
}

Output:

foo 0 0
foo 1 1

Looks pretty viable -- everything's working well! -- What if we use Qt's implicit sharing? Just make AbstractPrivate a subclass of QSharedData and replace QScopedPointer with QSharedDataPointer.

making d-pointer QSharedDataPointer

In the last section, we commented out the copy constructors since QScopedPointer is not copy-constructable, but here QSharedDataPointer is copy-constructable, so we add them back:

class AbstractPrivate : public QSharedData
{
public:
    AbstractPrivate() : var(0) {}
    virtual ~AbstractPrivate() = default;

    int var;
};

class Abstract
{
public:
    Abstract(const Abstract &other) = default;
    ~Abstract() = default;
protected:
    explicit Abstract(AbstractPrivate &dd) : d_ptr(&dd) {}
public:
    virtual void foo() const = 0;
    virtual void modifyVar() = 0;
protected:
    QSharedDataPointer<AbstractPrivate> d_ptr;
private:
    Q_DECLARE_PRIVATE(Abstract)
};

class DerivedPrivate : public AbstractPrivate
{
public:
    DerivedPrivate() : AbstractPrivate(), bar(0) {}
    virtual ~DerivedPrivate() = default;

    int bar;
};

class Derived : public Abstract
{
public:
    Derived() : Abstract(*(new DerivedPrivate)) {}
    Derived(const Derived &other) = default;
    ~Derived() = default;
protected:
    explicit Derived(AbstractPrivate &dd) : Abstract(dd) {}
public:
    void foo() const override { Q_D(const Derived); cout << "foo " << d->var << " " << d->bar << endl; }
    void modifyVar() override { Q_D(Derived); d->var++; d->bar++; }
private:
    Q_DECLARE_PRIVATE(Derived)
};

And testing the copy-on-write mechanism:

int main()
{
    QScopedPointer<Derived> ins(new Derived());
    QScopedPointer<Derived> ins2(new Derived(*ins));
    ins->foo();
    ins->modifyVar();
    ins->foo();
    ins2->foo();
}

But, eh, it's a compile-time error.

error: reinterpret_cast from type 'const AbstractPrivate*' to type 'AbstractPrivate*' casts away qualifiers
 Q_DECLARE_PRIVATE(Abstract)

Q_D, revisited

So, where does the const removal come from? In qglobal.h, the code related to Q_D is as follows:

template <typename T> inline T *qGetPtrHelper(T *ptr) { return ptr; }
template <typename Ptr> inline auto qGetPtrHelper(const Ptr &ptr) -> decltype(ptr.operator->()) { return ptr.operator->(); }

// The body must be a statement:
#define Q_CAST_IGNORE_ALIGN(body) QT_WARNING_PUSH QT_WARNING_DISABLE_GCC("-Wcast-align") body QT_WARNING_POP
#define Q_DECLARE_PRIVATE(Class) \
    inline Class##Private* d_func() \
    { Q_CAST_IGNORE_ALIGN(return reinterpret_cast<Class##Private *>(qGetPtrHelper(d_ptr));) } \
    inline const Class##Private* d_func() const \
    { Q_CAST_IGNORE_ALIGN(return reinterpret_cast<const Class##Private *>(qGetPtrHelper(d_ptr));) } \
    friend class Class##Private;

#define Q_D(Class) Class##Private * const d = d_func()

It turns out that Q_D will call d_func() which then calls an overload of qGetPtrHelper() that takes const Ptr &ptr. What does ptr.operator->() return? What is the difference between QScopedPointer and QSharedDataPointer here?

QScopedPointer's operator->() is a const method that returns a non-const pointer to T; however, QSharedDataPointer has two operator->()s, one being const T* operator->() const, the other T* operator->(), and they have quite different behaviours -- the non-const variant calls detach() (where copy-on-write is implemented), but the other one does not.

qGetPtrHelper() here can only take d_ptr as a const QSharedDataPointer, not a non-const one; so, no matter which d_func() we are calling, we can only get a const AbstractPrivate *. That is just the problem here.

To resolve this problem, let's replace the Q_D macros with the ones we define ourselves:

#define CONST_SHARED_D(Class) const Class##Private *const d = reinterpret_cast<const Class##Private *>(d_ptr.constData())
#define SHARED_D(Class) Class##Private *const d = reinterpret_cast<Class##Private *>(d_ptr.data())

We will then use SHARED_D(Class) in place of Q_D(Class) and CONST_SHARED_D(Class) for Q_D(const Class). Since the const and non-const variant really behaves differently, it should help to differentiate these two uses. Also, delete Q_DECLARE_PRIVATE since we do not need them any more:

class AbstractPrivate : public QSharedData
{
public:
    AbstractPrivate() : var(0) {}
    virtual ~AbstractPrivate() = default;

    int var;
};

class Abstract
{
public:
    Abstract(const Abstract &other) = default;
    ~Abstract() = default;
protected:
    explicit Abstract(AbstractPrivate &dd) : d_ptr(&dd) {}
public:
    virtual void foo() const = 0;
    virtual void modifyVar() = 0;
protected:
    QSharedDataPointer<AbstractPrivate> d_ptr;
};

class DerivedPrivate : public AbstractPrivate
{
public:
    DerivedPrivate() : AbstractPrivate(), bar(0) {}
    virtual ~DerivedPrivate() = default;

    int bar;
};

class Derived : public Abstract
{
public:
    Derived() : Abstract(*(new DerivedPrivate)) {}
    Derived(const Derived &other) = default;
    ~Derived() = default;
protected:
    explicit Derived(AbstractPrivate &dd) : Abstract(dd) {}
public:
    void foo() const override { CONST_SHARED_D(Derived); cout << "foo " << d->var << " " << d->bar << endl; }
    void modifyVar() override { SHARED_D(Derived); d->var++; d->bar++; }
};

With the same main() code, what's the result?

foo 0 0
foo 1 16606417
foo 0 0

... big whoops, what is that random thing there? Well, if we use dynamic_cast in place of reinterpret_cast, the program simply crashes after ins->modifyVar();, indicating that ins's d_ptr.data() is not at all a DerivedPrivate.

virtual clones

The detach() method of QSharedDataPointer will by default create an instance of AbstractPrivate regardless of what the instance really is. Fortunately, it is possible to change that behaviour through specifying the clone() method.

First, we need to make a virtual function in AbstractPrivate class:

virtual AbstractPrivate *clone() const = 0;

(make it pure virtual just to force all subclasses to re-implement it; if your base class is not abstract you probably want to implement the clone() method) and then override it in DerivedPrivate:

virtual DerivedPrivate *clone() const { return new DerivedPrivate(*this); }

Then, specify the template method for QSharedDataPointer::clone(). As we will re-use it multiple times (for different base classes), it is better to define a macro:

#define DATA_CLONE_VIRTUAL(Class) template<>                      \
    Class##Private *QSharedDataPointer<Class##Private>::clone()   \
    {                                                             \
        return d->clone();                                        \
    }
// after the definition of Abstract
DATA_CLONE_VIRTUAL(Abstract)

It is not necessary to write DATA_CLONE_VIRTUAL(Derived) as we are never storing a QSharedDataPointer<DerivedPrivate> throughout the heirarchy.

Then test the code again:

foo 0 0
foo 1 1
foo 0 0

-- Just as expected! It continues to work if we replace Derived with Abstract in QScopedPointer:

QScopedPointer<Abstract> ins(new Derived());
QScopedPointer<Abstract> ins2(new Derived(* dynamic_cast<const Derived *>(ins.data())));

Well, another problem comes, that the constructor for ins2 seems too ugly, and messy. We could, like the private classes, implement a virtual function clone() for these kinds of things, but it is still not gentle enough, and we cannot use a default copy constructor for any class that contains such QScopedPointers.

What about QSharedPointer that is copy-constructable? Well, then these copies actually point to the same data structures and no copy-on-write is performed at all. This still not wanted.

the Descendents of ...

Inspired by Sean Parent's video, I finally come up with the following implementation:

template<typename T>
class Descendent
{
    struct concept
    {
        virtual ~concept() = default;
        virtual const T *ptr() const = 0;
        virtual T *ptr() = 0;
        virtual unique_ptr<concept> clone() const = 0;
    };
    template<typename U>
    struct model : public concept
    {
        model(U x) : instance(move(x)) {}
        const T *ptr() const { return &instance; }
        T *ptr() { return &instance; }
        // or unique_ptr<model<U> >(new model<U>(U(instance))) if you do not have C++14
        unique_ptr<concept> clone() const { return make_unique<model<U> >(U(instance)); }
        U instance;
    };

    unique_ptr<concept> m_d;
public:
    template<typename U>
    Descendent(U x) : m_d(make_unique<model<U> >(move(x))) {}

    Descendent(const Descendent & that) : m_d(move(that.m_d->clone())) {}
    Descendent(Descendent && that) : m_d(move(that.m_d)) {}

    Descendent & operator=(const Descendent &that) { Descendent t(that); *this = move(t); return *this; }
    Descendent & operator=(Descendent && that) { m_d = move(that.m_d); return *this; }

    const T *data() const { return m_d->ptr(); }
    const T *constData() const { return m_d->ptr(); }
    T *data() { return m_d->ptr(); }
    const T *operator->() const { return m_d->ptr(); }
    T *operator->() { return m_d->ptr(); }
};

This class allows you to use Descendent<T> (read as "descendent of T") to represent any instance of any subclass of T. It is copy-constructable, move-constructable, copy-assignable, and move-assignable.

Test code:

int main()
{
    Descendent<Abstract> ins = Derived();
    Descendent<Abstract> ins2 = ins;
    ins->foo();
    ins->modifyVar();
    ins->foo();
    ins2->foo();
}

It gives just the same results as before, but much neater and nicer -- How does it work?

First we define a class concept. We put here what we want our instance to satisfy. We would like to access it as const and non-const, and to clone it as-is. Then we define a template class model<U> where U is a subclass of T, and implement these functionalities.

Next, we store a unique_ptr<concept>. The reason for not using QScopedPointer is QScopedPointer is not movable, but movability is a feature we actually will want (in sink arguments and return values).

Finally it's just the constructor, moving and copying operations, and ways to access the wrapped object.

When Descendent<Abstract> ins2 = ins; is called, we will go through the copy constructor of Descendent:

Descendent(const Descendent & that) : m_d(move(that.m_d->clone())) {}

which will then call ins.m_d->clone(). But remember that ins.m_d actually contains a pointer to model<Derived>, whose clone() is return make_unique<model<Derived> >(Derived(instance));. This expression will call the copy constructor of Derived, then make a unique_ptr<model<Derived> >, which calls the constructor of model<Derived>:

model(Derived x) : instance(move(x)) {}

which move-constructs instance. Finally the unique_ptr<model<Derived> > is implicitly converted to unique_ptr<concept>, as per the conversion rule. "If T is a derived class of some base B, then std::unique_ptr<T> is implicitly convertible to std::unique_ptr<B>."

And from now on, happy hacking --- (.>w<.)

GSoC 2019

Posted on kdekrita

This summer will be a little bit interesting as I joined the Google Summer of Code (GSoC). The software I will be working on is Krita. Krita is a painting software I have been using for more than one year. Since the (pre)release of Krita 4.0, I use it to paint all my works.

Before using Krita, I used to use PaintToolSAI, and there are quite a lot of concepts and functionalities in it that I find really useful; after getting involved in the Krita community I am pretty lucky to be able to introduce these little shiny stars to our community, and even implement some of them.

My project for GSoC is on the undo/redo system in Krita. The system currently works using an undo stack to storage individual changes to the document, and invoking these commands to perform undos and redos. This system is complex and not easy to maintain. As Dmitry suggests, a better solution would be storing the states of the document as shallow copies, since it simplifies the system and make history brushes possible. It would be a rather huge and fundamental change in the code, and he recommends me to experiment with vector layers first.

Another part of the project, which is not a research, is the snapshot docker that would allow users to temporarily save some states of the document and return to them quickly at a later time. This is an enhancement on the GUI level, as the tile data in paint layers are shallow copied, making it possible to make a clone of the document relatively fast.

I will make more posts on KDE and Krita in the near future. Let's keep in touch! (.w.)

没赶上报名截止日期,一直 not invited。就很难过。

E 的题目描述是这样的。

Description

tz学姐做题很忙,有一些简单的问题需要你帮忙解决:给定三个序列A,B,C和一个整数X, 现在需要找到三个数Ai,Bj,Ck,满足Ai+Bj+Ck = X.

Input

第1行三个整数 L, N, M;

第2行L个整数代表序列A

第3行M个整数代表序列B

第4行N个整数代表序列C

第5行1个整数S代表有S个X。

接下来的S行每行一个整数X

1<=L, N, M<=500, 1<=S<=1000. 所有整数均在32位整数范围内

Output

对于S个询问计算X对应的公式是否能被满足。 如能满足,输出 "YES", 否则输出 "NO"。

Sample Input

3 3 3
1 2 3
1 2 3
1 2 3
3
1
4
10

Sample Output

NO
YES
NO

我当时给出的代码是这样的。

#include <iostream>
#include <algorithm>
using namespace std;
int main() {
  int l,m,n;
  cin>>l>>m>>n;
  int a[l],b[m],c[n];
  for(int&p:a)cin>>p;
  for(int&p:b)cin>>p;
  for(int&p:c)cin>>p;
  sort(c,c+n);
  cin>>n;
  for(int p;cin>>p;){
    for(int q:a)
      for(int r:b)
        if(binary_search(c,c+n,p-q-r)) {
          cout<<"YES\n";
          goto l;
        }
    cout<<"NO\n";
  l:1;
  }
}
//292

由于我不能提交,无法判断它是否超时了。查了一下网上的做法,是把 ab 加起来存到另一个数组里,然后对这个新的数组排序查找。

仔细分析一下就是:

我的方法,排序用了 O(n*log n),查找 O(n**2*log n)

另一个做法,排序 O(n**2*log n),查找 O(n*log n)

看上去好像正好抵消了没什么区别。问题在于查找是多次查找,我们希望每次查找的时间尽量短。

所以改过的代码是这样的:

#include <iostream>
#include <algorithm>
using namespace std;
int main() {
  int l,m,n,r=0;
  cin>>l>>m>>n;
  int a[l],b[m],c[n],S[l*m]; // GNU 扩展的变长数组
  for(int&p:a)cin>>p;
  // range-for 输入第二组数据,同时将输入的数据和第一组的每一个数字相累加,结果存到 `S` 里。
  for(int&p:b) {
    cin>>p;
    for(int&q:a)S[r++]=p+q;
  }
  for(int&p:c)cin>>p;
  sort(S,S+r);
  cin>>n; // 丢弃个数信息,因为不需要
  for(int p;cin>>p;){
    for(int q:c)
      if(binary_search(S,S+r,p-q)){
        puts("YES");
        goto l; // 直接跳到下次输入,不输出 NO
      }
    puts("NO");
  l:1;
  }
}
//311

排名表上最短是345。

但是有什么用呢。我又不能提交(以后一定要提前关注一下)。