Re: [Development] QList

23 mars 2017 kl. 17:22 skrev Thiago Macieira : > > You're contradicting yourself now. If private inheritance is not is-a, then > you can't tell me not to use private inheritance because QString isn't a > QStringView. > > I don't want QStringView to appear to users

Re: [Development] [Interest] pushing a WIP

On quarta-feira, 22 de março de 2017 10:17:03 PDT Patrick Stinson wrote: > I am not new to git but am new to growing out of using git as if it were > svn. I have a local work in progress branch (apple--pencil) based on dev, > and want to know how to push it to a feature branch on dev. Should I

Re: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug

Hi Thiago, BTN_TRIGGER_HAPPYxy are a group of kernel #defines, apparently for drivers not supported by the 2.6 kernels. Here are my dev notes: ... Qt-5.8.0 then compiled against gcc-5.4.0 with only one minor problem:

Re: [Development] QList

On Thu, 23 Mar 2017 14:22:36 -0700 Thiago Macieira wrote: > > > > return qFindChar(*this, ch, from, cs); > > > > or > > > > return qFindString(*this, QStringView(, 1), from, cs); > > > > where only the qFoo() functions are exported, but none of the > >

Re: [Development] QList

On quinta-feira, 23 de março de 2017 13:46:24 PDT Marc Mutz wrote: > On Thursday 23 March 2017 21:11:16 Thiago Macieira wrote: > > On quinta-feira, 23 de março de 2017 12:54:53 PDT Thiago Macieira wrote: > > > Then my QString and QByteArray updates are still mostly valid and can be > > > taken in

Re: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug

On quinta-feira, 23 de março de 2017 13:57:07 PDT Ed Leaver wrote: > On 03/23/2017 01:43 PM, Thiago Macieira wrote: > > On quinta-feira, 23 de março de 2017 10:59:25 PDT Ed Leaver wrote: > >> will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think > >> this worthwhile, have you a

Re: [Development] QList

On quinta-feira, 23 de março de 2017 14:12:23 PDT Marc Mutz wrote: > > I beg to differ. It *is* "is-a": any modifiable QString is also a view to > > itself. > > "is-a" is a terminus technicus. It means is-subtype-of aka. > https://en.wikipedia.org/wiki/Liskov_substitution_principle > > > Also,

Re: [Development] QList

On Thursday 23 March 2017 21:16:55 Thiago Macieira wrote: > On quinta-feira, 23 de março de 2017 12:41:56 PDT Marc Mutz wrote: > > On 2017-03-23 19:27, Thiago Macieira wrote: > > > In the mean time: why do you care if some class derives from > > > QStringView? > > > > Because it's _wrong_. > > >

Re: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug

On 03/23/2017 01:43 PM, Thiago Macieira wrote: On quinta-feira, 23 de março de 2017 10:59:25 PDT Ed Leaver wrote: will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think this worthwhile, have you a Qt-5.9.0-beta source tarball? You can't turn C++11 off since 5.7.0. Thanks.

Re: [Development] QList

On Thursday 23 March 2017 21:11:16 Thiago Macieira wrote: > On quinta-feira, 23 de março de 2017 12:54:53 PDT Thiago Macieira wrote: > > Then my QString and QByteArray updates are still mostly valid and can be > > taken in for Qt 6. The one change I probably want to make is to start > > using

Re: [Development] RFC: Containers member functions for algorithm

On quinta-feira, 23 de março de 2017 02:36:06 PDT Marc Mutz wrote: > Second, that member functions always get their *this argument passed by > reference. A free function can take the argument by value instead. The example for this is actually in the other thread: QStringView::indexOf(). If you

Re: [Development] QList

On 23 March 2017 at 21:57, Thiago Macieira wrote: >> A base class that a user can name is detectable in multiple >> inheritance scenarios. >> Once you add such a base, it becomes hard to remove it, regardless of its >> size. > > True, but remember I am proposing as a

Re: [Development] QList

On quinta-feira, 23 de março de 2017 12:41:56 PDT Marc Mutz wrote: > On 2017-03-23 19:27, Thiago Macieira wrote: > > In the mean time: why do you care if some class derives from > > QStringView? > > Because it's _wrong_. > > It does not model is-a, so public inheritance is out of the question.

Re: [Development] QList

On quinta-feira, 23 de março de 2017 12:54:53 PDT Thiago Macieira wrote: > Then my QString and QByteArray updates are still mostly valid and can be > taken in for Qt 6. The one change I probably want to make is to start using > size_t and ssize_t like QStringView does. BTW, should we have a

Re: [Development] QList

On quinta-feira, 23 de março de 2017 11:33:37 PDT Ville Voutilainen wrote: > On 23 March 2017 at 20:27, Thiago Macieira wrote: > > In the mean time: why do you care if some class derives from QStringView? > > We certainly need to discuss the presence of an extra

Re: [Development] QList

On quinta-feira, 23 de março de 2017 12:28:54 PDT Marc Mutz wrote: > On 2017-03-23 19:20, Thiago Macieira wrote: > > Actually, the QStringView class makes me need to sit down and rewrite a > > lot of > > the code. > > This I do not understand. QStringView has nothing to do with QString, > any

Re: [Development] Use of std::function in Qt API

On quinta-feira, 23 de março de 2017 12:13:09 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > > The point however is that if libstdc++ does break its ABI, then you'll > > have > > to rebuild half the world anyway. The few libraries and applications that > > did use Qt and were not affected would

Re: [Development] QList

On 2017-03-23 19:27, Thiago Macieira wrote: On quarta-feira, 22 de março de 2017 01:27:54 PDT Marc Mutz wrote: NAK to inheriting from QStringView, publicly or privately. NAK to adding another pointer. BTW, just to be clear: I am not accepting this discussion as closed. I only had this idea

Re: [Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug

On quinta-feira, 23 de março de 2017 10:59:25 PDT Ed Leaver wrote: > will attempt gcc-4.8.2 -no-std=c++11 in the next few days. If you think > this worthwhile, have you a Qt-5.9.0-beta source tarball? You can't turn C++11 off since 5.7.0. -- Thiago Macieira - thiago.macieira (AT) intel.com

Re: [Development] QList

On 2017-03-23 19:20, Thiago Macieira wrote: Actually, the QStringView class makes me need to sit down and rewrite a lot of the code. This I do not understand. QStringView has nothing to do with QString, any more than it has to do with std::u16string. Well, if you skip that idea with one

Re: [Development] Use of std::function in Qt API

On lunes, 20 de marzo de 2017 12:11:17 -03 Thiago Macieira wrote: > Em segunda-feira, 20 de março de 2017, às 11:53:50 PDT, Lisandro Damián > > Nicanor Pérez Meyer escreveu: > > In the (2) case it will mean that we distro packagers will be forced to > > change Qt's SONAME. Yeah, the whole of it.

Re: [Development] RFC: Containers member functions for algorithm

On quinta-feira, 23 de março de 2017 00:32:14 PDT Olivier Goffart wrote: > Hi everyone, > > I have been wondering if we should enhance Qt container with member > functions to help using some of the standard algorithm. > a peace of code is better than many words. We would be able to do: [cut] I

Re: [Development] QList

On 23 March 2017 at 20:27, Thiago Macieira wrote: > In the mean time: why do you care if some class derives from QStringView? > We certainly need to discuss the presence of an extra pointer inside, as that > has a cost. But derivation? A base class that a user can

Re: [Development] QList

On quarta-feira, 22 de março de 2017 01:27:54 PDT Marc Mutz wrote: > NAK to inheriting from QStringView, publicly or privately. NAK to adding > another pointer. BTW, just to be clear: I am not accepting this discussion as closed. I only had this idea a while ago, so I have not yet throught it

Re: [Development] QList

On quarta-feira, 22 de março de 2017 02:36:19 PDT Edward Welbourne wrote: > Is there scope for a common (perhaps private) base, to be used by (at > least) QString and QStringView, something along the lines of a Java > interface ? That was an alternative I didn't post because I hadn't yet throught

Re: [Development] QList

On quarta-feira, 22 de março de 2017 01:27:54 PDT Marc Mutz wrote: > On Wednesday 22 March 2017 07:37:27 Thiago Macieira wrote: > > Another thing I'd want is for QStringView to carry the pointer to the > > QArrayData like QString does. > > NAK to inheriting from QStringView, publicly or

[Development] Qt-5.9.0-beta on CentOS-6.8: one minor BTN_TRIGGER_HAPPY bug

Hi. Two binary questions: 1. I've been doing some compile testing of Qt-5.8.0 on CentOS-6.8. Only one minor bug in non-critical (to me) component, simple work-around. Would like to test Qt-5.9.0-beta, see if there's an easy way to automatically disable

Re: [Development] PSA: Blacklisting test for CI-runs only

To emphasize on aspect of this PSA: This only works for tests in Qt 5.9 and onwards (once qtbase merged), not for older branches of Qt. Simon From: Development on behalf of Tor Arne Vestbø

[Development] first Qt 5.9.0 beta snapshot available

Hi all, We have finally first Qt 5.9.0 beta snapshot available via Qt Online Installer for mac and linux users, windows one coming later today or tomorrow morning. Snapshot is smoke tested & seems to be pretty much OK. Please download the snaphot (instructions here:

Re: [Development] RFC: Containers member functions for algorithm

Il 23/03/2017 10:36, Marc Mutz ha scritto: > Exactly. Bring back qSort(Container &), calling std::sort(std::begin(c), > std::end(c)). But leave the container interface alone. This could be done "right now" if we add them in a separate namespace. Whether changing qSort itself -- back in the day I

Re: [Development] RFC: Containers member functions for algorithm

I agree, but Marc actually just said that creator could suggest functions with signature f(T) when one presses . after an object o of type T. That's not the same as allowing the syntax o.f() to call f(o). On 23.03.2017 11:51, Konrad Rosenbaum wrote: > On Thursday, March 23, 2017 10:36:06 Marc

Re: [Development] RFC: Containers member functions for algorithm

On Thursday, March 23, 2017 10:36:06 Marc Mutz wrote: > There're > proposals floating around for years to make o.f() fall back to f(o) for std > C++. Those are a lot more pain than you'd think! This construct already exists in C# (static extension classes/methods) and it is causing major

Re: [Development] RFC: Containers member functions for algorithm

The reason why STL is using free function is because it separates data structures (aka containers) and algorithms. A bad example what happens if you dont separate can be seen here: https://www.imagemagick.org/api/Magick++/Image_8h_source.html ...and your data structure will be bloated with member

Re: [Development] RFC: Containers member functions for algorithm

On 2017-03-23 11:01, Ville Voutilainen wrote: On 23 March 2017 at 11:36, Marc Mutz wrote: That said, there's a reason why there's no std::sort(Container &). It's because you need Concepts to disambiguate the various overloads. Well, that and because Eric Niebler doesn't

Re: [Development] RFC: Containers member functions for algorithm

On 23 March 2017 at 11:36, Marc Mutz wrote: > That said, there's a reason why there's no std::sort(Container &). It's > because you need Concepts to disambiguate the various overloads. Well, that > and because Eric Niebler doesn't manage to limit the scope of his range >

Re: [Development] RFC: Containers member functions for algorithm

I hardly imagine a "container" api without a "contains()" member. What I would call good sense. Qt already has this, std not. The other member that makes sense, if "indexOf()"... Qt already has this. For the rest, free functions provide more flexibility. >> I realize that QtCreator already has

Re: [Development] RFC: Containers member functions for algorithm

On Thursday 23 March 2017 09:27:53 Eike Ziller wrote: > I do not think that these belong into the API of the containers though, or > at least if (some of) this API gets into the containers itself, the > implementation should just call generic functions. There is no reason why > the convenience

Re: [Development] RFC: Containers member functions for algorithm

> On Mar 23, 2017, at 8:32 AM, Olivier Goffart wrote: > > Hi everyone, > > I have been wondering if we should enhance Qt container with member functions > to help using some of the standard algorithm. > a peace of code is better than many words. We would be able to do: > >

Re: [Development] RFC: Containers member functions for algorithm

Hi, I love this idea and how it goes into the direction of making life easier (more convenient) for developers. Simon > On 23 Mar 2017, at 08:32, Olivier Goffart wrote: > > Hi everyone, > > I have been wondering if we should enhance Qt container with member functions >

[Development] RFC: Containers member functions for algorithm

Hi everyone, I have been wondering if we should enhance Qt container with member functions to help using some of the standard algorithm. a peace of code is better than many words. We would be able to do: myList.sort(); //or myList.sort([](auto , auto ){ return a.member < b.member; }); if

Re: [Development] Diff between Qt-5.7.1 and Qt-5.8.0 on Android - Pointer Below the Cursor at Text Fields

On Tue, Mar 21, 2017 at 4:06 PM, Olivier Goffart wrote: > On Sonntag, 19. März 2017 09:39:57 CET Robert Iakobashvili wrote: > > Nexus-7 with Android-6 > > The same Qt app built with 5.7.1 works properly > > and with 5.8.0 appears a blue pointer down the cursor at text fields >