Re: [Development] Abandoning the container changes
On Friday July 20 2012, Olivier Goffart wrote: On Thursday 19 July 2012 14:19:36 Marc Mutz wrote: On Wednesday July 18 2012, Olivier Goffart wrote: We discussed namespaces long time ago already, and decided not to put Qt in a namespace. The reason is that it breaks source compatibility by breaking all the forward declarations. Even with inline namespaces? Then they would have failed to achieve their goal to hide the fact that the type is in an inline namespace. Yes, inline namespace won't help. If you do: class QString; int foo(const QString ); It creates the symbol _Z3fooRK7QString, which is different from _Z3fooRKN3v507QStringE. Of course... how embarrassing.. :) The suggested solution is, during Qt5 lifetime, introduce forward-declaration headers that declares all the Qt types, and deprecate the use of forward declarations. Then in Qt6 we can finally move in a namespace. Sounds like a plan, yes. Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Friday July 20 2012, joao.abeca...@nokia.com wrote: Close to impossible. Oh, no. It's very possible. It's just not going to happen. We might as well have Qt50 and Qt52 and let the user pick one. Essentially, we're back at Qt5 and Qt6 with different names. Yes, with the difference that a Qt5 application can't link against a Qt6 Qt w/o recompilation. I'm not fighting for this, don't get me wrong, I'm just setting misconceptions straight. Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Thursday 19 July 2012 14:19:36 Marc Mutz wrote: On Wednesday July 18 2012, Olivier Goffart wrote: We discussed namespaces long time ago already, and decided not to put Qt in a namespace. The reason is that it breaks source compatibility by breaking all the forward declarations. Even with inline namespaces? Then they would have failed to achieve their goal to hide the fact that the type is in an inline namespace. Yes, inline namespace won't help. If you do: class QString; int foo(const QString ); It creates the symbol _Z3fooRK7QString, which is different from _Z3fooRKN3v507QStringE. The suggested solution is, during Qt5 lifetime, introduce forward-declaration headers that declares all the Qt types, and deprecate the use of forward declarations. Then in Qt6 we can finally move in a namespace. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
Some comments to the thread as a whole: Thiago did the call to not pursue the container changes any more for Qt 5 and propably had good reasons to do so. That implies that we'll continue with the classes we have now (yes, with their downsides in some use cases as well) for Qt 5. The containers are actually not as bad as some of you make them sound. The classes are stable and for many (most) use cases have a rather good performance. So they are something we can live with for the next years to come. Breaking BC again in a year from now just to make some container classes 10-30% faster for isolated benchmarks is simply not worth it. Inside an application the improvement is usually negligible and for the few cases where it matters one can use specialized containers. There's many more places where we can improve Qt a lot more (in a BC way) then by changing our container layout again in a year from now. Delaying further for such a change is also out of the question. The most important thing right now is to get the new version out. Remember we're doing a product which is a sum of many parts. We've done a huge amount of new work with Qt 5. As long as we haven't done the 5.0 release all this other good work not worth anything for our user base. Cheers, Lars On 7/19/12 3:08 AM, ext André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Wed, Jul 18, 2012 at 05:49:12PM -0600, Charley Bay wrote: The ideal for me is that if container-changes would push the Qt release back six months (to arbitrarily pick-a-fictitious-number), I'd rather have a release now, and another release in six months. This was not meant to put anything on the critical path or to change the timing of Qt 5.0 at all. Andre' ___ 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
Re: [Development] Abandoning the container changes
On Wednesday July 18 2012, Olivier Goffart wrote: On Wednesday 18 July 2012 14:00:08 Marc Mutz wrote: On Wednesday July 18 2012, Oswald Buddenhagen wrote: On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote: We don't even need to break binary compatibility. We could use inline namespaces to let new code see the new containers while old code uses the old ones. and how exactly is this supposed to work? we are not talking about changing some private implementation details, but the publicly visible data structures which are fundamental parts of our api+abi. even if it's somehow possible to have different classes use different container implementations, the conversion overhead would be ridiculous. That's a question of how the new classes are designed. I don't see an a-priori reason why, say, a v50::QVector couldn't share data with a v51::QVector, esp. considering the flexibility that was already present in Thiago's branch. There will be a conversion penalty of some form, but only for applications that continue to use the old version (because Qt will internally use the newest, of course). There will also be a maintenance penalty, but we already pay it in the form of BC guarantees. If we used inline namespaces, we would trade one form of maintenance burden (keeping BC) for another (maintaining inline namespaces). The question is just: which one is more work? And frankly, no-one knows, because there's no experience with inline namespaces (even though GCC uses something similar for the debug STL containers for a long time). We discussed namespaces long time ago already, and decided not to put Qt in a namespace. The reason is that it breaks source compatibility by breaking all the forward declarations. Even with inline namespaces? Then they would have failed to achieve their goal to hide the fact that the type is in an inline namespace. -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Thursday July 19 2012, joao.abeca...@nokia.com wrote:
Marc Mutz wrote:
On Wednesday July 18 2012, joao.abeca...@nokia.com wrote:
I think it would be feasible to do a binary-only break somewhere
around the 5.2 timeframe (say, ~12 months) where we address this.
Technically, this would be Qt 6, but user porting effort would be
reduced to a recompile. The value of having a long lived (5 years?)
binary compatible 5.x series is (IMO) low as there are quite often
other reasons to recompile the stack.
We don't even need to break binary compatibility. We could use inline
namespaces to let new code see the new containers while old code uses
the old ones. That will exclude non-C++11 compilers from seeing the
more efficient implementations, or else from the BC guarantee. Do we
care?
It's a binary break because containers and their memory layout are part
of function signatures in the ABI.
We also don't want a price to be paid at the interface: you were calling
a function and now just the function call has an additional cost of
deep-copying the container, potentially breaking implicit sharing that
was previously assumed to occur. This would be a silent change.
No, you would of course add an overload (where it matters).
Assuming we have
inline namespace v50 {
class QVector ... ;
}
qFun(const QVector ); // implictly v50::QVector
now. In, say, v5.2 we'll change QVector's guts. We do so by adding a new
implementation in namespace v52 and providing overloads for v50::QVector
where it matters:
namespace v50 {
class QVector ... ; // same as before
}
inline namespace v52 {
class QVector ... ; // new impl, with conversion to/from v50::QVector...
}
qFun(const v50::QVector); // old version, explicit namespace, required for BC
qFun(const QVector ); // new version (if necessary)
I'm not sure about forward-declarations, but at least inline namespaces are
designed to prevent the user of a type from being able to distinguish whether
it's in a namespace or a nested inline namespace. E.g., you can still
specialise templates in the surrounding namespace:
template
class QVectorMyType {...};
Inline namespaces are designed for library versioning. And seriously,
regarding another copy vs. implicit sharing: Qt breaks behaviour at so many
levels so often that users would hardly notice if there was some conversion
going on, esp. as the conversion cost, if not negligible, would of course
only be paid by old code (ie. qFoo(v50::QVector) would be implemented by
converting the argument to v52::QVector and calling qFoo(v52::QVector)).
I'd say that people that need BC guarantees are used to this kind of thing,
without having looked at it in details, glibc's library versioning is working
in the same way, everything else would be a maintenance nightmare.
Thanks,
Marc
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On quinta-feira, 19 de julho de 2012 14.19.36, Marc Mutz wrote: Even with inline namespaces? Then they would have failed to achieve their goal to hide the fact that the type is in an inline namespace. Yes. It breaks binary compatibility completely for all the code that uses QString in its API. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On quinta-feira, 19 de julho de 2012 14.31.52, Marc Mutz wrote:
namespace v50 {
class QVector ... ; // same as before
}
inline namespace v52 {
class QVector ... ; // new impl, with conversion to/from v50::QVector...
}
qFun(const v50::QVector); // old version, explicit namespace, required for
BC
qFun(const QVector ); // new version (if necessary)
As you've shown, we need to duplicate everything that has QString, QByteArray
and QVector in our API.
Close to impossible.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
hi Thiago,
There are two sides to this coin.
On Thursday July 19 2012, Thiago Macieira wrote:
On quinta-feira, 19 de julho de 2012 14.19.36, Marc Mutz wrote:
Even with inline namespaces? Then they would have failed to achieve their
goal to hide the fact that the type is in an inline namespace.
Yes. It breaks binary compatibility completely for all the code that uses
QString in its API.
One: No, it doesn't. Code that mentions 'QString' in v5.0 will implicitly
say 'v50::QString'. Code that mentions 'QString' in v5.2 (assuming QString
has changed there) will implicitly say 'v52::QString'. There's no bic, since
v50::QString hasn't changed, and the old API is still available. _Because_
the old API is still available, this comes at a cost, of course.
On Thursday July 19 2012, Thiago Macieira wrote:
On quinta-feira, 19 de julho de 2012 14.31.52, Marc Mutz wrote:
namespace v50 {
class QVector ... ; // same as before
}
inline namespace v52 {
class QVector ... ; // new impl, with conversion to/from
v50::QVector... }
qFun(const v50::QVector); // old version, explicit namespace, required
for BC
qFun(const QVector ); // new version (if necessary)
As you've shown, we need to duplicate everything that has QString,
QByteArray and QVector in our API.
Close to impossible.
That's is question number two: what does it cost to apply inline namespaces to
a core type such as QString? I can't answer that , and you can't answer,
either, because no-one ever tried. I never said it's easy, but I don't think
it's impossible. Stephen is working on a Clang-based Qt4-to-5 porting tool,
IIRC, so in one year, with that work further progressed, that duplication
might come for free, because it's automatable.
But I can see how converting to inline namespaces /now/ is too big a task,
yes.
Was just an idea, anyway.
Thanks,
Marc
--
Marc Mutz marc.m...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
Thiago Macieira wrote: As you've shown, we need to duplicate everything that has QString, QByteArray and QVector in our API. Not to forget QList, QVariant and potentially other classes we haven't considered changing yet. Besides, I'm sure we'd find places where we can't decide which one is the canonical version, like signals, and be forced to emit both variations. And this is just scratching the surface. Assuming Qt keeps some data internally by itself, no matter what the API looks like, conversion costs would still be there. Close to impossible. Oh, no. It's very possible. It's just not going to happen. We might as well have Qt50 and Qt52 and let the user pick one. Essentially, we're back at Qt5 and Qt6 with different names. João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
Hey, I would rather we don't *rush* the container changes in, but get them up to snuff in a separate branch, instead. I would also like to challenge the assumptions I've seen repeated that probability for breakage is low and autotest coverage is high. It isn't and it isn't. It is very easy to break less-often used features and corner cases that will not get caught by autotests. I don't think this is acceptable for fundamentals like QVector and friends. I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. Cheers, João From: development-bounces+joao.abecasis=nokia@qt-project.org [development-bounces+joao.abecasis=nokia@qt-project.org] on behalf of ext André Pönitz [andre.poen...@mathematik.tu-chemnitz.de] Sent: 17 July 2012 23:59 To: development@qt-project.org Subject: Re: [Development] Abandoning the container changes On Tue, Jul 17, 2012 at 05:19:23PM +0200, Oswald Buddenhagen wrote: On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. this is absurd. Incidentally, I agree. [Even if I lack the skill to express myself so clearly at times ;-}] we said A, now we need to say B. or unsay A, which i don't think anyone wants. i for one don't believe in qt6 anytime soon. it's the do-never release qt5 was for years. The suggested 4 years are 3 1/2 years too much anyway. That's 3 1/2 years more of forcing people to re-invent the wheel when it comes to performance-sensitive components in a Qt environment, and it's 3 1/2 years on top of the past half decade or so where Qt containers fail to deliver on one of the original reasons to have them at all (portability, convenience of use, _and_ performance). We do have the chance to fix it _now_, and we have a fairly decent idea of how the fix looks like. The whole change is essentially source compatible, i.e. has a low probability of breaking other components, and it is very well covered by autotests. The chances to be ready before the rest (Webkit Windows? Mac?) is ready for a 5.0 release are good. To get back on the constructive side I propose to do any of the following, in decreasing order of desirability: (A) Have the QString/QByteArray related bits in 5.0. (B) Have everything in 5.0. (C) Don't do anything for 5.0, but aim for a 6.0 instead for a 5.1 next. (D) Don't do anything for 5.0, but allow 5.1 to be source compatiple but binary incompatible. (E) Don't do anything for 5.0, and provide a compile-time switch for 5.1 to select between current and patched versions, default to current. [This is probably the most expensive solution, but the one that fits best to the rules] Andre' ___ 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
Re: [Development] Abandoning the container changes
On Wed, Jul 18, 2012 at 07:06:55AM +, joao.abeca...@nokia.com wrote: Hey, I would rather we don't *rush* the container changes in, but get them up to snuff in a separate branch, instead. I would also like to challenge the assumptions I've seen repeated that probability for breakage is low and autotest coverage is high. It isn't and it isn't. It is very easy to break less-often used features and corner cases that will not get caught by autotests. I don't think this is acceptable for fundamentals like QVector and friends. I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. That's essentially option (D) with a somewhat longer lead time. I think that would be ok. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. Right. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wednesday July 18 2012, joao.abeca...@nokia.com wrote: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. We don't even need to break binary compatibility. We could use inline namespaces to let new code see the new containers while old code uses the old ones. That will exclude non-C++11 compilers from seeing the more efficient implementations, or else from the BC guarantee. Do we care? Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wednesday July 18 2012, joao.abeca...@nokia.com wrote: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. if it's qt 6, then you call it qt 6. you need to do that because of SOVERSION requirements anyway. but this instantly forces the question: what's the point of rushing out 5.0 now if we already know that we'll deprecate it in a year? The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. every linux distributor will slaughter you for this statement. On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote: We don't even need to break binary compatibility. We could use inline namespaces to let new code see the new containers while old code uses the old ones. and how exactly is this supposed to work? we are not talking about changing some private implementation details, but the publicly visible data structures which are fundamental parts of our api+abi. even if it's somehow possible to have different classes use different container implementations, the conversion overhead would be ridiculous. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On 18/07/2012 02:06, ext joao.abeca...@nokia.com wrote: Hey, I would rather we don't *rush* the container changes in, but get them up to snuff in a separate branch, instead. I would also like to challenge the assumptions I've seen repeated that probability for breakage is low and autotest coverage is high. It isn't and it isn't. It is very easy to break less-often used features and corner cases that will not get caught by autotests. I don't think this is acceptable for fundamentals like QVector and friends. I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. If there's reasons to break BC, there's reasons for a new Major version. We don't circumvent the policies because is looks silly to have a new major version in such a short time after 5.0. However, I can imagine there's other significant changes we'll notice after 5.0 which will warrant other BC-incompatible changes, and maybe we'd want to refactor out more of the modules from QtBase into their own repos? As such, we might have several valid reason for having another major, to quickly correct learned lessons from Qt 5, and to ensure Qt 6 can live on for a very long time. Still, if Qt 6 would be on the road-map then, we should aim for making transitioning as simple as a pure recompile. We don't _have_ to do significant restructuring just because we're going a new major. Simply saying that we need to do it because of BC issues is fine. If major speed improvements is a result of that, I'm sure many people would understand. Anyways, several people and Thiago himself has said that now is not the time for such a change to our tools classes, and we should listen to that. I don't think you want to add them both and let the end user decide, as it will create a maintenance nightmare, and you will have applications which both use Qt 5 but are incompatible with each others run-time. (Some apps will demand that you use the optimized Qt5 for plug-ins etc.) -- .marius Cheers, João From: development-bounces+joao.abecasis=nokia@qt-project.org [development-bounces+joao.abecasis=nokia@qt-project.org] on behalf of ext André Pönitz [andre.poen...@mathematik.tu-chemnitz.de] Sent: 17 July 2012 23:59 To: development@qt-project.org Subject: Re: [Development] Abandoning the container changes On Tue, Jul 17, 2012 at 05:19:23PM +0200, Oswald Buddenhagen wrote: On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. this is absurd. Incidentally, I agree. [Even if I lack the skill to express myself so clearly at times ;-}] we said A, now we need to say B. or unsay A, which i don't think anyone wants. i for one don't believe in qt6 anytime soon. it's the do-never release qt5 was for years. The suggested 4 years are 3 1/2 years too much anyway. That's 3 1/2 years more of forcing people to re-invent the wheel when it comes to performance-sensitive components in a Qt environment, and it's 3 1/2 years on top of the past half decade or so where Qt containers fail to deliver on one of the original reasons to have them at all (portability, convenience of use, _and_ performance). We do have the chance to fix it _now_, and we have a fairly decent idea of how the fix looks like. The whole change is essentially source compatible, i.e. has a low probability of breaking other components, and it is very well covered by autotests. The chances to be ready before the rest (Webkit Windows? Mac?) is ready for a 5.0 release are good. To get back on the constructive side I propose to do any of the following, in decreasing order of desirability: (A) Have the QString/QByteArray related bits in 5.0. (B) Have everything in 5.0. (C) Don't do anything for 5.0, but aim for a 6.0 instead for a 5.1 next. (D) Don't do anything for 5.0, but allow 5.1 to be source compatiple but binary incompatible. (E) Don't do anything for 5.0, and provide a compile-time switch for 5.1 to select between current and patched versions
Re: [Development] Abandoning the container changes
On Wednesday July 18 2012, Oswald Buddenhagen wrote: On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote: We don't even need to break binary compatibility. We could use inline namespaces to let new code see the new containers while old code uses the old ones. and how exactly is this supposed to work? we are not talking about changing some private implementation details, but the publicly visible data structures which are fundamental parts of our api+abi. even if it's somehow possible to have different classes use different container implementations, the conversion overhead would be ridiculous. That's a question of how the new classes are designed. I don't see an a-priori reason why, say, a v50::QVector couldn't share data with a v51::QVector, esp. considering the flexibility that was already present in Thiago's branch. There will be a conversion penalty of some form, but only for applications that continue to use the old version (because Qt will internally use the newest, of course). There will also be a maintenance penalty, but we already pay it in the form of BC guarantees. If we used inline namespaces, we would trade one form of maintenance burden (keeping BC) for another (maintaining inline namespaces). The question is just: which one is more work? And frankly, no-one knows, because there's no experience with inline namespaces (even though GCC uses something similar for the debug STL containers for a long time). Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wednesday 18 July 2012 14:00:08 Marc Mutz wrote: On Wednesday July 18 2012, Oswald Buddenhagen wrote: On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote: We don't even need to break binary compatibility. We could use inline namespaces to let new code see the new containers while old code uses the old ones. and how exactly is this supposed to work? we are not talking about changing some private implementation details, but the publicly visible data structures which are fundamental parts of our api+abi. even if it's somehow possible to have different classes use different container implementations, the conversion overhead would be ridiculous. That's a question of how the new classes are designed. I don't see an a-priori reason why, say, a v50::QVector couldn't share data with a v51::QVector, esp. considering the flexibility that was already present in Thiago's branch. There will be a conversion penalty of some form, but only for applications that continue to use the old version (because Qt will internally use the newest, of course). There will also be a maintenance penalty, but we already pay it in the form of BC guarantees. If we used inline namespaces, we would trade one form of maintenance burden (keeping BC) for another (maintaining inline namespaces). The question is just: which one is more work? And frankly, no-one knows, because there's no experience with inline namespaces (even though GCC uses something similar for the debug STL containers for a long time). We discussed namespaces long time ago already, and decided not to put Qt in a namespace. The reason is that it breaks source compatibility by breaking all the forward declarations. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wednesday, July 18, 2012 14:00:08 Marc Mutz wrote: The question is just: which one is more work? And frankly, no-one knows, because there's no experience with inline namespaces (even though GCC uses something similar for the debug STL containers for a long time). I believe the llvm community libc++ uses inline namespaces, but that might not have the widespread use and multiple versions required to really get the required experience. I don't think breaking binary compatibility in a 5.x release is a good idea. As was said previously, if it's Qt 6, call it Qt 6. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
André Pönitz wrote: On Wed, Jul 18, 2012 at 07:06:55AM +, joao.abeca...@nokia.com wrote: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. That's essentially option (D) with a somewhat longer lead time. Somewhat. If it's a binary break we should still call it Qt 6. I'm thinking we should get 5.0 out, use 5.1 to stabilize, react to feedback and generally (im)prove on the Qt 5 vision. Some container changes sneaked in, but they're not what we're trying to deliver *now*. In parallel, we actually write the container changes everyone's up in arms about (Thiago's changes are unfinished and not-fully-published work in progress), we review those changes, take them for a spin, kick the hell out of those tires and then make an informed decision whether it is worth the binary break and how to handle it, in case it is. Besides autotests coverage, we also have no benchmarks showing improvements. I assume we can see improvements for the inlining of size and offset/data in iteration benchmarks, but we haven't fully explored the impact of *growing* the size of the container itself. Anyway, we can discuss potential options now, but we can't make any decisions and can hardly make commitments, other than than let's do the container changes and release them when they're ready. Cheers, João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
João spaketh: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. André respondeth: That's essentially option (D) with a somewhat longer lead time. João respondeth again: Somewhat. If it's a binary break we should still call it Qt 6. I'm thinking we should get 5.0 out, use 5.1 to stabilize, react to feedback and generally (im)prove on the Qt 5 vision. Some container changes sneaked in, but they're not what we're trying to deliver *now*. In parallel, we actually write the container changes everyone's up in arms about (Thiago's changes are unfinished and not-fully-published work in progress), we review those changes, take them for a spin, kick the hell out of those tires and then make an informed decision whether it is worth the binary break and how to handle it, in case it is. Besides autotests coverage, we also have no benchmarks showing improvements. I assume we can see improvements for the inlining of size and offset/data in iteration benchmarks, but we haven't fully explored the impact of *growing* the size of the container itself. Anyway, we can discuss potential options now, but we can't make any decisions and can hardly make commitments, other than than let's do the container changes and release them when they're ready. IMHO this seems reasonable. I view QML2 as the stabilized version of QML1 (significant technical differences, as well as underlying implementation). I was quite impressed with what QML1 offered (it's a new paradigm), but I think the community would benefit from learning-to-work with QML2 as opposed to extending their learning curves on QML1. I understand the value of the container-changes, and while warranted, it doesn't seem to be the biggest part of the core-offering of Qt5, and it's possible some of the benchmarks/changes associated with that effort might be better understood after the C++11 Rvalue-references are better implemented and made available through compiler vendors. The ideal for me is that if container-changes would push the Qt release back six months (to arbitrarily pick-a-fictitious-number), I'd rather have a release now, and another release in six months. I know it's been discussed before (don't want to re-open that discussion), but I don't care about binary compatibility (I know how to recompile); and only somewhat care about interface compatibility (adding-member-functions seems incredibly cheap to me, I'd prefer to have the APIs mature properly since they represent new designs); and, I'd support any renaming/refactoring to enforce best-practice-use-models as these are discovered when applying this new paradigm. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
Marius Storm-Olsen wrote: On 18/07/2012 02:06, ext joao.abeca...@nokia.com wrote: I think it would be feasible to do a binary-only break somewhere around the 5.2 timeframe (say, ~12 months) where we address this. Technically, this would be Qt 6, but user porting effort would be reduced to a recompile. The value of having a long lived (5 years?) binary compatible 5.x series is (IMO) low as there are quite often other reasons to recompile the stack. If there's reasons to break BC, there's reasons for a new Major version. We don't circumvent the policies because is looks silly to have a new major version in such a short time after 5.0. Agreed. However, I can imagine there's other significant changes we'll notice after 5.0 which will warrant other BC-incompatible changes, and maybe we'd want to refactor out more of the modules from QtBase into their own repos? As such, we might have several valid reason for having another major, to quickly correct learned lessons from Qt 5, and to ensure Qt 6 can live on for a very long time. Yes, by all means when we notice these needed changes and have them ready let's bundle them together and call them a release. Let's not plan releases based on features and let's not plan to do work based on the assumption that we're doing a binary break anyway, at least for as long as we can avoid it. Still, if Qt 6 would be on the road-map then, we should aim for making transitioning as simple as a pure recompile. We don't _have_ to do significant restructuring just because we're going a new major. Simply saying that we need to do it because of BC issues is fine. If major speed improvements is a result of that, I'm sure many people would understand. Agreed. Anyways, several people and Thiago himself has said that now is not the time for such a change to our tools classes, and we should listen to that. I don't think you want to add them both and let the end user decide, as it will create a maintenance nightmare, and you will have applications which both use Qt 5 but are incompatible with each others run-time. (Some apps will demand that you use the optimized Qt5 for plug-ins etc.) My suggestion is not to have both variants in the common code base or to advertise two alternative Qt 5 implementations. I'm suggesting we treat this as feature development happening in a feature branch (reviewed, CI-tested and all that, if feasible). I'm also suggesting we consider the posibility of doing an earlier BC break with stronger SC guarantees and use that if/when there's significant value being added. Having this *possibility* at all can encourage people to try out things, instead of waiting for a Do Never Qt 6 (tm) release and rushing half-baked features out. João ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Wed, Jul 18, 2012 at 05:49:12PM -0600, Charley Bay wrote: The ideal for me is that if container-changes would push the Qt release back six months (to arbitrarily pick-a-fictitious-number), I'd rather have a release now, and another release in six months. This was not meant to put anything on the critical path or to change the timing of Qt 5.0 at all. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
Op 16-7-2012 23:52, Thiago Macieira schreef: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: Hello all I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. That being the case, would it be possible to at least document these issues properly then? I think it is not all that clear from the documentation that QList is so inefficient for these cases. I don't think documentation changes are binary incompatible ;-) André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Tuesday July 17 2012, Andre Somers wrote: Op 16-7-2012 23:52, Thiago Macieira schreef: [...] That includes the fact that QListQVariant is extremely inefficient. That being the case, would it be possible to at least document these issues properly then? I think it is not all that clear from the documentation that QList is so inefficient for these cases. I don't think documentation changes are binary incompatible ;-) [...] Would a patch that makes certain QList instantiations privately inherit QVector acceptable? I'm thinking QListQModelIndex, QListQVariant, mostly, probably others. That would require a patch that made QList and QVector identical, API-wise, and that, in turn, would require using member; support in the compiler (the QT_NO_USING define is still in the code). Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. this is absurd. we said A, now we need to say B. or unsay A, which i don't think anyone wants. i for one don't believe in qt6 anytime soon. it's the do-never release qt5 was for years. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Tue, Jul 17, 2012 at 05:19:23PM +0200, Oswald Buddenhagen wrote: On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote: On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. this is absurd. Incidentally, I agree. [Even if I lack the skill to express myself so clearly at times ;-}] we said A, now we need to say B. or unsay A, which i don't think anyone wants. i for one don't believe in qt6 anytime soon. it's the do-never release qt5 was for years. The suggested 4 years are 3 1/2 years too much anyway. That's 3 1/2 years more of forcing people to re-invent the wheel when it comes to performance-sensitive components in a Qt environment, and it's 3 1/2 years on top of the past half decade or so where Qt containers fail to deliver on one of the original reasons to have them at all (portability, convenience of use, _and_ performance). We do have the chance to fix it _now_, and we have a fairly decent idea of how the fix looks like. The whole change is essentially source compatible, i.e. has a low probability of breaking other components, and it is very well covered by autotests. The chances to be ready before the rest (Webkit Windows? Mac?) is ready for a 5.0 release are good. To get back on the constructive side I propose to do any of the following, in decreasing order of desirability: (A) Have the QString/QByteArray related bits in 5.0. (B) Have everything in 5.0. (C) Don't do anything for 5.0, but aim for a 6.0 instead for a 5.1 next. (D) Don't do anything for 5.0, but allow 5.1 to be source compatiple but binary incompatible. (E) Don't do anything for 5.0, and provide a compile-time switch for 5.1 to select between current and patched versions, default to current. [This is probably the most expensive solution, but the one that fits best to the rules] Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: Hello all I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz wrote: On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira wrote: Hello all I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. I assume this is meant as a verdict, not as (possibly temporary) state of thinking. Correct. The changes are the right thing to do, just not now. We'll have to live with the current containers and their overhead until Qt 6. That includes the fact that QListQVariant is extremely inefficient. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Abandoning the container changes
Hello all I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. The changes are public, though, so we can always retrieve them for Qt 6 when we do it in (say) 4 years time. I'll abandon my branch and the metaobject changes that went along. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Thu, 2012-07-05 at 09:04 +0300, Thiago Macieira wrote: Hello all I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. The changes are public, though, so we can always retrieve them for Qt 6 when we do it in (say) 4 years time. I don't know the changes in detail, but would it be possible to introduce the container changes under a special namespace instead (think std::tr1)? Then we could still choose to use them in new code and the transition to Qt 6 would be somewhat easier. regards, Michael ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On quinta-feira, 5 de julho de 2012 11.28.58, Michael Hasselmann wrote: On Thu, 2012-07-05 at 09:04 +0300, Thiago Macieira wrote: Hello all I think that, despite the potential benefits of the changes, we should not apply them at this time. There are far too many chances for breakage and it's a blatant disrespect for the feature freeze. The changes are public, though, so we can always retrieve them for Qt 6 when we do it in (say) 4 years time. I don't know the changes in detail, but would it be possible to introduce the container changes under a special namespace instead (think std::tr1)? Then we could still choose to use them in new code and the transition to Qt 6 would be somewhat easier. We can add them, but I don't see a value in doing that if no one is using them. They'll just increase build time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
On Thu, 05 Jul 2012 13:28:58 +0300, Thiago Macieira wrote: We can add them, but I don't see a value in doing that if no one is using them. They'll just increase build time. extra module? I always wondered where to throw stuff that - can't make it (yet) into Qt, - is too small to be its own module, - but useful enough not to be stuck on labs. Basically that was the idea of Qxt, but with modularization these things can happen right in Qt. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Abandoning the container changes
Op 5-7-2012 12:28, Thiago Macieira schreef: We can add them, but I don't see a value in doing that if no one is using them. They'll just increase build time. How could we use it, if it is not included? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
