Re: [Development] QtCS2019 Notes: QtCore
On Saturday, 23 November 2019 13:55:52 CET André Pönitz wrote: > Also, replacing size() by count() would be easy to do in e.g. Creator > (effectively a single global renaming of size() to count() and discarding > the changes to Qt itself). > > Wrapping int() around requires more manual work. I understand, but I think this is the type of change that will eventually become a problem down the road. We think it can help with porting, but it may later introduce subtle bugs by truncating sizes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Notes from "Releasing" session in QtCon19
Hi all, The script creating the changlog still oversees a lot of QTBUG - > entries. I could not find out why the bug number is sometimes added to> the changelog entry and sometimes doesn't.> See for example> https://codereview.qt-project.org/c/qt/qtbase/+/281862/2..3/dist/changes-5.14.0 I've experienced the same with https://codereview.qt-project.org/c/qt/qtserialbus/+/281838/1..4/dist/changes-5.14.0 Had to add many of them by hand. Greetings, André Cheers, Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: QtCore
On Sat, Nov 23, 2019 at 12:48:12PM +0100, Thiago Macieira wrote: > On Saturday, 23 November 2019 09:47:23 CET André Pönitz wrote: > > So let's make this a real proposal: Should we have > > > >qsizetype QContainer::size() > >int QContainer::count() const > > So you propose changing code like > > int n = vec.size(); > to > int n = vec.count(); > while we could just change it to: > int n = int(vec.size()); > > If we're going to make changes anyway, why not make the right change? int n = vec.count(); is less ugly than int n = int(vec.size()); It's less to type, less to read, one level of parantheses less. Also, replacing size() by count() would be easy to do in e.g. Creator (effectively a single global renaming of size() to count() and discarding the changes to Qt itself). Wrapping int() around requires more manual work. Peppe has a point that the problem exists for other functions like indexOf(), but e.g. in Creator code that's used far less frequently than size() (about an order of magnitude less) so having to use int(indexOf(...)) is less of a pain than the .size() case. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: QtCore
On Saturday, 23 November 2019 09:47:23 CET André Pönitz wrote: > So let's make this a real proposal: Should we have > >qsizetype QContainer::size() >int QContainer::count() const So you propose changing code like int n = vec.size(); to int n = vec.count(); while we could just change it to: int n = int(vec.size()); If we're going to make changes anyway, why not make the right change? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: Clang-based cpp parser for lupdate
On Fri, Nov 22, 2019 at 12:25:21PM +, Joerg Bornemann wrote: On the topic of switching to gettext: My searches yielded nothing. because our archives are incomplete and badly indexed, and clearly nobody bothered to make a jira task (at least a publicly visible one). It would be cool to know where this was discussed before. notes from the 1st qtcs: https://lists.qt-project.org/pipermail/qt5-feedback/2011-June/000632.html small followup: https://lists.qt-project.org/pipermail/qt5-feedback/2011-July/000683.html the real discussion happened on the kde side: http://kde.6490.n7.nabble.com/Translation-in-Qt5-td1135058.html and resulted in a master thesis level document: http://nedohodnik.net/gettextbis/ obviously, this is about a lot more than just switching from l* to gettext - gotta think big when you break everything anyway. ;) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: QtCore
Il 23/11/19 09:47, André Pönitz ha scritto: So let's make this a real proposal: Should we have qsizetype QContainer::size() int QContainer::count() const ? It's an idea, but overly confusing and will make our API a mess. (Also, concretely, what about count(T), indexOf(T), capacity(), removeAll(T), length(), all the functions returning QVector::iterator::difference_type?) I'd rather break ODR by offering a porting macro that applications can set, and that makes the APIs return int (but everything still uses qsizetype internally). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Notes from "Releasing" session in QtCon19
Am 20.11.2019 um 15:11 schrieb Kai Köhne: Hi, I took the notes for the "Releasing" Session we just had at the Qt Contributor Summit 2019: https://wiki.qt.io/Qt_Contributor_Summit_2019_-_Releasing_Notes High level summary: * The Releasing Dashboard [1] in JIRA provides a good overview of upcoming releases, Qt Creator releases will be added there, too. * We should list all contributors of a release in the ChangeLog (AP Jani Heikkinen) * Let's encourage people to help editing ChangeLogs (gerrit in-editing) (AP everyone) * Next time for release meeting (cancellations) will be (also) announced in IRC channel topic (AP Jani Heikkinen) The script creating the changlog still oversees a lot of QTBUG - entries. I could not find out why the bug number is sometimes added to the changelog entry and sometimes doesn't. See for example https://codereview.qt-project.org/c/qt/qtbase/+/281862/2..3/dist/changes-5.14.0 Cheers, Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtCS2019 Notes: QtCore
On Fri, Nov 22, 2019 at 08:01:30PM +0100, Giuseppe D'Angelo via Development
wrote:
> Il 22/11/19 18:49, Thiago Macieira ha scritto:
> > We decided not to add q6sizetype. Just add a "### Qt6: qsizetype" comment
> > where you can't use qsizetype in Qt 6. We'll deal with conflicts.
>
> Sorry, what do you mean by "conflicts"? I mean that there's countless code
> today that uses "int s = foo.size()" (or indexOf, or similar); such code
> will now trigger narrowing warnings.
>
> > There's always QVector::size_type, QByteArray::size_type and
> > QString::size_type if you really need to be explicit and that's fine today.
>
> The chance that non-generic code uses this is practically 0 and we know it.
> Yes, "auto" will work, but still has anyone actually did the exercise on a
> big codebase (Creator, KDE, ...) and checked how many warnings are we
> talking about?
My current assumption is that it will be an unrealistic effort to actually
fix the cause for the warning, so not enabling narrowing warnings flags is
the most likely cause of action at least for Qt Creator.
Now that you spell out the problem, it occurs to me that we might
even have the cake and eat it in this case:
Most (all?) containers have currently several functions to return their
size, e.g. QVector::{size,count,length}. We could one of them continue
to return an int.
So adapting a codebase would be just replacing the now qsizetype-returning
variant by an int-returning variant, which is rather easy and safe, compared
to fiddling with actual type changes.
So let's make this a real proposal: Should we have
qsizetype QContainer::size()
int QContainer::count() const
?
Andre'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
