Quote Originally Posted by TriKri View Post
Hm, that makes sense, better getting the constructs right the first time than getting them wrong and having to live with them forever.
And no API is perfect, sometimes less then ideal API is kept as changing it would otherwise have massive impact on existing code.

Your idea of using instance copying for keeping states is quite good IMHO from a readability point of view, though it might also require a different approach in savind/restoring state then


Quote Originally Posted by TriKri View Post
If I ever write such a wrapper, I will consider contributing with it.
Excellent :-)
I've never actually considered that until you brought it up.

It is small improvements like this that allow a framework to evolve rather than to stagnate.

Quote Originally Posted by TriKri View Post
Not at all – what should get modified is the thing you paint on, and I don't see why the thing you paint with should be modified?
Theoretically true, the paint device is held by pointer and the pointer value doesn't change so the QPainter method could call non-const paint device methods.

Maybe there are even compilers which generated warnings for this or it was done for consistency (methods starting with an imperative verb usually do change the state of the object they are invoked on)

Cheers,
_