Re: [Development] FileRe: Move ctors for q_declare_shared types
On Monday 29 June 2015 13:44:13 Daniel Teske wrote: 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); I repect Howard a lot, and he's right, to a point, even though I'd argue that explicitly clearing a moved-from object that isn't immediately going out of scope afterwards should be considered good coding practice, if only to give the reader of the code a hint as to what the state of the object is now. But there are additional constraints here. The std library contains next to no out-of-line classes. Destoying the LHS upon move assignment is thus trivial, and comes at only minor cost (though the O(N) behaviour _can_ be troublesome in practice even so). Consequently, all your examples are of template classes. But for most Qt types, and indeed the vast majority of those this thread is^Wwas originally about, there is an extremly high cost associated with destroying the LHS compared to just swapping the state into the RHS: out-of- line destructor calls. They are not free. They act as compiler-firewalls. The compiler loses a lot of the little information about a pimpled object that it had, and not only that: it loses information about at the very least all other objects of the same type in scope, because it must assume that they are all shared. It probably loses *all* information about *all* reference type objects in scope, too. That needs to be seen in connection with the future of the RHS. In the vast majority of cases, the RHS just gets its dtor called at the very next opportunity. If the LHS was destroyed as part of the move, then the RHS dtor will have little to nothing to do. It's an extremely expensive no-op, and doubles the number of dtor calls compared to swapping. So, it doubles the number of dtor calls, and it pessimises all code around it. I am not prepared to make that pessimisation for out-of-line types. People who use std::move can imo be bothered to clear the moved-from object after the move in those miniscule fraction of cases where that actually matters. Forcing people to use swap (if, indeed, they can, because swap() doesn't bind to rvalues on the rhs) for the common case is bad api design. For inline types, see https://codereview.qt-project.org/115376 Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 5.5.0 snapshot available - aimed to be final packages
Hello Can you please generate the splitted set of packages ? []'s On Mon, Jun 29, 2015 at 4:13 AM, Salovaara Akseli akseli.salova...@theqtcompany.com wrote: Hi all, We have new Qt 5.5.0 packages available which are aimed to be final. Windows: http://download.qt.io/snapshots/qt/5.5/5.5.0/2015-06-26_109/ Linux: http://download.qt.io/snapshots/qt/5.5/5.5.0/2015-06-26_136/ Mac: http://download.qt.io/snapshots/qt/5.5/5.5.0/2015-06-26_111/ Source: http://download.qt.io/snapshots/qt/5.5/5.5.0/latest_src/ (source package mirroring is in progress) Please check these packages now and inform me immediately if you find something broken blocking the release. If nothing serious is found during testing we will release these packages Wednesday 01.07.2015. Br, Akseli -- Akseli Salovaara Software Specialist The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] FileRe: Move ctors for q_declare_shared types
- 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] FileRe: Move ctors for q_declare_shared types
On Monday 29 June 2015 17:14:57 Marc Mutz wrote:
So, it doubles the number of dtor calls, and it pessimises all code around
it. I am not prepared to make that pessimisation for out-of-line types.
People who use std::move can imo be bothered to clear the moved-from object
after the move in those miniscule fraction of cases where that actually
matters. Forcing people to use swap (if, indeed, they can, because swap()
doesn't bind to rvalues on the rhs) for the common case is bad api design.
I agree with Marc here.
But, isn't there a third way for some types? For those that can take a null d-
pointer, it should be easy to just do:
Klass operator=(Klass other)
{ d = other.d; other.d = nullptr; return *this; }
This is better than the three-way swap because there's no extra temporary
being constructed and destructed out-of-line.
The drawback is that it implies null-d-pointer support forever, since it got
inlined in user code.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
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
On Monday 29 June 2015 20:42:40 Marc Mutz wrote:
But, isn't there a third way for some types? For those that can take a
null
d- pointer, it should be easy to just do:
Klass operator=(Klass other)
{ d = other.d; other.d = nullptr; return *this; }
Doesn't work. this-d is leaked in the process.
Never mind then...
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
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
On Monday 29 June 2015 17:50:31 Thiago Macieira wrote:
On Monday 29 June 2015 17:14:57 Marc Mutz wrote:
So, it doubles the number of dtor calls, and it pessimises all code
around it. I am not prepared to make that pessimisation for out-of-line
types. People who use std::move can imo be bothered to clear the
moved-from object after the move in those miniscule fraction of cases
where that actually matters. Forcing people to use swap (if, indeed,
they can, because swap() doesn't bind to rvalues on the rhs) for the
common case is bad api design.
I agree with Marc here.
But, isn't there a third way for some types? For those that can take a null
d- pointer, it should be easy to just do:
Klass operator=(Klass other)
{ d = other.d; other.d = nullptr; return *this; }
Doesn't work. this-d is leaked in the process.
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Disabling thread safe static guards
Hi, Can we disable gcc's feature of emitting extra code to make local static initialization thread safe ? (-fno-threadsafe-statics) Since MSVC doesn't support it we can't rely on this feature in cross-platform Qt code (maybe only in QPA code). Generates uneeded code and helps hidding crashes that developers using Linux don't notice. Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling thread safe static guards
On Monday 29 June 2015 19:44:49 Sergio Martins wrote: Hi, Can we disable gcc's feature of emitting extra code to make local static initialization thread safe ? (-fno-threadsafe-statics) No. Since MSVC doesn't support it we can't rely on this feature in cross-platform Qt code (maybe only in QPA code). Correct. Generates uneeded code and helps hidding crashes that developers using Linux don't notice. The code is needed because we use it in Q_GLOBAL_STATIC. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling thread safe static guards
On Monday 29 June 2015 13:02:42 Thiago Macieira wrote: Since MSVC doesn't support it we can't rely on this feature in cross-platform Qt code (maybe only in QPA code). Correct. Also, it's one of the C++11 features. It's tracked as Q_COMPILER_THREADSAFE_STATICS and is supported in MSVC since 2015. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] New Qt 5.5.0 snapshot available - aimed to be final packages
Hi all, We have new Qt 5.5.0 packages available which are aimed to be final. Windows: http://download.qt.io/snapshots/qt/5.5/5.5.0/2015-06-26_109/ Linux: http://download.qt.io/snapshots/qt/5.5/5.5.0/2015-06-26_136/ Mac: http://download.qt.io/snapshots/qt/5.5/5.5.0/2015-06-26_111/ Source: http://download.qt.io/snapshots/qt/5.5/5.5.0/latest_src/ (source package mirroring is in progress) Please check these packages now and inform me immediately if you find something broken blocking the release. If nothing serious is found during testing we will release these packages Wednesday 01.07.2015. Br, Akseli -- Akseli Salovaara Software Specialist The Qt Company ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans
Il 29/06/2015 02:02, Thiago Macieira ha scritto: SNIP In fact, it is already a big problem for us that it is being deprecated at all. QtWebEngine is not an adequate replacement, neither for developers (insufficient API), nor for packagers (bundling Chromium that itself bundles dozens of libraries makes this a completely unacceptable package for at least Fedora and Debian). But even if it were, applications are not going to be ported to it overnight. Chromium devs are willing to talk about unbundling. Have you reached out to them? sorry for the intrusion, about unbundling a good number of bundled libraries can be unbundled, gentoo do this, search remove_bundled_libraries.py in the following ebuild (bash script) https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-45.0.2438.3.ebuild most but not _all_ are libs are unbundled, maybe more hands on problem could help reaching perfection ;) good luck SNIP ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS C++11 plans (CopperSpice)
There is always CopperSpice the Qt fork which uses C++11. They've got rid of moc and plan to replace Qt containers with std ones. Afterwards maybe they will add support for namespaces to their peppermill source convertor utility. I am one of the developers of CopperSpice and I would like to elaborate on our project. Our initial release of CopperSpice was in July 2014 with our target audience being our local C++ Users Group in the San Francisco Bay area. We wanted to explore the interest in CopperSpice and obtain feedback regarding the steps we took to remove moc. Our full presentation in February 2015 was well received and attended by several prominent people. Our intent was to formally announce CopperSpice at CPPCon in September. Oddly, once we submitted a proposal for speaking at CPPCon, someone in Europe decided to post information about CopperSpice on reddit. As of today I can announce we have been approved to speak about CopperSpice at CPPCon. The current version of CopperSpice supports the full Qt Metaobject System, requires C++11, and includes CsCore, CsGui, CsPhonon, as well as CsScript, and CsWebkit. We have CsDBus partially ported, however more time has been spent on other libraries. It will be available in our September release. I would like to clarify, we did not use anything from the Woboq blog posting as others have speculated. We had moc removed from CopperSpice a year earlier than the release of this blog. We are also not associated with the Trinity Project. As a consequence of our presentation in February we have modified parts of the internal registration code to better implement reflection. We will be making a few more changes before this is released. Our September release of CopperSpice will include changes to the contain library, reimplementation of atomic types, our new changes to the MetaObject System registration, full API documentation, ?? We would like to encourage developers to attend CPPCon to learn about modern C++ and where it is going. For more information please check out the following video. http://cppcon.org/2015promo/ Our thanks go out to Trolltech, Nokia, and Digia for all the work they have done. Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
