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 as a base of QString. I just
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 just
On quinta-feira, 23 de março de 2017 14:54:20 PDT Ed Leaver wrote:
> 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
>
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:
qt-everywhere-opensource-src-5.8.0/qtgamepad/src/plugins/gamepads
On Thu, 23 Mar 2017 14:22:36 -0700
Thiago Macieira wrote:
> >
> > return qFindChar(*this, ch, from, cs);
> >
> > or
> >
> > return qFindString(*this, QStringView(&ch, 1), from, cs);
> >
> > where only the qFoo() functions are exported, but none of the
> > QString/View/Ref members.
>
> I d
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 f
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 Qt
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
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_.
> >
>
I am not entirely sure about BIG projects, but my medium sized one works
fine with qbs, there are even some custom modules thrown in that handle
.proto and grpc files for code generation and it works like magic. Doesnt
exactly support qtlinguist atm though, so you will have to find a way
around tha
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. Save
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 size_
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 wr
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 private base, so it's not expo
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.
I
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 public
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 pointer inside, as
> > that has a
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 more
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
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 a
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
Sof
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 inhe
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.
>
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 li
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 name is detectable in multiple
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 com
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
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 privately.
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
qtgamepad/src/plugins/gamepads/evdev/qev
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ø
Sent: Thursday, March 23, 2017 3:55:30 PM
To: development@qt-projec
Hi everyone,
It's now possible to blacklist tests only when run in the CI. You do
this by adding the 'ci' keyword to the normal list of keywords when
blacklisting a test, eg:
[someTestFunction]
osx-10.8 ci
See also https://bugreports.qt.io/browse/QTBUG-59564
This results in the test being b
On Thursday, March 23, 2017 11:12:31 AM CET Giuseppe D'Angelo wrote:
> Il 23/03/2017 10:50, Philippe ha scritto:
> > 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 "inde
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:
https://wiki.qt.io/How_to_ge
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
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 Mut
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 headache
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
Il 23/03/2017 10:50, Philippe ha scritto:
> 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.
Bikeshedding: this implies that your container
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 manage to limit the sco
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
> proposals.
The TS proposa
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 h
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 shou
> 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:
>
> myList.sort();
> //
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
> to help using some of
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 &a, auto &b){ return a.member < b.member; });
if (
45 matches
Mail list logo
