Re: [Development] Undeprecating QString::null

[Thiago Macieira]

On Tuesday, 16 January 2018 10:28:27 PST Uwe Rathmann wrote:
> On Tue, 16 Jan 2018 18:38:48 +0100, Kevin Kofler wrote:
> > So just use QString(), or define your own static instance of it if you
> > really want to microoptimize it that much.
> 
> No it is simply that the first version of Qwt was for Qt 1.2 ( before
> QString even existed ) and during a history of almost 20 years there are
> leftovers.

Nitpick: QString existed in Qt 1.2, it just wasn't the QString we know.

It was actually the predecessor to Qt 2's QCString, which in Qt 4 became 
Q3CString and was deprecated by QByteArray.

> I had missed the point, when the static instance had been replaced -
> that's why I was erroneously concerned about BC breaks.

There's still static data, but unlike the Qt 1 solution, it's not an instance 
of QString but just of the shared null data. Since Qt 5, it's also shared with 
QVector and QByteArray. That's why the constructor is just as efficient.

-- 
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] Undeprecating QString::null

[Uwe Rathmann]

On Tue, 16 Jan 2018 18:38:48 +0100, Kevin Kofler wrote:

> So just use QString(), or define your own static instance of it if you
> really want to microoptimize it that much.

No it is simply that the first version of Qwt was for Qt 1.2 ( before 
QString even existed ) and during a history of almost 20 years there are 
leftovers.

I had missed the point, when the static instance had been replaced - 
that's why I was erroneously concerned about BC breaks.

Uwe



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

Re: [Development] Undeprecating QString::null

[Kevin Kofler]

Uwe Rathmann wrote:
> So my first question would be, what is wrong about using QString:null and
> why using QString() is better. My second question then would be if this
> is also for Qt4 ( Qwt 6.1.2 supports all versions >= Qt 4.4 ) and older
> versions of C++ and compilers.

A long long time ago, QString::null used to be a static instance of 
QString(). This was more efficient than QString() in a context like this one 
where a const QString & is needed, but less efficient in many contexts where 
people (ab)used it, e.g.:
QString foo = QString::null;
which should really be just:
QString foo;

Thus, now, QString::null is just a static instance of an empty structure, 
and converting that structure to QString is the same as QString(), so there 
is no longer any performance benefit from using QString::null. This was 
already the case in Qt 4. Even Qt 3.3.8b already had that change.

So just use QString(), or define your own static instance of it if you 
really want to microoptimize it that much.

Kevin Kofler

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

Re: [Development] Undeprecating QString::null

[Uwe Rathmann]

On Tue, 16 Jan 2018 17:54:43 +0100, Giuseppe D'Angelo wrote:

> headers of 3rd party libraries
> should be included under -isystem, not -I, to disable warnings in their
> headers.

Yes as there seems to be no BC break ( thanks to all correcting me, I 
should have a deeper look at the code before ) this is a reasonable 
recommendation - at least for platforms, where the option is available - 
I can give my users for now.

Sorry for the noise,
Uwe

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

Re: [Development] Undeprecating QString::null

[Alexander Nassian]

No it isn‘t about you. But your message suggested you blame it on Qt project ;)

Anyway, default values are not part of a functions signature and don’t break 
binary compatibility.

Beste Grüße / Best regards,
Alexander Nassian

> Am 16.01.2018 um 17:46 schrieb Uwe Rathmann :
> 
>> On Tue, 16 Jan 2018 17:26:51 +0100, Alexander Nassian wrote:
>> 
>> Deprecated since Qt4 ...
> 
> According to qstring.h:
> 
> #if QT_DEPRECATED_SINCE(5, 9)
> ...
> #endif
> 
> But come this is not about me and if I missed, that an API has been 
> declared as deprecated. It is about what to best in the current situation.
> 
> Uwe
> 
> 
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
 


—

bitshift dynamics GmbH
Neudorfer Str. 1, 79541 Lörrach
Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747
Geschäftsführer: Alexander Nassian, Markus Pfaffinger

http://www.bitshift-dynamics.de

Zentrale: +49 762158673 - 0
Fax: +49 7621 58673 - 90

Allgemeine Anfragen: i...@bitshift-dynamics.com
Technischer Support: supp...@bitshift-dynamics.com
Buchhaltung: invo...@bitshift-dynamics.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Undeprecating QString::null

[Giuseppe D'Angelo]

Il 16/01/2018 16:20, Uwe Rathmann ha scritto:

Sure this is only a warning, but it is obviously something where Qwt
users get irritated as they can't fix code of a 3rd party header.


Changing to QString() is BC, as explained, so just do that. Note that 
this is actually a buildsystem issue: headers of 3rd party libraries 
should be included under -isystem, not -I, to disable warnings in their 
headers.


Hope this helps,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Undeprecating QString::null

[Uwe Rathmann]

On Tue, 16 Jan 2018 17:26:51 +0100, Alexander Nassian wrote:

> Deprecated since Qt4 ...

According to qstring.h:

#if QT_DEPRECATED_SINCE(5, 9)
...
#endif

But come this is not about me and if I missed, that an API has been 
declared as deprecated. It is about what to best in the current situation.

Uwe





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

Re: [Development] Undeprecating QString::null

[Konstantin Ritt]

changing the parameter's default value *is* binary compatible.


Regards,
Konstantin

2018-01-16 20:35 GMT+04:00 Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com>:

> > The "just change" introduces a binary incompatibility - right ?
>
> I don't think it does: the QString is constructed on the caller's side
> anyways and your function is always passed a QString object;
> if you had an app that linked to qwt and didn't recompile it will just
> keep calling QString::null() from its side and pass the resulting object to
> your function.
>
> Best,
> Jean-Michaël
>
> On Tue, Jan 16, 2018 at 5:22 PM, Konstantin Tokarev 
> wrote:
>
>>
>>
>> 16.01.2018, 19:18, "Uwe Rathmann" :
>> > On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
>> >
>> >>  Just change your code to use "= QString()", no #ifdef necessary.
>> >
>> > The "just change" introduces a binary incompatibility - right ?
>> >
>> > Please be aware, that Qwt is part of almost any Linux distro - according
>> > to sourceforge it has more than 1000 additional downloads every week
>> > since many years.
>> >
>> > All distro maintainers would not only have to upgrade the Qwt packages,
>> > but also all packages depending on it - users would have to rebuild.
>>
>> However, it seems like amount of reverse dependencies of Qwt is rather
>> moderate, e.g. in Ubuntu I see
>>
>>   libqwt6:i386
>>   zygrib
>>   simon
>>   qsapecng
>>   qgis
>>   nlkt
>>   libqwt-dev
>>   libqgis-gui2.0.1
>>
>>
>> >
>> > Considering the strict compatibility rules you have for Qt you will
>> > understand, that this is nothing I would like to do easily.
>> >
>> > But could you please comment on why this change is an improvement -
>> > beyond getting rid of 3-4 lines in qstring.h ?
>>
>> Because having redundancies in API is bad maybe?
>>
>> >
>> > Thanks,
>> > Uwe
>> >
>> > ___
>> > Development mailing list
>> > Development@qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/development
>>
>> --
>> Regards,
>> Konstantin
>> ___
>> 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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Undeprecating QString::null

[Eike Ziller]

> On Jan 16, 2018, at 17:16, Uwe Rathmann  wrote:
> 
> On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
> 
>> Just change your code to use "= QString()", no #ifdef necessary.
> 
> The "just change" introduces a binary incompatibility - right ?

I don’t see why that would be the case, the function signature doesn’t change.

Br, Eike

> 
> Please be aware, that Qwt is part of almost any Linux distro - according 
> to sourceforge it has more than 1000 additional downloads every week 
> since many years.
> 
> All distro maintainers would not only have to upgrade the Qwt packages, 
> but also all packages depending on it - users would have to rebuild.
> 
> Considering the strict compatibility rules you have for Qt you will 
> understand, that this is nothing I would like to do easily.
> 
> But could you please comment on why this change is an improvement - 
> beyond getting rid of 3-4 lines in qstring.h ?
> 
> Thanks,
> Uwe
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

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

Re: [Development] Undeprecating QString::null

[Jean-Michaël Celerier]

> The "just change" introduces a binary incompatibility - right ?

I don't think it does: the QString is constructed on the caller's side
anyways and your function is always passed a QString object;
if you had an app that linked to qwt and didn't recompile it will just keep
calling QString::null() from its side and pass the resulting object to
your function.

Best,
Jean-Michaël

On Tue, Jan 16, 2018 at 5:22 PM, Konstantin Tokarev 
wrote:

>
>
> 16.01.2018, 19:18, "Uwe Rathmann" :
> > On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
> >
> >>  Just change your code to use "= QString()", no #ifdef necessary.
> >
> > The "just change" introduces a binary incompatibility - right ?
> >
> > Please be aware, that Qwt is part of almost any Linux distro - according
> > to sourceforge it has more than 1000 additional downloads every week
> > since many years.
> >
> > All distro maintainers would not only have to upgrade the Qwt packages,
> > but also all packages depending on it - users would have to rebuild.
>
> However, it seems like amount of reverse dependencies of Qwt is rather
> moderate, e.g. in Ubuntu I see
>
>   libqwt6:i386
>   zygrib
>   simon
>   qsapecng
>   qgis
>   nlkt
>   libqwt-dev
>   libqgis-gui2.0.1
>
>
> >
> > Considering the strict compatibility rules you have for Qt you will
> > understand, that this is nothing I would like to do easily.
> >
> > But could you please comment on why this change is an improvement -
> > beyond getting rid of 3-4 lines in qstring.h ?
>
> Because having redundancies in API is bad maybe?
>
> >
> > Thanks,
> > Uwe
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
> --
> Regards,
> Konstantin
> ___
> 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] Undeprecating QString::null

[Alexander Nassian]

Deprecated since Qt4 (so it survived already two versions that were allowed to 
break binary compatibility) means that you had 12 (twelve) years to do the 
migration. How long should it be maintained? And again, it also could have been 
removed in Qt4 or 5.

> Am 16.01.2018 um 17:16 schrieb Uwe Rathmann :
> 
> On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
> 
>> Just change your code to use "= QString()", no #ifdef necessary.
> 
> The "just change" introduces a binary incompatibility - right ?
> 
> Please be aware, that Qwt is part of almost any Linux distro - according 
> to sourceforge it has more than 1000 additional downloads every week 
> since many years.
> 
> All distro maintainers would not only have to upgrade the Qwt packages, 
> but also all packages depending on it - users would have to rebuild.
> 
> Considering the strict compatibility rules you have for Qt you will 
> understand, that this is nothing I would like to do easily.
> 
> But could you please comment on why this change is an improvement - 
> beyond getting rid of 3-4 lines in qstring.h ?
> 
> Thanks,
> Uwe
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
 


--

bitshift dynamics GmbH
Neudorfer Str. 1, 79541 Lörrach
Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747
Geschäftsführer: Alexander Nassian, Markus Pfaffinger

http://www.bitshift-dynamics.de

Zentrale: +49 762158673 - 0
Fax: +49 7621 58673 - 90

Allgemeine Anfragen: i...@bitshift-dynamics.com
Technischer Support: supp...@bitshift-dynamics.com
Buchhaltung: invo...@bitshift-dynamics.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Undeprecating QString::null

[Konstantin Tokarev]

16.01.2018, 19:18, "Uwe Rathmann" :
> On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
>
>>  Just change your code to use "= QString()", no #ifdef necessary.
>
> The "just change" introduces a binary incompatibility - right ?
>
> Please be aware, that Qwt is part of almost any Linux distro - according
> to sourceforge it has more than 1000 additional downloads every week
> since many years.
>
> All distro maintainers would not only have to upgrade the Qwt packages,
> but also all packages depending on it - users would have to rebuild.

However, it seems like amount of reverse dependencies of Qwt is rather
moderate, e.g. in Ubuntu I see

  libqwt6:i386
  zygrib
  simon
  qsapecng
  qgis
  nlkt
  libqwt-dev
  libqgis-gui2.0.1


>
> Considering the strict compatibility rules you have for Qt you will
> understand, that this is nothing I would like to do easily.
>
> But could you please comment on why this change is an improvement -
> beyond getting rid of 3-4 lines in qstring.h ?

Because having redundancies in API is bad maybe?

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

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

Re: [Development] Undeprecating QString::null

[Uwe Rathmann]

On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:

> Just change your code to use "= QString()", no #ifdef necessary.

The "just change" introduces a binary incompatibility - right ?

Please be aware, that Qwt is part of almost any Linux distro - according 
to sourceforge it has more than 1000 additional downloads every week 
since many years.

All distro maintainers would not only have to upgrade the Qwt packages, 
but also all packages depending on it - users would have to rebuild.

Considering the strict compatibility rules you have for Qt you will 
understand, that this is nothing I would like to do easily.

But could you please comment on why this change is an improvement - 
beyond getting rid of 3-4 lines in qstring.h ?

Thanks,
Uwe


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

Re: [Development] Undeprecating QString::null

[Olivier Goffart]

Am Dienstag, 16. Januar 2018, 16:20:54 CET schrieb Uwe Rathmann:
> Hi all,
> 
> I received a bug report concerning a header of the Qwt library ( http://
> qwt.sf.net ), that is using the deprecated QString::null.
> 
> Sure this is only a warning, but it is obviously something where Qwt
> users get irritated as they can't fix code of a 3rd party header.
> 
> The offending line looks like this:
> 
> QwtText( const QString & = QString::null, ... );
> 
> So my first question would be, what is wrong about using QString:null and
> why using QString() is better. My second question then would be if this
> is also for Qt4 ( Qwt 6.1.2 supports all versions >= Qt 4.4 ) and older
> versions of C++ and compilers.
> 
> To be honest I don't want to create a new ( + binary incompatible )
> version of Qwt and/or add even more version depending #ifdefs, as long as
> there is no good reason.

QString::null is a leftover of Qt3 and was already deprecated in Qt 4.0
There was just some forgotten remaining compatibility code that was only 
recently marked as QT_DEPRECATED. 
Just change your code to use "= QString()", no #ifdef necessary.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org



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