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 sou
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 declarat
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
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
th
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 na
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 namespac
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
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, th
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 us
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 ar
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 anythi
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
>> reduce
>
> 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 essen
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
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 b
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 commun
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 cont
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 exa
at 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
> 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
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
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
he 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: [De
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:
> > > >
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 appl
On Tuesday July 17 2012, Andre Somers wrote:
> Op 16-7-2012 23:52, Thiago Macieira schreef:
[...]
> > That includes the fact that QList 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 th
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 t
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
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
On quinta-feira, 5 de julho de 2012 15.30.27, André Somers wrote:
> 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?
Chicken-and-the-
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@
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 i
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 breaka
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
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
35 matches
Mail list logo
