Re: [Development] The future of smart pointers in Qt API

[Daniel Teske]

Am 04.02.2020 um 17:47 schrieb Volker Hilsheimer:

On 4 Feb 2020, at 16:12, Ville Voutilainen  wrote:

On Tue, 4 Feb 2020 at 15:40, Volker Hilsheimer  wrote:

This works, but now you are encoding the visual hierarchy of the widgets in two 
places: when asking the presumed parent to create the widgets; and when setting 
up the layout, which might do things differently (esp once you start 
refactoring complex UIs).#

That's not a problem. The code simply behaves as if you would have used the 
current constructors that take a parent parameter.

Ownership transfers between different qt parents don't violate the invariant. 
And they continue to work just like before.


So how is the above usage of makeChild an improvement over calling operator new 
to instantiate your objects?



It's also clearer to see the parent child relationship.

And it switches what the easiest way to construct a object is. Currently 
it's less code to create a object without a parent, whereas with my 
patch and the deprecation enabled the easiest way to handle qt objects 
is via makeChild.





But that just means that QBoxLayout::addWidget(std::unique_ptr<>) has to behave 
imho saner in that edge case and actually delete the widgets that were added but 
never parented. (And I should really implement that to show how it would work.)


That seems like a terrible idea. One of the layout’s jobs is to set up the 
parent/child hierarchy so that you as a developer don’t have to.

I don't see how that idea changes that.


Iif the layout deletes widgets that were created without parent, instead of 
adding it to the correct parent, then that’s a change. You have to create 
widgets with parents, and add them to the layout (which might then add it to 
another parent, which at the very least introduces unnecessary overhead of 
ChildAdded/Removed event processing).


I didn't explain the behaviour well enough, so sorry for the confussion.

The layout takes care of the child widgets only if it never parented the 
widgets.


If the layout parented the widgets, either in setLayout or because the 
layout already had a parent, then those widgets are owned by the parent 
widget not by the layout. Or because the layout was added to a different 
layout that has a parent.


Essentially, if in the layout dtor the widgets don't have a parent, then 
those widgets are owned by the layout.


And I'm open to only do that for those widgets that were explicitly 
moved into the layout, though I have a slight preference to changing the 
existing behaviour.






Do we really want to make it harder for people to write UIs just because the 
resulting code doesn’t satisfy a C++ idiom?

It's not a question of satisfying idioms for the sake of satisfying
idioms, it's a question of avoiding bugs that we know
based on decades of experience to be difficult to avoid with raw pointers.


That’s my point:

I do not believe that the decades of experience we have with QObject’s 
parent/child model support the claim that it is inferior to using 
smart-pointers. It’s not something people constantly struggle with.


The problem is that you have to actually know what every method does, 
which isn't always obvious and is not always documented.





That doesn’t invalidate the suggestion that we should use smart pointers in Qt 
code, or in Qt APIs where we are not benefitting from QObject trees.



If you don’t care about the things that QObject/QWidget does for you, then 
don’t use QObject/QWidget. And if you do use QObject/QWidget and get a 
consistent object model from it, then I’m really not convinced that adding 
smart pointers to the API is making the code clearer, or in any way more 
explicit. It’s not like the ability of using std::unique_ptr means that people 
no longer have to be familiar with Qt’s basic concepts to use it correctly.

Correct, but if code moves a std::unique_ptr into a function call
argument, I know that ownership is transferred, by just glancing at
the code. With a raw pointer, I don't know that.


But ownership isn’t transferred if you call QLayout::addWidget; it is never 
transferred to the layout object - it might be transferred to the QWidget that 
the layout operates on.


Well, that's a matter of perspective. With the API I outlined, ownership 
is indeed transferred to the layout, which then either a) immediately 
transfers it to the widget, b) transfers it later on e.g. setLayout, c) 
if neither happens the layout owns the widgets.


Now, it's worth reiterating that this is a edge case. This is only about 
layouts that never ever get added to a widget hierarchy. That should be 
rare.


daniel
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Daniel Teske]

Am 04.02.2020 um 13:22 schrieb Konstantin Shegunov:
On Tue, Feb 4, 2020 at 12:15 PM Vitaly Fanaskov > wrote:


I think, if we decide to re-implement parent-child model using smart
pointers, we would not use unique pointers at all. Even in a methods
like QObject::makeChild (because ownership is already defined).
Shared +
weak pointers make perfect sense here.


You have to be really crafty. Allocating on the stack is a thing, you 
know, even for parent-child trees, so how do you intend to handle 
that? Are we again in "forget the stack and new everything" land?


Same as before, in essence a stack object is equivalent to a unique_ptr 
object.


Thus:

There's no problem with having a QObjects without a parent on the 
stack/in a unique_ptr.


A QObject with a parent on the stack/unique_ptr is double owned and thus 
a problem. The severity of that problem is arguably worse with a unique_ptr.


Where my patch improves this situation is that the object ctors taking a 
parent ptr are all marked with a optional deprecation, thus if you opt 
into that, you'll get a warning for the second case even for the stack 
allocation.


And yes this contrary to very crafty code that allocates objects in the 
right order on the stack, but that has never been the recommend way to 
use Qt.


daniel

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Daniel Teske]

Am 04.02.2020 um 07:53 schrieb Shawn Rutledge:


On 1 Feb 2020, at 19:20, Daniel Teske <mailto:q...@squorn.de>> wrote:


Now to take your next example: setParent is not fine. setParent can 
be used in 4 different ways:


child->setParent(child->parent()): Invariant holds
child->setParent(newParent): Invariant holds
child->setParent(nullptr): Nope
orphan->setParent(parent): Nope

The solution is I have is to replace setParent with two functions: 
adoptChild + releaseChild, which both ensure that the invariant 
always holds.


And to deprecate setParent. ...

In Qt Quick we plan to have a unified ownership tree in Qt 6: visual 
parent item will be the same as QObject parent.  (Whereas in Qt 5, 
QQuickItem::setParentItem() sets a different pointer.)  And 
Item.parent is a property, so it’s expected to be able to reparent a 
subtree of Items by setting its parent to a different one.  How do you 
think that should be handled?


You snipped out the relevant part that explains that there are new 
methods: adoptChild + releaseChild. So I don't see any problem?


daniel

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Daniel Teske]

Hi Daniel,

I like many things in this proposal, especially the principles; thanks for that!

Where I’m on the fence is the replacing of setParent with “adoptChild”. I think 
of “parent” as a property of an object, so setParent/parent accessors are the 
API that fits into my mental model. I have a hard time thinking about “list of 
children” as that property..


Well this should not compile. (Or rather be optionally deprecated.)

unique_ptr<> a;
a->setParent(b);




But I think the example below shows exactly the problem 


Now for some classes the parent ptr has additional meaning beyond just being 
the owner. E.g. for the layout classes. For that reason there's a bit of 
infrastructure, which makes this work:

parent->makeChild();

or to take a more complex example:

parent->makeChild("Hello World!");

(The infrastructure is a third constructor, and a forwarding function defined 
via Q_OBJECT)

For example, converting some random code on 
https://doc.qt.io/qt-5/qtwidgets-widgets-lineedits-example.html to use 
makeChild would look like this:

Window::Window(QWidget
  *parent)
 :
QWidget
(parent)
{
   QGroupBox *echoGroup = makeChild(tr("Echo"));
   QLabel *echoLabel =
echoGroup
->makeChild(tr("Mode"));
   QComboBox *comboBox =
echoGroup
->makeChild();
   [...]
   QGridLayout *echoLayout = echoGroup->makeChild();

   echoLayout->addWidget(echoLabel, 0, 0);

   echoLayout
->addWidget(echoComboBox, 0, 1);

   echoLayout
->addWidget(echoLineEdit, 1, 0, 1, 2);



This works, but now you are encoding the visual hierarchy of the widgets in two 
places: when asking the presumed parent to create the widgets; and when setting 
up the layout, which might do things differently (esp once you start 
refactoring complex UIs).#


That's not a problem. The code simply behaves as if you would have used 
the current constructors that take a parent parameter.


Ownership transfers between different qt parents don't violate the 
invariant. And they continue to work just like before.








Or if using unique_ptrs:

Window::Window(QWidget
  *parent)
 :
QWidget
(parent)
{
   auto echoGroup = std::make_unique(tr("Echo"));
   auto echoLabel = std::make_unique(tr("Mode"));
   auto comboBox = std::make_unique();
   [...]
   auto echoLayout = std::make_unique();

   echoLayout->addWidget(std::move(echoLabel), 0, 0);

   echoLayout
->addWidget(std::move(echoComboBox), 0, 1);

   echoLayout
->addWidget(std::move(echoLineEdit), 1, 0, 1, 2);


I don’t think these lines above are correct.

QBoxLayout::addWidget does *not* take ownership. Widgets are reparented to 
their correct parent once you call QWidget::setLayout in the next line, and 
QLayout operates on QLayoutItems that hold a weak pointer to the widgets that 
the layout places.


It's even more complicated than that, if the layout is already set on a 
widget a call to QBoxLayout::addWidget does transfer ownership.


But for a parent-less QBoxLayout::addWidget(QWidget *) does not take 
ownership. So whether a call to addWidget does transfer ownership is 
really hard to tell.


Which I personally find surprising and I actually missed that in my 
patch and Giuseppe had to point it out.


But that just means that QBoxLayout::addWidget(std::unique_ptr<>) has to 
behave imho saner in that edge case and actually delete the widgets that 
were added but never parented. (And I should really implement that to 
show how it would work.)


There's another pain point in the patch currently, and that has to do 
with the overloaded meaning of the parent ptr for QDialog. For QDialog 
in addition to the memory ownership that also controls modality. The 
other cases of overloaded meaning that I found in qtbase are as far as I 
can tell fine.


Meaning a line such as this:

QDialog dialog(parent);

is technically a doubly owned object, because it's both owned by the 
stack and by the passed parent. And that same problem makes it hard to 
make this memory safe.


The solution to that, is to fix Qt here. Modality and parent should not 
be coupled in this way.


daniel



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Daniel Teske]

Am 02.02.2020 um 18:17 schrieb Иван Комиссаров:

Can we please return to the discussion about QObject parent/child with smart 
pointers rather than discussing Qt/stl naming?

No one answered my question about QObject::deleteLater:


And what about the QObject::deleteLater() method? Any ideas how this should 
look like with smart pointers?


So obviously this:

std::unique_ptr<> ptr;
ptr->deleteLater();

should show a warning. Thus, the first step is to annotate deleteLater 
with a optional deprecation.


Then two new functions need to be added:

static QObject::deleteLater(QObject *ptr)

which does not violate that invariant. (Unless you take a pointer out of 
a unique_ptr and pass it in.)


And a second variant:
static QObject::deleteLater(std::unique_ptr ptr)

which quite obviously also keeps the invariant.

I think I missed the function in my patch, but that's how you could 
easily do it.


daniel

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Daniel Teske]

Pros I can see:
1) Qt style
STL has different naming convention that looks alien to Qt API. It leads to 
inconsistency.


The "Qt projects not using the standard library" era is over and the 
sooner that is understood the better. That inconsistency is just 
something to get used too


Qt does not duplicate:

std::optional
std::tuple
std::function
ranges
algorithms
parallel algorithms

All of them are great features that I would expect every Qt project to 
have some use for.


This list will grow in the future because C++ evolution is quite a bit 
faster then in the past. This isn't just that the standard gains 
features faster, but that compilers implement them immediately and from 
my experience these features are adopted in the industry.


In the future mixing Qt and standard classes will be even more common.

The important question for Qt is: How to leverage the evolution of 
standard C++ for the best combined offering.


daniel


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[Daniel Teske]

Parent-child relationship is not going to go away, it has purpose beyond object 
lifetime: the visual hierarchy is encoded in the parent/child relationship of 
widgets, for example.

Making ownership of objects, and assumptions regarding their life-cycle, 
explicit in code is a good thing though. Using smart pointers is the idiomatic 
C++ way to do so. But it doens’t have to be the only way; a call to 
QObject::setParent is IMHO just as explicit, and parent/child in Qt is a 
concept you have to learn either way.

But sometimes our APIs are messy. QTabWidget::addTab transfers ownership of the 
QWidget*; QTabWidget::addAction does not transfer ownership of the QAction*. 
Unless you understand fairly well how QAction works, or unless you 
read/remember the documentation, it’s impossible to see from the code what 
happens wrt to object ownership.

API naming is not a scalable way to make the distinction, so finding how we can 
use smart pointers to make it clear in the code when ownership is transferred 
is a good idea.

Perhaps the pragmatic approach is to address this in those APIs that take a 
QObject* but don’t transfer ownership. I believe those are much fewer. 
Otherwise, the convention can be that any API that takes a raw pointer takes 
ownership. How this is implemented internally doesn’t matter.



I have already invested quite a bit of time and thinking into how to add 
unique_ptr apis to Qt. And I encourage everyone to go back and read my 
previous mails, and/or the actual patch I produced.


Because I have already presented a design that is:

* Backwards compatible, existing code continues to work.
* And adds a lot of memory safety to Qt. Though not without a loop-hole.
* And actually exists as a experimental patch, not just some abstract idea.

To explain it once more, the key insight is the following invariant:

A QObject[1] is either owned by its parent, or by a unique_ptr[2].

[1]: Some classes use the same parent-child concept as QObject.
[2]: Stack allocated objects are essentially equivalent to unique_ptr 
held ones.


That implies that a unique_ptr owned QObject should have no parent.

That invariant ensures that there's exactly one owner for each object, 
and thus ensures that every object is deleted.


But it doesn't guarantee that the owner is what the user expected.

So to take your examples:

QTabWidget::addAction: This never transfers ownership, thus the 
invariant holds.


parent->addTab(tab): This has three cases:

* tab is owned already by parent: Invariant holds
* tab is owned by a different parent: Invariant holds

And the last case, and that's the small loop hole in the design:
* tab has no parent

That means, the child is owned by a unique_ptr, and the user must have 
called .get() on it.


Thus the small case where the user has to be cautious is when they have 
a raw pointer for a object owned by a unique_ptr. Luckily with the 
design I have this is should be rare.


In addition to the existing QTabWidget::addTab, the patch then adds:

QTabWidget::addTab(unique_ptr<>) for which the invariant obviously holds.

Now to take your next example: setParent is not fine. setParent can be 
used in 4 different ways:


child->setParent(child->parent()): Invariant holds
child->setParent(newParent): Invariant holds
child->setParent(nullptr): Nope
orphan->setParent(parent): Nope

The solution is I have is to replace setParent with two functions: 
adoptChild + releaseChild, which both ensure that the invariant always 
holds.


And to deprecate setParent. I actually made that deprecation opt-in, 
because of the next part:


Construction of QObjects:

The goal is to enable modern C++, meaning that users can choose to never 
use "new".


The first problem is then that a ctor such as this:

QTabWidget(QWidget *parent = nullptr)

can be used via make_unique:

auto child = make_unique(someParent);

That call would then violate the invariant, and thus in my patch I split 
up the ctor of QTabWidget into 2:


QTabWidget()
QTabWidget(QWidget *parent)

This is obviously backwards compatible.
The first ctor can be used without violating the invariant, whereas the 
second one violates it. And thus it's again optionally deprecated.


Now for some classes the parent ptr has additional meaning beyond just 
being the owner. E.g. for the layout classes. For that reason there's a 
bit of infrastructure, which makes this work:


parent->makeChild();

or to take a more complex example:

parent->makeChild("Hello World!");

(The infrastructure is a third constructor, and a forwarding function 
defined via Q_OBJECT)


For example, converting some random code on 
https://doc.qt.io/qt-5/qtwidgets-widgets-lineedits-example.html to use 
makeChild would look like this:


Window::Window(QWidget    *parent)
:QWidget  (parent)
{
  QGroupBox *echoGroup = makeChild(tr("Echo"));
  QLabel *echoLabel =echoGroup->makeChild(tr("Mode"));
  QComboBox 

Re: [Development] The future of smart pointers in Qt API

[Daniel Teske]

Hi,

I'm confused that there's zero discussion of the work I have done in 
showing how adding unique_ptr apis would look like. Surely, you have 
internally discussed that approach.


Also I'm sad to see that instead of using public mailing lists, you seem 
to have discussed this extensively internally.



For sure, it should only be a choice for newly designed API.

How did you come to this conclusion?


1) Use std::*  smart pointers as-is.

2) Add Qt-style wrappers around std::* smart pointers and move old
implementations of Qt smart pointers to the Qt5Compact module.

Both options have pros and cons. It would be useful to hear your
thoughts on it. It’s worth mentioning that some other options, like
using Qt smart pointers as-is, were also discussed. They were found less
suitable, but feel free to share your opinion if you disagree.


Using a standard class as is the right answer, because:

* Qt should position itself so that it benefits from innovation 
happening in the standard. Greater interoperability should be a goal. 
(Not just for smart pointers, but in general.)
* There's existing tooling around unique_ptr, and there would be none 
for any wrappers.
* Mixing std code and qt code is easier when they use the same 
vocabulary types.
* The existing smart pointers in qt have less capable API than the std 
ones.

   Expecting this to be different the next time seems foolish.
* unique_ptr is 9 years old. It's behaviour is well understood in the 
wider C++ community.

* There's a feeling that Qt has a NIH problem in the wider C++ community

daniel
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Daniel Teske]

The minor problem being that to not so small audiences,
new Whoosh(something);
just looks like a bug, and then you need to look three times to
realize that something is a parent.

Sure... but `something.createChild()` can help with that.

OTOH, I just realized a problem with that... when the new child needs to
take its parent in the ctor for other reasons. I don't know if there is
an easy solution to that. (Of course, you can still pass the parent with
createChild, but then you've violated DRY.)


There are multiple different implementations of createChild.

The one I did choose requires the class to have a tagged ctor, meaning a 
ctor whose first parameter is QParentPtr parent, so the ctor 
still has access to the actual parent ptr, and createChild simply passes 
the this pointer as the first parameter.


The drawback is obviously that requires new ctors, but there are several 
benefits:


* It is easier to do than having a later reparenting. Writing the new 
ctors is trivial.

* It allows for designing classes that can only created with a parent
* The cost of creating new ctors is only for those that want to make use 
of createChild.

* The new ctors have clear ownership semantics

In that patch, I've also added new ctors that take no parent ptr, to be 
used with make_unique or for stack-allocation.


And the last puzzle piece is that the qt users can choose to deprecate 
the old existing ctors, thus users can choose between:


* Keep just using Qt as is
* Make use of createChild by providing new ctors
* Ensure that each memory allocation is either parented or held in a 
unique_ptr, by opting into the deprecation + using some kind of code 
analysis preventing usage of raw news.


And obviously that's also the way, a existing code base could be 
transitioned.


The actual implementation of that mechanism is in:

https://codereview.qt-project.org/c/qt/qtbase/+/260618/1/src/corelib/global/qglobal.h 

https://codereview.qt-project.org/c/qt/qtbase/+/260618/1/src/corelib/kernel/qobjectdefs.h 



daniel
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Daniel Teske]

Hi,

I was happly ignoring the other threads, since I didn't like the 
temperature of some the responses.


But I guess you force me to write a response not just to you, but 
something that is a bit more general.

Or... just don't do that?

I can't recall that I've *ever* had problems with QObject ownership.


You, and a few others have made similar arguments, that start from your 
personal experience and since you do not needed something conclude that 
it is not worth doing.


And please don't read the rest of the mail as a attack on you, that's 
not intended. I think it's important to hear from all kind of different 
users, but I need to point out what I perceive as a faulty argument.


It is imho the wrong perspective:

There's a wide spectrum of Qt users.
* Some of which don't want Qt to change [much].
* Some of which want leverage new C++ features while using Qt
* Some of which want Qt to be more like the C++ standard

By arguing from a personal standpoint, you are implicitly ignoring all 
users that aren't like you. A proposal (or the rejection) should be 
based on considering the effect not just on you, but on all kind of 
different users.


Except, just considering current users, would be quite wrong.

Qt needs to continously attract new users, as it otherwise dies with the 
current user base. Those users will mostly - I would assume - come from 
a C++ backgroud. And my experience as a freelancer is that most projects 
I see use at least C++11 and I have no trouble finding projects using 
more modern standards.


But even that, would be the wrong perspective. We are discussing APIs in 
the context of Qt 6, which will be around for a decade. Thus, the 
correct perspective would be to consider which kind of user Qt wants to 
attract and serve in a few years. And I believe that in a few years, 
most people with a C++ background would expect modern apis.


The same perspective error happens from these arguing for deprecation 
and removal, too.


For example, obviously Q_FOREACH is ugly and outdated. It seems some 
argue that the benefit of not having to teach Q_FOREACH is worth the 
major pain and frustration that existing users would experience if it 
just got removed. I can't understand that.


In fact the whole premise of the thread is imho misguided. If the goal 
is making Qt and C++ more interoperable, then deprecation and removal is 
the wrong way to go about it.


The way forward should be to create win-win situations for both those 
that want to make use of modern C++ and those that are quite happy with 
Qt as it is.


For example, I wish Qt 6 would:

* enable templated QObjects. There's a prototype from Olivier, so is 
that possible?

* support move only types in Qt container
* add overloads for all functions taking bool * that make use of 
std::optional
* add overloads for all functions using output parameters. auto [...] = 
foo() is imho ugly, but that's nevertheless better than output parameters

* have great interoprability with ranges

None of that would require making Qt worse for existing users.


Generally, if you follow three rules:

- If you create an object on the stack, either don't parent it or ensure
its parent outlives it. (Usually not hard!)
- If you create an object with `new`, **create** it with a parent.
- Otherwise use a smart pointer (QScopedPointer or QSharedPointer)¹.

...you just won't have problems.


And that doesn't need to change with my design at all. You can just 
write the same code as is. To reiterate a point that seems to be a 
source of misunderstanding, in the design I proposed the vast majority 
of objects are never owned by a unique_ptr. Most objects are created 
with a parent.


And there are small benefits that even those that don't want to use 
unique_ptr, can get with minimal effort. For example by using the new 
makeChild function:


parent->makeChild(...);

It's almost impossible to forget to pass a parent parameter. And best of 
all, no one is forced to use that, but it can be adopted at whatever 
pace is best.


And for your last case of holding a QObject in a smart pointer, the 
propsal makes that drastically less akward.


So, I think what I have actually proposed has zero costs to those that 
don't want to use it, while enabling those that e.g. want to make use of 
tooling around memory managment capable of doing so.


daniel

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Daniel Teske]

The patch I propose does not take that into account and is indeed 
almost entirely source compatible.



Scratch the "not".


And while I'd encourage someone to try it out, I'm of the firm opinion 
that Qt should try to get over its NIH attitude. One of the issues 
with Qt in the real world is that it's just that tiny bit differently 
than what non Qt C++ users are familiar with for. Sometimes that's for 
a good reason. but there's a cost there that is imho unappreciated 
inside the Qt bubble.


That sounds a bit harsher than intended and I should expand a bit on the 
costs:


* Non Qt C++ developers can be expected to be familiar with how 
unique_ptr works. Today that might not be a entirely true, but we aren't 
deciding the api for today. We are deciding on the api for the next years.


* Static analyzers understand standard c++ but are unlikely to 
understand the Qt dialect. [1]


* Using standard c++ means, that any evolution in c++ benefits Qt 
automatically.


daniel

[1] For another example, clang-tidy knows about standard smart pointers 
for its use after move check: 
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-use-after-move.html


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt, Take 2

[Daniel Teske]

Am 06.05.2019 um 12:04 schrieb Lars Knoll:


On 6 May 2019, at 10:27, Konstantin Shegunov > wrote:


On Mon, May 6, 2019 at 10:42 AM Lars Knoll > wrote:


Not sure whether it’s most projects, but there certainly are
users doing it. And we’ve been using the pattern in our examples
in some cases as well. But I can relate to Allan that creating
widgets on the stack is bad style (as it conflicts with the way
we memory manage them), and if I’d have a choice today, I would
probably prefer to enforce them to be created on the heap by some
means.


Fine, there seems to be somewhat of an argument in that regard. I'd 
raise the question then, what should be done for QObject derived 
classes, and I don't mean the ones that come from Qt (i.e. QFile, 
which Thiago mentioned), but the ones the user defines. In the end 
QObject is for us to derive from - get signals and slots and all 
those goodies. But then if one restricts QObject to be on the heap 
how do we treat the user classes? What I mean is - you can control 
how allocations happen in the library, say you provide custom 
new/delete for QObject and/or QWidget and restrict the stack 
(presumably through some trickery that disables the constructor), 
does this mean we are to force the user to write their own allocation 
operators for their classes? This doesn't really sound practical to 
say the least. Moreover there's really little reason (from the user's 
point of view) to have something in the heap if it can go on the 
stack. What do we do with QCoreApplicaiton, force the heap on it?


It’s somewhat of a philosophical discussion now, as we are where we 
are and users can and are creating QObject’s on the stack. I don’t 
think we can change that now (even for Qt 6), and restricting it would 
lead to rather ugly syntax in C++ (as the language doesn’t really help 
enforcing something like this). So that means we’ll have to continue 
to support it.


That's something that needs to be taken into account in any change in 
how memory management could work in Qt6. The patch I propose does not 
take that into account and is indeed almost entirely source compatible. 
(No changes in Qt Creator required, and two minor changes in tests.)


And the constructors/apis that are marked with QT_UNSAFE_API by default 
don't even emit any warning. The user can opt into those warnings.


One thing I forgot to mention, which is something I only have a mediocre 
solution for is, modal QDialogs (or any other top level widgets) on the 
stack. For those the parent pointer is both the owner and indicates to 
which parent the dialog is modal. In my opinion, the best solution is to 
disentangle this. E.g. introduce a new method ::setModalTo(QWidget *), 
which if used overwrites to which parent a dialog is modal. (That is by 
default a dialog is modal to its parent, unless something else is set 
via setModalTo). This means code that uses modal widgets on the stack 
would need some conversion work, but that's as far as I can see the best 
solution.



The main benefits I see here that this scheme can co-exist with current
code, i.e. code bases could slowly opt-in and migrate step by step, and
it does not add the need to sprinkle user side code with the typical
smart pointer line noise.
The same is true for what I'm proposing. It can and does allow users to 
convert at they choosing, and since the vast majority of QObjects are 
created with parents, most QObjects will be created via makeChild. Using 
unique pointers is the exception not the norm with what I've proposed. 
And indeed due to the ergonomics of makeChild via make_unique, the user 
is steared towards using the better way to construct QObjects.


Now, what André is proposing is very similar to just having a owning 
smart pointer that remembers the pointed at object after it has lost 
ownership. I see no reason why that (or more fuller proxy classes) 
couldn't work. But,


* The class/smart pointer would need to be move only, which limits how 
useful it is.

* The semantics feel strange to me.

And while I'd encourage someone to try it out, I'm of the firm opinion 
that Qt should try to get over its NIH attitude. One of the issues with 
Qt in the real world is that it's just that tiny bit differently than 
what non Qt C++ users are familiar with for. Sometimes that's for a good 
reason. but there's a cost there that is imho unappreciated inside the 
Qt bubble.


Also nowadays C++ is changing quite fast and the way to profit from the 
advancements in standard c++ is by making sure that Qt works great with 
new standard c++ idioms. It's not by investing time into inventing a 
slightly different idiom.


For example, Microsoft is still researching whether static analysers 
could detect dangling pointers [2]. That tool obviously will understand 
unique_ptr and is unlikely to understand our custom solution.


daniel

[1] 

Re: [Development] unique_ptr and Qt, Take 2

[Daniel Teske]

Иван Комиссаров:

IMHO, it should be a Qt6 feature. It’s awesome.

However, I liked the idea (is it deprecated or what?) of a template 
method

template
std::observer_ptr 
qMakeChild(gsll::not_null> parent, Args… args)

{
    return parent->adoptChild(std::make_unique(args));
}


For some classes, notably QLayout constructing with a parent is 
different from setting a parent later. The former automatically sets the 
layout, whereas the later doesn't.


So, what you would need to do is in pseudo code:

std::observer_ptr 
qMakeChild(gsll::not_null> parent, Args… args)

{
 auto obj = std::make_unique(args);
 if hasMember(T:initWithParent)
 obj->initWithParent(parent)
    return parent->adoptChild(std::move(obj));
}

And obviously create a initWithParent method on all classes that are 
special like QLayout. I didn't explore that, as it didn't feel that nice 
to me





Maybe I’m asking too much, but it would be nice get rid of raw 
pointers completely switching to pair std::unique_ptr/std::observer_ptr


I don't think observer_ptr has only miniscule benefit over a raw pointer 
and I think it's ugly.


Thiago Macieira:

On Friday, 3 May 2019 10:22:20 PDT Daniel Teske wrote:

std::unique_ptr rightButton =
std::make_unique("RIGHT");
layout->addWidget(std::move(rightButton));
The problem in this particular example is that once you've added the 
widget,
the rightButton smart pointer no longer has a pointer. You can't 
continue to
set up your push button. In most cases, this is just a matter of 
moving the
set up before the addition / reparenting, or using the other idiom 
where the

object is never in a smart pointer in the first place.

So this begs the question of whether std::unique_ptr is the best smart 
pointer
for this scenario. Would it make sense to create one that understands 
parent-

child relationship?


addWidget could return a raw pointer to he widget, also that would 
require making addWidget and a bunch of other functions templates.


(They need to be templates, because we want to return the subclass that 
is stored in the unique_ptr, that is: T * addWidget(std::unique_ptr) 
is the right signature.)


But, on the topic of using our own smart pointer class.

I think unique_ptr actually works well enough with Qt's parent/child 
relationship with the right apis, because both use similar enough concepts.


Using the standards mechanism for memory management has the benefit that 
it is well-known outside the Qt world and aligns Qt better with modern 
practices, whereas our own smart pointer is again our own very different 
corner of C++.


I think that standard C++ is developing quite rapidly and for Qt's to 
profit from that development it needs to try harder to adopt changes in 
C++. And I believe that to be critical to Qt's long term success.


std::unique_ptr rightButton = 
std::make_unique("RIGHT");
layout->addWidget(std::move(rightButton)); 


To really, really, really nitpick, this last line is (or feels) wrong: 
layouts do not take ownership of the widgets they manage. An ownership 
transfer MAY happen immediately (if the layout is installed) or later 
(as soon as the layout is installed). 
I actually didn't know that and must have missed it. ( There are 
obviously lots of apis, I did check the documentation and read the 
implementation of most functions, but it's rather likely that a bunch of 
my implementations miss subtle details.)


So, what the function should do is to always do take ownership and if 
that requires behaving a bit differently than addWidget, so be it.


For example one case where I did catch something like that, the two 
variants of QAbstractItemView::setIndexWidgetbehave slightly differently.


* If the model index is valid, both take ownership of the widget.
* If the model index is invalid
    * The normal version does nothing
    * The unique_ptr version deletes the widget

Now, I'm in a bit of a hurry atm, but QLayout basically would need to 
ensure that any unique_ptrs that it took ownership of are either passed 
on to its parent widget, or are deleted in ~QLayout.


daniel

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] unique_ptr and Qt, Take 2

[Daniel Teske]

Hi,

a year back I wrote a patch that added unique_ptr apis to most of 
qtbase. I still think that would be a good addition to Qt, and thus I've 
updated the patch with the feedback gained at the Contributor Summit 
last year and taking into account that with Qt6, binary compatibility is 
not required. The result is: https://codereview.qt-project.org/#/c/260618/


Since not everyone remembers last years mail, I'll explain the problem 
that patch is trying to solve, but won't go into all the details:

Consider this small program:

QWidget widget;
QHBoxLayout *layout = new QHBoxLayout();
QPushButton *leftButton = new QPushButton("LEFT", ); // Owned by 
widget

layout->addWidget(leftButton); // No Ownership transfer

QPushButton* rightButton = new QPushButton("RIGHT"); // No owner
layout->addWidget(rightButton);   // Ownership transfer

QObject::connect(leftButton, ::clicked,
    [leftButton]{
    QMenu menu;
    auto act = new QAction("Action!"); // No Owner
    menu.addAction(act); // No Ownership transfer
menu.exec(leftButton->mapToGlobal(leftButton->rect().bottomLeft()));
});
widget.show();

In that program:

* The left button is owned at construction by the parent.
* The right button is created unowned, but adding a widget to a layout 
automatically sets the parent
* The action is created unowned, and is leaked because addAction does 
not set the parent.


That is, even though:

* layout->addWidget(new QPushButton()) and
* menu->addAction(new QAction())

look very similar, the later leaks memory.

That's a less than ideal api. With Qt6 there's a opportunity to leverage 
unique_ptr to ensure that memory is not leaked.


The patch adds two ways to create new QObjects:

* std::make_unique("LEFT"); and
* parent->makeChild("RIGHT");
* adds various overloads for ownership transfer

The first half of the program would thus look like:

QWidget widget;
QHBoxLayout *layout = widget.makeChild();

QPushButton *leftButton = widget.makeChild("LEFT");
layout->addWidget(leftButton);

std::unique_ptr rightButton = 
std::make_unique("RIGHT");

layout->addWidget(std::move(rightButton));

For second half, the naive transformation:

{
    QMenu menu;
    auto act = std::make_unique("Action!");
    menu.addAction(act.get());
menu.exec(leftButton->mapToGlobal(leftButton->rect().bottomLeft()));
}

does no longer leak memory, instead the action is freed at the end of 
the scope as its still owned by the unique_ptr.


I believe that Qt6 is a unique opportunity to add apis for better memory 
management to Qt.


So, who thinks that this is something that ought to be a Qt6 feature?

And who wants to actually help make that happen?

daniel

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] unique_ptr and Qt

[Daniel Teske]

Thanks for doing this.

Here is what i suggest to make the change less intrusive:
For the constructors themself in every classes.

  // Removed the '=nullptr' default parent, and added QT_UNSAFE_API
  QT_UNSAFE_API explicit QLineEdit(QWidget *parent);
  QT_UNSAFE_API explicit QLineEdit(const QString &, QWidget *parent);
  // Added new non-deprecated constructor not taking parent.
  explicit QLineEdit(const QString & = {});


//The QObject::makeChild method:
template  T* QObject::makeChild(Args&&... args)
{
  auto n = new T(std::forward(args)...);
  n->setParent(this);
  return n;
}


That way, std::make_unique still work, and constructing objects on the 
stack does not change.


For the cases where the parent in the constructor has another meaning, 
we would need another factory function (makeChild) in the relevant 
class. Or interept the ParentChanged, or reimplement setParent in that 
class.


What do you think?


Consider this "old" code:

QWidget widget;
QVBoxLayout *topLayout = new QVBoxLayout();
QVBoxLayout *childLayout = new QVBoxLayout();
topLayout->addLayout(childLayout);

That would, if I understood you correctly, translate too:
QWidget widget;
QVboxLayout *topLayout = widget.makeChild();
auto childLayout = std::make_unique();
topLayout-addLayout(std::move(childLayout));

Both topLayout and childLayout do end up with the same parent. In the 
old code, the QLayout ctor which takes a parent widget, calls 
QWidget::setLayout.
Thus I think overriding setParent or interpreting ParentChanged would 
not work.


Though makeChild could work, that is we would need:

template  T* QWidget::makeChild(Args&&... args)
{
  auto n = new T(std::forward(args)...);
  n->setParent(this);

  if constexpr(std::is_base_of)
    setLayout(n);
  return n;
}

I guess whether that is feasible depends on many ctors assign additional 
semantics to the parent parameter.


daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] unique_ptr and Qt

[Daniel Teske]

Hi,

I've done some research into how supporting unique_ptr in Qt might look 
like.


I have a patch which adds apis using unique_ptr for ownership transfer 
to almost all of QtBase and a patch for Qt Creator to show how using 
those apis looks like.


Qt: https://codereview.qt-project.org/231543
Qt Creator: https://codereview.qt-project.org/231545

It's nowhere finished, and I have no expectations of it going into Qt in 
the near future, nor the intention to finish the patch. The intent was, 
to have some fun, to explore the space of what is possible, to show how 
it could look like and to maybe start a discussion on what Qt can and 
should do in that direction. Also I run out of time to properly polish it.


This patch is backwards compatible, existing code continues to work 
exactly the same and has a very high degree of source compatibility. It 
allows users to opt-in to warnings that indicate unclear ownership 
semantics and allows for piece by piece porting of code. It requires 
C++17 though. And unfortunately due to a bug MSVC 15.7 is not good 
enough. That bug in guaranteed copy elision is supposed to be fixed in 15.8.


The additional apis are enabled via a configure flag and are inline 
functions.


The core idea is this invariant:

A Qt Object either is owned by a unique_ptr, is owned by a parent, or is 
allocated on the stack. (A stack allocated object, might or might not 
have a parent.)


Thus the first addition are 3 new functions for creating objects, all 
very similar to std::make_unique.


std::unique_ptr qmakeUnique(Args ...);
T* QObject::makeChild(Args ...);
T makeOnStack(ParentType, Args ...);

Those functions ensure that the returned object observe the invariant. 
That is, qmakeUnique passes a nullptr as the parent pointer to T.  And 
widget->makeChild(...) passes widget as the parent pointer. Thus if the 
constructor uses the parent pointer to set it's parent, the invariant 
holds and is ensured at compile time. Some types, e.g. QEvent, 
QTreeWidgetItem are treated a bit differently, see the patch for details.


I'll discuss various classes of functions:

* Functions "taking" ownership, e.g. QLayout::addWidget( child )

Note: Qt functions that "take" ownership, don't actually always take 
ownership. If the passed in argument is already owned by the right 
parent, ownership is not transferred.


To ensure that the invariant holds, there are two cases to consider:

a) The child is owned by a parent. => Use the addWidget(QWidget 
*rawPointer) overload
b) The child is owned by a unique_ptr => Use the new 
addWidget(std::unique_ptr widget) overload


For example this code is then possible:

auto label = qmakeUnique("label text");
layout->addWidget(std::move(label));

A undiagnosed and potential pitfall, is this code:

auto label = qmakeUnique("label text");
layout->addWidget(label.get());

which leads to double deletion. Calling a qt function that takes 
ownership with a raw pointer derived from a unique_ptr is a user bug. 
While obvious in this case, that isn't always so.


* Functions releasing ownership / creating new objects

There aren't actually not a lot of functions in this category. For 
example QLayout::removeWidget() does not release ownership of the 
widget, instead ownership is transferred if the widget is added to a 
different layout.


For functions that actually do release ownership / create objects, add a 
function returning a unique_ptr mostly named either "makeXXX" or 
"releaseXXX".


So how do I prevent users from calling the old function?

a) Not at all, this makes the code fully backwards compatible.
b) The user can opt into deprecation warnings by defining: 
QT_DEPRECATED_UNSAFE_API For Qt Creator patch, I defined that only in 
the coreplugin plugin.


* Other points
I probably missed quite a few special cases, since my aim was to cover 
as much as qtbase as possible, without spending too much time on each 
individual class. But for the most part, there weren't that many special 
cases. I left a few "TODO"s in the patch for apis that would take more 
work. I don't think there was anything completely unsolvable, but quite 
a few pain points.


Having unique_ptr as a vocabulary type also has some other benefits:

Some apis in Qt would really love to have a way to ensure that the 
caller takes care of deleting the resource. But because there is no way 
in C++98 to ensure that, they don't transfer ownership. For example, the 
documentation of QTcpServer::nextPendingConnection() is:


> The socket is created as a child of the server, which means that it 
is automatically deleted when the QTcpServer 
 object is destroyed.
> It is still a good idea to delete the object explicitly when you are 
done with it, to avoid wasting memory.


With unique_ptr there would be a way to ensure that the caller takes 
ownership by returning the QTcpSocket wrapped in a unique_ptr.


Also while writing this patch, I noticed several functions whose 

Re: [Development] FileRe: Move ctors for q_declare_shared types

[Daniel Teske]

  If a change is related to a discussion on the mailing list, I expect that
  the change is posted to the discussion.
 
 I already quoted you the mail where I ...
 
  Because not doing that, circumvents the discussion on the mailing list and
  goes against the spirit of The Qt Governance Model.
  
  You circumvented the discussion and did not inform the mailing list on the
  changes, which clearly were related:
  https://codereview.qt-project.org/115376
 
 ... shared this ^ change on the ML. Now you _again_ claim I didn't.

I never claimed that you didn't share this change. Also I mentioned that 
change exactly once so far. Can you please not grossly misrepresent what I 
actually wrote?

I wrote and this is from the only mail in which I mention that change, and I 
hope you read it this time:
You circumvented the discussion and did not inform the mailing list on the 
changes:

You only informed the mailing list on that change after it was already in the 
repository. You didn't wait until the discussion came to a conclusion. If you 
would have posted that change for discussion, I would have pointed out the how 
broken that change is without a change to the container classes.

I stand by my point, you circumvented the discussion on the mailing list.

  https://codereview.qt-project.org/#/c/120771
  https://codereview.qt-project.org/#/c/120804/
 
 These just implement what was discussed on the ML. Again: no-one spoke out
 against the solution Thiago and I came up with (publicly on the ML). 
 I posted one change, I didn't post them all, no. They contain no new
 information. 
I was under the impression that you wanted to not fix the container classes at 
all. Can you quote me the mail on the mailing list where you or Thiago propose 
and agree on fixing the container classes? 

 I have a few dozen of changes (re)adding move semantics to Qt
 types. Do you want to see them all? I can CC you from now on on Gerrit. I
 doubt everyone else will want to be spammed on the ML.
Again, and I'm not sure why this is complicated for you to understand:

A change that is related to a ongoing discussion on the mailing list, should 
be discussed on the mailing list. You shouldn't create hard facts by pushing a 
change.

  In my opinion this is unprofessional.
 
 Then I guess I'm unprofessional.
 
 You got what you lobbied for. What, exactly, are you complaining about?
Your unprofessional behaviour. I thought I made clear that I'm fine with the 
fixes in Qt.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FileRe: Move ctors for q_declare_shared types

[Daniel Teske]

 Are we going to announce every API change on the ML now?

No, that is obviously stupid. But, could you please stop trying to divert a 
discussion by raising unrelated questions? 

If a change is related to a discussion on the mailing list, I expect that the 
change is posted to the discussion. 

Because not doing that, circumvents the discussion on the mailing list and 
goes against the spirit of The Qt Governance Model.

You circumvented the discussion and did not inform the mailing list on the 
changes, which clearly were related:
https://codereview.qt-project.org/115376
https://codereview.qt-project.org/#/c/120771
https://codereview.qt-project.org/#/c/120804/

In my opinion this is unprofessional.

daniel

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FileRe: Move ctors for q_declare_shared types

[Daniel Teske]

Hi,

https://codereview.qt-project.org/#/c/120804/ and
https://codereview.qt-project.org/#/c/120771 do fix the move assignment 
operators in Qt, just like I wanted. 

I wonder why Marc Mutz didn't fell the need to update the mailing list on his 
changed opinion and this fix. 

Anyway, for those who don't want to read the full thread but want to know how 
write a move assignment operator. This advice by Howard E. Hinnant is good:

In general a move assignment operator should:
- Destroy visible resources (though maybe save implementation detail 
resources).
- Move assign all bases and members.
- If the move assignment of bases and members didn't make the rhs resource-
less, then make it so.

In code this looks e.g. like this:
 QVectorT operator=(QVectorT other) Q_DECL_NOTHROW
{ QVector moved(std::move(other)); swap(moved); return *this; }

Now, if and only if the destructor of the class has no side effects or those 
side effects are inconsequential, you might consider implementing move 
assignment as a swap between other and this.

But if you are holding a user defined type or if you are holding resources like 
file handlers or network sockets, you shouldn't implement move assignment via a 
simple swap between other and this.

As a counter example, std::string's move assignment operator is allowed to be 
implemented as a simple swap.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] FileRe: Move ctors for q_declare_shared types

[Daniel Teske]

   - QVector should give the same guarantee as the standard containers.
  
  I disagree with that. QVector is not std::vector. At first, it is
  implicitly shared, so that's already a big difference. And therefore we
  can allow ourselfs many more differences.
 
 But this point still stands.

Right, there's a argument possible that gratuitous differences should be 
avoided, after all it has the same name, so it should be semantically close, 
but well, I'm not going to bother with that.

Instead I will argue that:
This guarantee is important, valuable and good and Qt not giving this is bad.

So, in this example:

QSharedPointerSomeClass a = [...]
QSharedPointerSomeClass b = [...]
a  = std::move(b);

after this line, b holds a reference to whatever a contained prior to the 
move, since QSharedPointer is using swap to implement move assignment.

This is (mostly) fine if b is a temporary, since it only affects the order of 
destruction. 

If b though is a e.g. a member variable  of a class, and the user intends to 
move resources between objects, b might not be destructed until much later.

If the order of destruction is important, or that a resource destruction has a 
side effect this is bad.

Since Qt can not know whether the destructor of the type held in a shared 
pointer or a vector has a important side effect, Qt classes have to assume that 
there are such side effects. 

It is also surprising and counter intuitive that copy assignment and move 
assignment treat the old value differently, and none of the standard library 
types that hold user types behave in such a way. If the user intended this 
behavior, s/he could have called swap instead.

In support of this argument, let me point to the history of this guarantee  
for vector in the standard. (The text for shared_ptr always contained the 
guarantee, so the history there is not as interesting.)

First, in 2007!, the issue 675 added the relevant text:
All existing elements of a are either move assigned or destructed. was added 
to container.requirements.

See Issue 675 at http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2456.html.

Do note, that the proposed resolution is at the bottom, and the discussion is 
best understood with the proposed resolution in mind.

This issue and proposed resolution was submitted by Howard E. Hinnant, who was 
the lead designer and author of the move semantics standardization papers, is 
the lead author of libc++ and was the chairman of the LWG from 2005 to 2010.

The relevant quote:

Move semantics means not caring what happens to the source (v2 in this 
example). It doesn't mean not caring what happens to the target (v1). In the 
above example both [copy and move] assignments should have the same effect on 
v1. Any non-shared ostream's v1 owns before the assignment should be closed, 
whether v1 is undergoing copy assignment or move assignment.

This implies that the semantics of move assignment of a generic container 
should be clear, swap instead of just swap. An alternative which could achieve 
the same effect would be to move assign each element. In either case, the 
complexity of move assignment needs to be relaxed to O(v1.size()). 

The same argument of course applies to QSharedPointer too:

QSharedPointerQFile a;
QSharedPointerQFile b;

a = std::move(b) should close the old QFile held in a. 

And here:
http://stackoverflow.com/questions/6687388/why-do-some-people-use-swap-for-move-assignments

Howard E. Hinnant writes:
In general a move assignment operator should:
- Destroy visible resources (though maybe save implementation detail 
resources).
- Move assign all bases and members.
- If the move assignment of bases and members didn't make the rhs resource-
less, then make it so.

daniel

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Move ctors for q_declare_shared types

[Daniel Teske]

On Friday 26 Jun 2015 16:45:18 Marc Mutz wrote:
 On Friday 26 June 2015 12:34:31 Daniel Teske wrote:
   Most of our implicitly shared types already had a move-assignment
   operator, because it's just
   
  QFoo operator=(QForr other) { swap(other); return *this; }
  
  And that's indeed how QVector's move assignment is implemented.
  
  It's also broken.
 
 It isn't. Other is left in an unspecified, but valid state. It's not even
 partially formed, as many move operators leave their source.

It's nice that you follow up the denial by a statement that is entirely and 
completely irrelevant to the discussion.  

  Just because other is a rvalue reference does not mean that it is a
  temporary and thus the is no guarantee that other's dtor gets called.
  
  And thus, this line:
  
  QVectorKlass vector = std::move(something);
  
  does not gurantees that the dtors for the old contents of vector are
  called.
 
 It does. It doesn't say when (when something is going out of scope), but
 saying that dtors aren't called is wrong.
 
 The problem you have is that you want immediate resource release. If you
 want that, swap something with a new object:
 
QVectorKlass().swap(something);
 
 (or call clear(), but that's Qt-specific). You're never holding more memory
 at any given time (if you do this), than with an immidiate-release move
 operation. According to the fundamental C++ principle Don't pay for what
 you don't use, not clearing target is the correct thing to do. The
 standard should be fixed.

The standard requires immediate release for a reason. If you don't want that, 
just use a swap instead. Implementing move assignment as a swap destroys a 
fundamental guarantee of assignment. The old value is destroyed.


  All existing elements of a are either move assigned to or destroyed,
  
  I do not see any reason why our containers should not give the same
  guarantee for move assignment and consider this a bug.
 
 I guess then you also consider it a bug that Qt containers don't meet the
 std container complexity guarantees (b/c/o CoW) and don't meet the std
 container thread safety guarantees (b/c/o the omission of a non-sharable
 state when handing out references to internal state by way of op[] or
 mutable iterators), or that they don't have range-ctor or range-insert, or
 emplace, or allocator support.

Nope those are documented and there was a good reason for implementing them 
like that. Some of the omissions are surely only oversights.

If there's a reason for implementing move assignment differently from the 
standard containers, then you need to provide it. 

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Move ctors for q_declare_shared types

[Daniel Teske]

 Most of our implicitly shared types already had a move-assignment operator,
 because it's just
 
QFoo operator=(QForr other) { swap(other); return *this; }
And that's indeed how QVector's move assignment is implemented.

It's also broken.

Just because other is a rvalue reference does not mean that it is a temporary 
and thus the is no guarantee that other's dtor gets called.

And thus, this line:

QVectorKlass vector = std::move(something);

does not gurantees that the dtors for the old contents of vector are called. 

For standard containers, this is specified in *container.requirements*
To quote, with: a being a container and rv a non-const rvalue of the same 
type:

a = rv

All existing elements of a are either move assigned to or destroyed,

I do not see any reason why our containers should not give the same guarantee 
for move assignment and consider this a bug.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Move ctors for q_declare_shared types

[Daniel Teske]

 
  For standard containers, this is specified in *container.requirements*
  To quote, with: a being a container and rv a non-const rvalue of the same
  type:
  
  a = rv
  
  All existing elements of a are either move assigned to or destroyed,
  
  I do not see any reason why our containers should not give the same
  guarantee for move assignment and consider this a bug.
 
 Is this really that much different? 
There's a huge difference between either move assigned to or destroyed and 
not doing that.

I'm not sure where you are disagreeing, so can you point out to which of those 
4 statements you don't agree?

- Standard containers guarantee that the old elements get either move assigned 
or destroyed.

- QVector does not give the same guarantee, because it uses swap.

- QVector should give the same guarantee as the standard containers.

 A move assign of an element also
 doesn't guarantee destruction of the assigned-to contents right then and
 there, right? This again may be implemented as a swap.
If your class is e.g. holding a resource, implementing move assignment as a 
swap is wrong. The old resource needs to be freed at the point of assignment. 
Doing otherwise makes it harder to reason about code.

For an example of that, see .e.g the shared_ptr in the C++ standard:

shared_ptr(shared_ptr r) noexcept;
Postconditions: *this shall contain the old value of r. r shall be empty. 
r.get() == 0.


daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans

[Daniel Teske]

On Thursday 25 Jun 2015 12:09:54 Knoll Lars wrote:
 On 25/06/15 11:43, Teske Daniel daniel.te...@theqtcompany.com wrote:
 
 
  * WEC7 not supported anymore, WEC2013 supported
 
 So what is the time frame for dropping WEC2013? Because that's the time
 Qt 
 will be stuck with MSVC2012.
 
 
 WEC2013 just came out. I’m afraid we’ll be stuck with it for some time.
 
Right, that's what I expected, I'm guessing the expectation is that it'll be 
supported for years. 

We need to prioritize moving towards modern C++. The C++ world is changing.We 
cannot be stuck on a compiler that has only a minimal set of C++11 features, 
if we want Qt to stay relevant.

So, I'm against making WEC2013 a supported platform.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans

[Daniel Teske]

 * WEC7 not supported anymore, WEC2013 supported
So what is the time frame for dropping WEC2013? Because that's the time Qt 
will be stuck with MSVC2012.

daniel

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Some Qt3D feedback

[Daniel Teske]

 Curiously, you didn't list any pro-namespace arguments. 

Actually:
 We couldn’t make things work in a source compatible way.

 * connect statements are hard with namespaces. 

 * metatype registration is problematic with namespaced types

 * One of our coding guidelines is that you write code once, but read it
 many times. Code written should be as self explaining as possible. Having
 generic class names inside an implicit namespace makes this difficult, as
 information is not fully local anymore 
 
 * class name prefixing is a widely used and understood scheme by our
 users.

You think you have countered all of them. But to claim that there were no pro-
namespace arguments is just wrong. 


 But after all I read from the proponents of name prefixing so far, we rather
 need to send the whole QtC bunch to the asylum because they've clearly
 backed themselves into a corner and can't possibly understand their code
 anymore. :)

As a Qt Creator developer, I wouldn't recommend making the Qt API inconsistent 
wiht itself by introducing namespaces into a module now. 

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Daniel Teske]

On Thursday 19 Feb 2015 15:41:42 Matthew Woehlke wrote:
 On 2015-02-19 15:21, Marc Mutz wrote:
  On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
  more than 400 lambdas in Creator's source
  
  Sounds like lambdas are overused (as any new language feature is overused
  before it's fully understood by the resp. language community).
That is a useless contribution to this discussion.

 I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
 using them most often in QObject::connect. Basically, a lambda saves
 writing a protected (or worse, *private*) slot by allowing the relevant
 code to be written inline. These are rarely more than a few lines long,
 and it's not unusual for them to be one-liners, e.g.:
 
   connect(d-UI.scrollBar, QAbstractSlider::valueChanged,
   [d](int value){ d-scrollTo(value); });

That's one area. The others are too replace trivial interfaces with a low 
amount of virtual functions by a std::function properties. This can simplify 
code if e.g. the different implementations don't fit into a nice hierarchy.

Also lambdas make the standard algorithm useful. 
 
 The above is basically a private slot that's *actually private*. I've
 also had cases of needing to connect a signal to a slot where the slot
 needs to be called with additional (constant) arguments; these tend to
 look like the above also.
 
 Of course, the usual caveats of binding to a lambda apply, but in many
 cases those aren't issues (e.g. my MainWindow class is not going to
 disappear without taking its widgets with it, and said widgets aren't
 likely to be emitting signals from other threads).
 
 p.s. It would be cool if these restrictions could be relaxed by adding
 an overload that takes a QObject that owns the slot.
There is. 

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Daniel Teske]

On Friday 20 Feb 2015 00:17:00 Mathias Hasselmann wrote:
  [...]
   [...]
   [...]
 [...]

I guess my point that the ranged based for loop and qt containers don't mix 
too well is now very much proven by the depth of this particular discussion.

The upcoming Ranges TS has also uses std::begin and std::end. That means that 
qt containers will require special care to use with that TS. 

That is Qt is in danger of being hard to use with modern C++ in this area. 

My point is, if we don't use C++11 ourselves we won't find out in which areas 
Qt and modern C++ don't mix, and we won't fix them. We will be stuck being a 
C++98 toolkit that is slowly getting obsolete. 

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Daniel Teske]

Hi,

Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and 
C++14 added a lot of new good features. C++17 is planned to be a big step 
again. 

Qt needs to evolve together with C++ or it will be a outdated toolkit stuck in 
a C++98 world.

As an example, Qt's container classes and C++11 range based for loop do not 
mix very well.[1] And for the same reason, the upcoming Ranges TS will not be 
too useful for Qt's container. 

We have started using some parts of C++11 in Creator a year ago and our 
experience is that lambdas (and std::function) are useful everywhere. Today we 
have more than 400 lambdas in Creator's source and have several interfaces 
that take a std::function. 

I would expect that allowing C++11 in Qt would similarly lead to a wider 
understanding on how to leverage the new features for better code and better 
APIs.

We need to start now and deprecate old compilers that do not support any C++11 
features at all. I I suggest requiring support for lambda as 
supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating all 
platforms that do not in Qt 5.6.

daniel

[1] ranged based for uses std::begin(container), which if not overloaded calls 
container.begin(), which detaches. 

So using range-based can be used:
- If the container is const or
- If the container is unshared or
- To actually change the container's contents
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Daniel Teske]

On Thursday 19 Feb 2015 08:26:29 Thiago Macieira wrote:
 On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
  [1] ranged based for uses std::begin(container), which if not overloaded
  calls  container.begin(), which detaches.
  
  So using range-based can be used:
  - If the container is const or
  - If the container is unshared or
  - To actually change the container's contents
 
 Sounds like the intended behaviour to me. What's wrong with this picture?

You don't want to detach if you are only reading.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Why can't QString use UTF-8 internally?

[Daniel Teske]

On Wednesday 11 Feb 2015 17:20:04 Guido Seifert wrote:
 Minor OT, but I am too curious... do you have an example?
 Are there really cases were turning lower case into upper case or
 vice versa changes the length of a string?
What is uppercase ß? 

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Platform maintainers

[Daniel Teske]

 To make it explicit, I’d like to propose the following people as
 Maintainers for different platforms:
 
 Android: Bogdan
+1

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] crash when activating timers

[Daniel Teske]

On Wednesday 13 Aug 2014 08:05:52 Thiago Macieira wrote:
 On Wednesday 13 August 2014 14:32:13 Ziller Eike wrote:
  So my question: Does anyone have any idea how this could possibly happen,
  how we could reproduce and/or debug and fix it?
 
 I also got a bug report that is similar:
 https://bugreports.qt-project.org/browse/QTBUG-40636
 
 It's right now in need info state. There's nothing I can do with what's
 reported there or by your backtrace. Any chance we can convince people to
 run Creator inside valgrind?
 
 Also, please store the debug files from the build somewhere.
There is a valgrind log attached to the creator bug.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

[Daniel Teske]

On Thursday 17 Jul 2014 13:28:10 Jędrzej Nowacki wrote:
 On Thursday 17 of July 2014 10:51:03 you wrote:
  QVariant::operator== is not symmetric
  
   QDateTime dateTime = QDateTime::currentDateTime();
  
  QTime time = dateTime.time();
  
  qDebug()  (QVariant(dateTime) == QVariant(time));
  qDebug()  (QVariant(time) == QVariant(dateTime));
  
  --
  false
  true
 
 We could make it symmetric, if you want. 
A equals operator that is not symetric is broken. Such a class cannot be 
reliably used in std nor qt containers. Or do you know which way around, 
QList::contains uses the equals operation?

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Converting types in Qt

[Daniel Teske]

 Anyway. To summarize my position in the original context: QVariant
 is as it is. It is convenient at times, and it is already too convenient
 at times. Easy type conversion is a different use case than Type
 agnostic storage. QVariant does a bit of both, only the second one
 has ever been useful _to me_, I have been bitten by the first. As
 there are typically also more direct ways to convert types than to
 pass through QVariant, I consider the possibility to do type conversion
 through QVariant a mis-feature, and adding even more conversion
 abilities would be a step into the wrong direction _for me_. This is
 a personal opinion.

I certainly can't recall any place in Creator where a conversion via QVariant 
was intended. I can though recall several instances where such a conversion 
was the source of bugs. 

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt Creator 3.2 dropping support for Mac OS X 10.6

[Daniel Teske]

Hi,

Let's make this: 
 Qt Creator 3.2:
  - drop support for compiling  running Qt Creator on 10.6

 We want to start using C++11 also in Qt Creator, and 10.6 is the only thing
 preventing that. Since 10.6 is deployment target only for Qt, we don’t
 necessarily need to keep “its IDE” running there (yes, that’s a Qt-centric
 way of looking at Qt Creator).

a actual independant proposal (since it doesn't really depend on what qt 
supports) and cross post it to qt-creator for some wider exposure.

Actually using C++11 would also mean bumping the minimum supported compiler 
for *compiling* Qt Creator. That's somewhat separate, but I would assume we 
would require at least lamba and auto support for compiling Qt Creator 3.2.

That means MSVC 2010, clang 3.1 or g++ 4.5 if I remember correctly.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Convenient script for contributors: git gpush

[Daniel Teske]

Hi,

a long time ago Marius Storm-Olsen wrote a nice convenience tool to ease 
pushing to gerrit. As probably most are unaware of that tool, I'll just resend 
his original annoucement.

--
Hi,

I've just pushed a convenience script to the qtrepotools repository, 
which makes it easier to push patch-sets with reviewers added.

If you ensure that you have qt5/qtrepotools/bin in your path, you can 
simply do
 git gpush +reviewer1 +reviewer2 =CC user1 =CC user2

This pushes HEAD to the remote 'gerrit' to the remote branch which HEAD 
is tracking, and ensures that reviewer1 and reviewer2 are added as 
reviewers to every commit pushed.

The script handles aliases, and I've added a few IRC nicks to the alias 
list already. Contributions welcome for missing IRC aliases.
Note that you can add your own local aliases too simply by
 git config --global gpush.alias.IRC nick Gerrit user

Examples:
   (note that $TRB below means the tracking remote branch, most
often 'master', if you are not working on some special branch.)

   git gpush
   # Pushes HEAD:refs/for/$TRB to 'gerrit', without any reviewers

   git gpush +mariuso =thiago
   # Pushes HEAD:refs/for/$TRB to 'gerrit', adding me as a reviewer
   # and sends Thiago a CC mail.

   git gpush :refs/for/buildsystem
   # Pushes HEAD:refs/for/buildsystem to 'gerrit', no reviewers

   git gpush myremote +mstormo
   # Pushes HEAD:refs/for/$TRB to 'myremote', adding me as a reviewer

   git gpush some-branch: +stormols
   # Pushes some-branch:refs/for/$TRB to 'gerrit', adding me as
   # a reviewer

   git gpush -n -v +mariusso +thiago
   # Does a verbose dry-run of the push, showing alias resolving
   # and the final 'git push' command used (comma-separated arguments)

which produces an output like:
  mariusso = stormols
  thiago = thiago-intel
+git,push,-n,-v,--receive-pack=git receive-pack --reviewer=stormols 
--reviewer=thiago-intel,gerrit,HEAD:refs/for/master
Pushing to ssh://storm...@codereview.qt-project.org:29418/qt/qtrepotools
To ssh://storm...@codereview.qt-project.org:29418/qt/qtrepotools
  * [new branch]  HEAD - refs/for/master

--

Usage:
 git gpush [opts] [remote] [[sha1/ref-from]:[ref-to]] [+reviewer] 
[=CC user] [-- push opts]

 Pushes changes to Gerrit and adds reviewers and CC to the patch
 sets

Description:
 This script is used to push patch sets to Gerrit, and at the same
 time add reviewers and CCs to the patch sets pushed.

 You can use email addresses, Gerrit usernames or aliases for the
 name of the reviewers/CCs. Aliases are read from the
 .git-gpush-aliases
 located next to the script, then from the git config which may
 have aliases set either locally in the current repository,
 globally (in your ~/.gitconfig), or system-wide.

 You can and alias in your global git config like this:
 git config --global gpush.alias.alias key alias value
 and if you only want it local in the current repository, just drop
 the --global option.

 If no sha1 or ref-from is specified or configured, 'HEAD' is used.
 You may configure a ref-from like this
 git config gpush.ref-from ref-from value

 If no ref-to is specified or configured, the remote tracking
 branch for 'ref-from' is used as
 'refs/for/remote tracking branch'.
 You may configure a ref-to like this
 git config gpush.ref-to ref-from value

 If no remote is specified or configured, 'gerrit' is used. You may
 configure a remote like this:
 git config gpush.remote remote name

 If all the options above have been populated, the remainder
 options are passed on directly to the normal 'git push' command.
 If you want to avoid specifying all options first, any options
 specified after a '--' are also passed on directly to the
 underlying 'git push' command.

Options:
 -v, --verbose
 Shows the alias resolving, and final 'git push' command as a
 comma-separated list of arguments.

 -n, --dry-run
 Do everything except actually send the updates.
 Can be combined with --verbose to see the final command gpush
 will run.

 --aliases
 Reports all registered aliases.

Copyright:
 Copyright (C) 2012 Nokia Corporation and/or its subsidiary(-ies).
 Contact: http://www.qt-project.org/

License:
 You may use this file under the terms of the 3-clause BSD license.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Making QScopedPointer scoped (again)

[Daniel Teske]

On Wednesday 04 Sep 2013 22:15:48 Stephen Kelly wrote:
 On Wednesday, September 04, 2013 19:48:53 Knoll Lars wrote:
  Given that we have less then 3 weeks until feature freeze (1) or (3)
  sound more attractive for 5.2.
 
 That's not relevant.
 
 QScopedPointer is not moved anywhere in Qt 5.2. No code depends on the
 patch. My revert should be approved and we should go with option 4:
 
 4) We revert the change that added moving to QScopedPointer. When there is
 a need for QUniquePointer in the future, it is added. The new
 QUniquePointer shouldn't have the bug I pointed out previously regarding
 constness:
QScopedPointer has never been a scoped pointer. It has always had a .reset() 
method. That should never have been part of QScopedPointer. That somehow move 
support is the tipping point for breaking QScopedPointer is insane.

After all adding move support can be fully implemented by public methods that 
are already existing. 

daniel#
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Making QScopedPointer scoped (again)

[Daniel Teske]

 Again, this is what std::unique_ptr is for. We should not try to turn
 QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have
 a need for a std::unique_ptr, they should use it. We should not adapt
 QScopedPointer to fit the need instead.
 
 Adding a move contructor to QScopedPointer makes no sense, because moving
 means 'escaping the scope', which breaks the fundamental point of
 QScopedPointer. QScopedPointer is different to std::unique_ptr and should
 remain so.

*const* unique_ptr is a scoped ptr. So QScopedPointer is a NIH irregardless of 
a move support. 
 
daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [request] Creation a new QtSerialPort component into a Qt bug tracker

[Daniel Teske]

On Wednesday 26 Jun 2013 13:05:01 Knoll Lars wrote:
 On 26.06.13 12:59, Daniel Teske daniel.te...@digia.com wrote:
 On Wednesday 26 Jun 2013 09:04:26 Knoll Lars wrote:
  I can do that, but I can unfortunately not migrate the open bugs to the
 
 new
 
  component (as I can't migrate across Jira projects). You'd have to
 
 create
 
  a new report for each of the open bugs in the Jira Qt project. If you're
  ok with that I'll remove the serial port component in  the playground
  project.
 
 Actually that's easy to do with jira so I just moved all 31 bug reports
 to the
 new component.
 
 Didn't find that. You'll need to show me the trick at some point :)
There's a gear button in the top right corner of every filter or search result, 
(See attachment) which allows for Bulk Changes. Those allow for moving all 
bug reports in one go. That used to be broken for changing more than ~3 issues 
at the same time but seems to work nicely now. Except that I'm now watching 
all the bugs that I moved. 

daniel
attachment: bulkchange.png___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] kdelibs coding style

[Daniel Teske]

On Tuesday 30 Apr 2013 20:45:40 Thiago Macieira wrote:
 On terça-feira, 30 de abril de 2013 19.51.40, Daniel Teske wrote:
   So you suggest that KDE adopt the Qt style and Qt doesn't change
   anything?
  
  Why do they need to be the same?
 
 That was the request: can they be the same? They are identical except for
 the braces-on-if.
 
 I tried to compromise, but it seems like we don't want to compromise.
Apparently you think there is some benefit, but so far you haven't actually 
explained what that benefit is. You should explain what those are before trying 
to change a rule.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] kdelibs coding style

[Daniel Teske]

On Tuesday 30 Apr 2013 19:44:45 Thiago Macieira wrote:
 On terça-feira, 30 de abril de 2013 18.47.33, Oswald Buddenhagen wrote:
  on a personal note, while i strongly sympathize with the diff
  minimization philosophy, i also feel quite a dislike for excess braces.
  adding to that the in this case pretty persuasive consideration of the
  status quo, i'd like this discussion to die. NOW.
 
 So you suggest that KDE adopt the Qt style and Qt doesn't change anything?
Why do they need to be the same?

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Mitch Curtis for approver

[Daniel Teske]

On Friday 14 Dec 2012 11:17:14 Jedrzej Nowacki wrote:
 14 days passed and there was no objections.
 
 Congratulations Mitch!
I'm sorry, that is not correct.

From http://qt-project.org/wiki/The_Qt_Governance_Model

Once seconded, a new Maintainer is appointed unless a community member 
objects to the Chief Maintainer within 15 work days. If an objection is 
raised, the Chief Maintainer decides, usually within 15 work days.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMake behaviour change

[Daniel Teske]

 - Means that source code where headers and sources are split into
 different directories all of a sudden depends on relative paths to all
 files
See VPATH, which Ossi already mentioned in the bug report.

 - Behaves differently from QtCreator (tested with a rather old version
 2.5.2).
What exactly did you test? That Creator can find the headers? That's not 
testing anything of relevenace to the qmake behaviour.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QMake behaviour change

[Daniel Teske]

On Wednesday 28 Nov 2012 13:17:58 Johan Thelin wrote:
 On Wed, Nov 28, 2012 at 11:24 AM, Daniel Teske daniel.te...@digia.com 
wrote:
  - Means that source code where headers and sources are split into
  different directories all of a sudden depends on relative paths to all
  files
  
  See VPATH, which Ossi already mentioned in the bug report.
 
 yup, will do. I'm just questioning what the change brings, apart from
 breakage. Are there any direct benefits, more than cleaning up
 something that has been around since the dark ages.

All I point out that your claim that I quoted is false. 

  - Behaves differently from QtCreator (tested with a rather old version
  2.5.2).
  
  What exactly did you test? That Creator can find the headers? That's not
  testing anything of relevenace to the qmake behaviour.
 
 It finds the headers, but qmake does not, so the project looks ok. And
 yes, I know that 2.5.2 is old :-)
That is not testing anything of relevance to the change in qmake behaviour. 

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Stepping down

[Daniel Teske]

On Friday 01 Jun 2012 13:37:48 Paweł Polański wrote:
 Hi,
 due to the fact that I have no longer enough time to maintain Symbian in
 Qt Creator's Project Management  Targets I would like to step down from
 this position.

My symbian knowledge is rather limited. I will be looking over any gerrit 
change requests or bug reports, but I would consider the symbian support to be 
in pratice unmaintained. That is, I'm seeking help with that part of Creator, 
be it by submitting patches or by voluntering for maintainer, as otherwise 
it'll will break and will get removed eventually.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

[Daniel Teske]

  Default Assignee
  
  There is call for discussion around default assignee – is it the module
  maintainer? Which tasks are up for grabs if everything new goes to the
  maintainer?
 
 Unassigned should be the default. When someone picks up the task, they
 should assign it to themselves. Anything else is misleading.
I don't think the Creator team wants to change away from the current default 
assignee system for bugs in Creator, as that works pretty well for us.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Project Missing Infrastructure

[Daniel Teske]

 Qt Project 
 ==

Do note that the Qt Project consists of more then just the Qt Framework.

As such please pay attention in wording and do distinguish those two.

 
 * There are no internal docs on how things work to release
   * Never been written down
Because that's simply not true for Qt Creator.
See http://wiki.qt-project.org/Qt_Creator_Releases

 * Releases
   * Start a release team
   * Release team will 'start the clock' on a release, then decide when
 the required quality level has been reached.
   * The decision of if the quality is good enough will be made by the
 release team.
   * Aim to release within a month to six weeks of starting the process.
   * If bugs are found during testing then maintainers are the ones who
 should ensure they get fixed

Nor should is this in any way close to the way we have/want to release Qt 
Creator. 

   * Should we release binary snapshots such as those currently
 provided for creator?
There are no Nokia provided binary releases of creator snapshots anymore.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development