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
> > (QTextEdit, QText
Il 22/03/2017 15:28, Michael Winkelmann ha scritto:
> Does that mean that QList would simply be a C++11 template alias for
> QVector?
That's one option on the table, I guess. On one side, it's simple to
implement, on the other side, requires fixing all the code that was
overloaded on QVector and Q
Does that mean that QList would simply be a C++11 template alias for
QVector?
On 18.03.2017 19:15, Thiago Macieira wrote:
> But as time went by, I don't think that hybrid approach is valid. A vector is
> simply much better. For Qt 6, I'd like QVector and QList to be the same type
> -- possibly
On 22 March 2017 at 13:14, Philippe wrote:
> by user, I meant "application programmer using Qt" :)
So did I. :) The question for a free utility function and a base class
is the same: are they exposed
in any way? If not, neither of them is something the application
programmer cares about, and thus
by user, I meant "application programmer using Qt" :)
Philippe
On Wed, 22 Mar 2017 13:08:19 +0200
Ville Voutilainen wrote:
> On 22 March 2017 at 13:03, Philippe wrote:
> > Externalizing sharing brings more flexibility indeed, but at the price
> > of more complexity on the user side, ie. less c
On 22 March 2017 at 13:03, Philippe wrote:
> Externalizing sharing brings more flexibility indeed, but at the price
> of more complexity on the user side, ie. less convenience...
Whether the sharing is done in a private base or via free functions is
not visible to the user.
__
Externalizing sharing brings more flexibility indeed, but at the price
of more complexity on the user side, ie. less convenience...
Philippe
On Wed, 22 Mar 2017 11:22:37 +0100
Marc Mutz wrote:
> On 2017-03-22 10:36, Edward Welbourne wrote:
> > On Wednesday 22 March 2017 07:37:27 Thiago Macieira
On 2017-03-22 10:36, Edward Welbourne 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.
Marc Mutz (22 March 2017 09:27)
NAK to inheriting from QStringView, publicly or privately
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.
Marc Mutz (22 March 2017 09:27)
> NAK to inheriting from QStringView, publicly or privately. NAK to
> adding another pointer.
Is the
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. NAK to adding
another pointer.
If you need a base class for your Q6String
> On 22 Mar 2017, at 10:39, Martin Smith wrote:
>
> >The whole issue here is the "sure it is longer".
>
> It's not the WHOLE issue. If you encounter...
>
> auto keys = theHash.keys();
>
> ...in someone's code, you have to look around in the rest of the code to
> figure out what keys is, un
>The whole issue here is the "sure it is longer".
It's not the WHOLE issue. If you encounter...
auto keys = theHash.keys();
...in someone's code, you have to look around in the rest of the code to figure
out what keys is, unless you are already familiar with the keys() function for
whatever
12 matches
Mail list logo
