Op 01/11/2017 om 22:27 schreef Thiago Macieira:
> On quarta-feira, 1 de novembro de 2017 13:15:11 PDT André Somers wrote:
>> That doesn't make sense. Of course it allows for that.
>>
>> You'd give indexOf a flag like Qt::searchTowardsBeginning (default being
>> Qt::searchTowardsEnd) to determine
On quarta-feira, 1 de novembro de 2017 13:15:11 PDT André Somers wrote:
> That doesn't make sense. Of course it allows for that.
>
> You'd give indexOf a flag like Qt::searchTowardsBeginning (default being
> Qt::searchTowardsEnd) to determine the direction to search in. Or do you
> mean that you w
Op 01/11/2017 om 21:00 schreef Thiago Macieira:
> On quarta-feira, 1 de novembro de 2017 12:03:27 PDT André Somers wrote:
>> Using signed for size types is crucial because the API expects to be able to
>>> count backwards from the end and needs to report failure in other
>>> situations. So unsign
On quarta-feira, 1 de novembro de 2017 12:03:27 PDT André Somers wrote:
> Using signed for size types is crucial because the API expects to be able to
> > count backwards from the end and needs to report failure in other
> > situations. So unsigned is simply ruled out.
>
> I think we're stuck with
01.11.2017, 18:50, "Philippe" :
>> Using unsigned for size types is crucial in preventing signed overflow in
>> pathological cases.
>
> During this interactive conference of "C++ gurus" (Herb Sutter, Bjarne
> Stroustrup, Andrei Alexandrescu, Stephan T. Lavavej, Chandler Carruth,
> Sean Parent,
On 2017-10-30 09:04, iman ahmadvand wrote:
> But we've some new widgets beside the existing widgets, for example:
>
> Switch: https://material.io
> /guidelines/components/selection-controls.html#selection-controls-switch
Why not add this to Qt?
Personally, I am not convinced that UI elements tha
Op 01/11/2017 om 16:46 schreef Thiago Macieira:
> On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote:
>>> No, not really, since it's already limited to half the full VM space. No
>>> object can be larger than that. Using unsigned is unnecessary.
>> Using unsigned for siz
On quarta-feira, 1 de novembro de 2017 08:58:35 PDT Konstantin Tokarev wrote:
> > There are also no pathological cases since there is no overflow.
>
> There is overflow, try e.g. QByteArray::fromBase64() with array of size
> larger than INT_MAX / 3
Everywhere where they may be overflow, you need
01.11.2017, 18:46, "Thiago Macieira" :
> On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote:
>> > No, not really, since it's already limited to half the full VM space. No
>> > object can be larger than that. Using unsigned is unnecessary.
>>
>> Using unsigned for size
On 1 November 2017 at 17:46, Thiago Macieira wrote:
> On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote:
>> > No, not really, since it's already limited to half the full VM space. No
>> > object can be larger than that. Using unsigned is unnecessary.
>>
>> Using unsigned
> Using unsigned for size types is crucial in preventing signed overflow in
> pathological cases.
During this interactive conference of "C++ gurus" (Herb Sutter, Bjarne
Stroustrup, Andrei Alexandrescu, Stephan T. Lavavej, Chandler Carruth,
Sean Parent, Scott Meyers, Michael Wong), it is clearly st
On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote:
> > No, not really, since it's already limited to half the full VM space. No
> > object can be larger than that. Using unsigned is unnecessary.
>
> Using unsigned for size types is crucial in preventing signed overflow i
On quarta-feira, 1 de novembro de 2017 08:21:10 PDT Thiago Macieira wrote:
> "Won't that limit the actual maximum size?"
>
> No, not really, since it's already limited to half the full VM space. No
> object can be larger than that. Using unsigned is unnecessary.
Huh... on second thought, this lim
01.11.2017, 18:21, "Thiago Macieira" :
> On quarta-feira, 1 de novembro de 2017 05:23:04 PDT Иван Комиссаров wrote:
>> Sorry for digging the thread, but how is
>> * use qssize_t
>> and
>> ** Wrapping std::{unordered_}map may be acceptable
>> combines?
>> std::*map uses size_t in it's API (
On quarta-feira, 1 de novembro de 2017 05:23:04 PDT Иван Комиссаров wrote:
> Sorry for digging the thread, but how is
> * use qssize_t
> and
> ** Wrapping std::{unordered_}map may be acceptable
> combines?
> std::*map uses size_t in it's API (size, max_size, count, reserve,
> begin(size_type), en
Hi,
Yet another update. We narrowed down the IO issue. The network update from 1G
to 10G, mentioned before, brought compellent into the picture and that one
didn't want to cooperate nicely with our btrfs installation, for an unknown
reason. The link will be downgraded and we would go back to
Hi all,
We have soft branched '5.9.3' from '5.9'. So please start using '5.9.3' for new
changes targeted to Qt 5.9.3 release. Final downmerge from '5.9' to '5.9.3'
will happen Wed 8th November so there should be enough time to finalize ongoing
changes in '5.9' and start using '5.9.3' for new o
> Using virtual functions for allocation/deallocation doesn't seem like a
> bright idea
If you speak about performances, then you are wrong. The impact is
neglictable compared to the rest of the allocations. This has been
proved by the guys that pushed that C++17 feature, with extensive
benchmark
01.11.2017, 15:30, "Philippe" :
> And offtop - what about allocators? They would be accesibble for wrappers,
> but not accesible for QVector/QString?
>
> Something sure, a Qt6 feature such as std::pmr::memory_resource (cf.
> https://www.youtube.com/watch?v=v3dz-AKOVL8) would be more than welcom
And offtop - what about allocators? They would be accesibble for wrappers, but
not accesible for QVector/QString?
Something sure, a Qt6 feature such as std::pmr::memory_resource (cf.
https://www.youtube.com/watch?v=v3dz-AKOVL8) would be more than welcome for Qt
containers and strings.
Philippe
Sorry for digging the thread, but how is
* use qssize_t
and
** Wrapping std::{unordered_}map may be acceptable
combines?
std::*map uses size_t in it's API (size, max_size, count, reserve,
begin(size_type), end(size_type))
And offtop - what about allocators? They would be accesibble for wrappers,
Hi all,
Qt 5.10 beta3 is available. You can update it at the top of your Qt 5.10
beta(2) online installation or do clean installation by using qt online
installer. Detailed instructions here:
https://wiki.qt.io/How_to_get_snapshot_via_online_installer
br,
Jani Heikkinen
Release Manager
___
Hi all,
Qt 5.10 beta3 is out. Instructions how to get the release are here:
https://wiki.qt.io/How_to_get_snapshot_via_online_installer.
So please test the packages and make sure all issues which must be fixed before
final Qt 5.10.0 release are visible in rc blocker list
(https://bugreports.qt
On Wednesday, November 1, 2017 10:16:53 AM CET Jedrzej Nowacki wrote:
> On Wednesday, November 1, 2017 8:50:06 AM CET Jedrzej Nowacki wrote:
> > On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote:
> > > Hi all,
> > >
> > > we've had a bunch of unfortunate small things piling up,
30.10.2017, 17:18, "iman ahmadvand" :
> Well.
> If it's OK to add new classes then we can create our classes And do the style
> related things in private part until Qt6 release, on that time we can move
> our changes to QStyle API.
Adding new and missing controls into QtWidgets, like QSwitch, i
On Wednesday, November 1, 2017 8:50:06 AM CET Jedrzej Nowacki wrote:
> On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote:
> > Hi all,
> >
> > we've had a bunch of unfortunate small things piling up, so sadly Coin is
> > down right now. I expect it to be up tomorrow (so in roughl
On Wednesday, November 1, 2017 9:06:20 AM EET Alex Blasche wrote:
> Congratulations. Access rights have been updated.
Thank you!
Andras
--
András Mantia | andras.man...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-
On Tuesday, October 31, 2017 10:11:22 PM CET Frederik Gladhorn wrote:
> Hi all,
>
> we've had a bunch of unfortunate small things piling up, so sadly Coin is
> down right now. I expect it to be up tomorrow (so in roughly 10 hours from
> now) assuming everything now goes smooth.
>
Small update. N
Congratulations. Access rights have been updated.
--
Alex
From: Development
on behalf of Antti Määttä
Sent: Wednesday, 11 October 2017 10:21:45 AM
To: Miikka Heikkinen; Pasi Keränen; development@qt-project.org
Subject: Re: [Development] Nominating Tomi
Congratulations. Access rights have been updated.
--
Alex
From: Development
on behalf of Rafael Roquetto
Sent: Tuesday, 10 October 2017 2:01:47 PM
To: Qt Project Development Mailing-List
Subject: [Development] Nominating Andras Mantia for approver
Howdy
30 matches
Mail list logo
