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

2015-06-29 Thread Marc Mutz
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

Re: [Development] New Qt 5.5.0 snapshot available - aimed to be final packages

2015-06-29 Thread Helio Chissini de Castro
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:

[Development] FileRe: Move ctors for q_declare_shared types

2015-06-29 Thread 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.

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

2015-06-29 Thread Thiago Macieira
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

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

2015-06-29 Thread Thiago Macieira
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

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

2015-06-29 Thread Marc Mutz
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

[Development] Disabling thread safe static guards

2015-06-29 Thread Sergio Martins
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

Re: [Development] Disabling thread safe static guards

2015-06-29 Thread Thiago Macieira
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

Re: [Development] Disabling thread safe static guards

2015-06-29 Thread Thiago Macieira
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

[Development] New Qt 5.5.0 snapshot available - aimed to be final packages

2015-06-29 Thread Salovaara Akseli
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:

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

2015-06-29 Thread Francesco Riosa
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

Re: [Development] Qt LTS C++11 plans (CopperSpice)

2015-06-29 Thread Ansel Sermersheim
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