On 2017-12-04 21:05, Ville Voutilainen wrote:
Same goes for semantics.
In fact, I'm _mainly_ concerned with semantics. Different method naming
is trivially fixed by tooling these days, as long as the semantics are
the same.
As a trivial example: qAsConst, like std::as_const, has the rvalue
On 4 December 2017 at 21:29, Allan Sandfeld Jensen wrote:
>> > I believe the name "optional" comes from Haskell and Java where it
>> > appeared
>> > first. The standard library only imports things that are already industry
>> > standard, and once there were several implementations of optional out
On Montag, 4. Dezember 2017 15:30:49 CET Ville Voutilainen wrote:
> On 4 December 2017 at 16:20, Allan Sandfeld Jensen wrote:
> > On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote:
> >> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the
> >> Haskell name is maybe. So why i
On Monday, 4 December 2017 06:00:53 PST Marc Mutz wrote:
> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the
> Haskell name is maybe. So why is it QOptional and not QMaybe? Because
> the C++ interface is used as the basis, not something from Haskell.
FYI, I wrote QMaybe some 9 t
04.12.2017, 17:31, "Ville Voutilainen" :
> On 4 December 2017 at 16:20, Allan Sandfeld Jensen wrote:
>> On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote:
>>> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the
>>> Haskell name is maybe. So why is it QOptional and not
On 4 December 2017 at 16:20, Allan Sandfeld Jensen wrote:
> On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote:
>>
>> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the
>> Haskell name is maybe. So why is it QOptional and not QMaybe? Because
>> the C++ interface is used as
On Montag, 4. Dezember 2017 15:00:53 CET Marc Mutz wrote:
>
> Ah, well, yes. Nothing truly originates in C++, true. But, IIRC, the
> Haskell name is maybe. So why is it QOptional and not QMaybe? Because
> the C++ interface is used as the basis, not something from Haskell.
>
I believe the name "o
On 2017-12-03 22:57, Allan Sandfeld Jensen wrote:
On Samstag, 2. Dezember 2017 17:48:19 CET Marc Mutz wrote:
If that analyis were true, you'd need to explain why it is, then, that
the Qt containers now have more or less the same API as std ones, when
in Qt 1 they were very different. And why I k
On Samstag, 2. Dezember 2017 17:48:19 CET Marc Mutz wrote:
> If that analyis were true, you'd need to explain why it is, then, that
> the Qt containers now have more or less the same API as std ones, when
> in Qt 1 they were very different. And why I keep needing to fight off
> QOptional. These are
>> . I would be fine having the same developer experience in C++
>
> even if I had to change name spaces and includes, but doesn't seem usual
>
> practice in C++.
>
> uh... ? I have been polyfilling optional, string_view, any, and variant for
> almost three years with boost, or std/experiment
> . I would be fine having the same developer experience in C++
even if I had to change name spaces and includes, but doesn't seem usual
practice in C++.
uh... ? I have been polyfilling optional, string_view, any, and variant for
almost three years with boost, or std/experimental/. The API is 99%
On Saturday 02 December 2017 19:11:23 Boudewijn Rempt wrote:
> > > And, c'mon, std::optional's API is just not going to be topped by
> > > QOptional. What should they do? snake_case vs. camelCase? That's what
> > > we need to invest several man-days of development work in, to rename
> > > the funct
On 2017-12-02 18:54, Ville Voutilainen wrote:
On 2 December 2017 at 18:48, Marc Mutz wrote:
If that analyis were true, you'd need to explain why it is, then, that
the
Qt containers now have more or less the same API as std ones, when in
Qt 1
they were very different. And why I keep needing to
On Sat, 02 Dec 2017 17:48:19 +0100
Marc Mutz wrote:
> > 1) the std implementation varies with compiler vendors, each one with a
> > different set of bugs, unit tests and sometimes performance. While with
> > Qt, the implementation is more uniform. This to say, I feel more secure
> > using Qt impl
>>And, c'mon, std::optional's API is just not going to be topped by QOptional.
I don't know the QOptional plans (or no-plan), but as today, on the Mac,
the latest XCode 9.1 still does not provide std::optional.
With Qt, at least, when something is available, it is available in all
platforms, and
On Sat, 2 Dec 2017, Ville Voutilainen wrote:
> On 2 December 2017 at 18:48, Marc Mutz wrote:
> > If that analyis were true, you'd need to explain why it is, then, that the
> > Qt containers now have more or less the same API as std ones, when in Qt 1
> > they were very different. And why I keep n
On 2 December 2017 at 18:48, Marc Mutz wrote:
> If that analyis were true, you'd need to explain why it is, then, that the
> Qt containers now have more or less the same API as std ones, when in Qt 1
> they were very different. And why I keep needing to fight off QOptional.
..
> And, c'mon, std::o
On 2017-12-01 23:12, Philippe wrote:
it's existential for Qt to get off its own container classes.
I shall in the future extend that statement to anything that overlaps
with std.
Two points to keep in mind:
1) the std implementation varies with compiler vendors, each one with a
different set o
>>it's existential for Qt to get off its own container classes.
>>I shall in the future extend that statement to anything that overlaps
>>with std.
Two points to keep in mind:
1) the std implementation varies with compiler vendors, each one with a
different set of bugs, unit tests and sometimes
On 1 December 2017 at 22:35, Thiago Macieira wrote:
> In theory, it's possible to use GCC 6 against an old set of libstdc++ headers.
>
> I don't know if the GCC devs officially support this (Ville, can you chime
> in?).
There's no attempt by GCC maintainers to make a newer compiler work
with the
On 2017-12-01 20:57, Marc Mutz wrote:
V8 fork, anyone?
Or was it V4? ETOOMANYJSENGINES
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Friday, 1 December 2017 11:57:33 PST Marc Mutz wrote:
> > Why can't they write
> >
> > QStringView(s1).compare(s2) ?
>
> I think you owe me a bit more thought on an answer to a mail of mine
> that that :P
> A quick look at the qCompareString() overload set will answer this
> question (hint
On Friday, 1 December 2017 10:59:48 PST Jean-Michaël Celerier wrote:
> > (just look at how we have to build Linux binaries with GCC 4.8).
>
> Isn't it possible to use a newer GCC but to tell it to use GCC 4.8's ABI ?
> eg to target GCC 4.8, by using -fabi-version=2 -D_GLIBCXX_USE_CXX11_ABI=0
Don'
On 2017-12-01 19:26, Thiago Macieira wrote:
On Friday, 1 December 2017 01:31:18 PST Marc Mutz wrote:
> Once those operator<=> are there, what benefit is there in having the
> API
> public and documented?
The spaceship operator solves the problem for qCompareStrings(). One
could say we already h
> (just look at how we have to build Linux binaries with GCC 4.8).
Isn't it possible to use a newer GCC but to tell it to use GCC 4.8's ABI ?
eg to target GCC 4.8, by using -fabi-version=2 -D_GLIBCXX_USE_CXX11_ABI=0
Best,
---
Jean-Michaël Celerier
http://www.jcelerier.name
On Fri, Dec 1, 20
On Friday, 1 December 2017 01:31:18 PST Marc Mutz wrote:
> > Once those operator<=> are there, what benefit is there in having the
> > API
> > public and documented?
>
> The spaceship operator solves the problem for qCompareStrings(). One
> could say we already have all relational operators for al
On 2017-11-30 22:13, Thiago Macieira wrote:
On Thursday, 30 November 2017 12:08:45 PST Marc Mutz wrote:
Don't go off on a tangent here. I used concepts syntax to keep the
example simple. I can post with std::enable_if, if you prefer :)
Fair enough, I had not considered that.
Anyway, the poin
On Thursday, 30 November 2017 12:08:45 PST Marc Mutz wrote:
> Don't go off on a tangent here. I used concepts syntax to keep the
> example simple. I can post with std::enable_if, if you prefer :)
Fair enough, I had not considered that.
> Anyway, the point is the asymmetry of member functions.
> u
On 2017-11-30 20:09, Thiago Macieira wrote:
On quinta-feira, 30 de novembro de 2017 10:53:33 PST Marc Mutz wrote:
What's wrong with str.compare()?
Do these two quotes somehow fit together?
template
bool operator==(const LHS &lhs, const RHS &rhs)
{ return qCompareStrings(lhs, rhs) ==
On Thursday, 30 November 2017 11:09:01 PST Thiago Macieira wrote:
> API parallelism with the Standard Library is not required where the standard
> library makes mistakes. Requiring constexpr for calculating string lengths
> is one where I think it made a mistake. Therefore, I will not accept that
>
On quinta-feira, 30 de novembro de 2017 10:53:33 PST Marc Mutz wrote:
> What's wrong with str.compare()?
>
> Do these two quotes somehow fit together?
>
>template
>bool operator==(const LHS &lhs, const RHS &rhs)
>{ return qCompareStrings(lhs, rhs) == 0; }
>
>template
>bool
On 2017-11-30 17:13, Thiago Macieira wrote:
On quinta-feira, 30 de novembro de 2017 06:02:19 PST Marc Mutz wrote:
On 2017-10-10 14:49, Thiago Macieira wrote:
[...]
> * We think members are cleaner and we don't want to add these
You have members where members are possible.
But you can't add mem
On quinta-feira, 30 de novembro de 2017 06:02:19 PST Marc Mutz wrote:
> On 2017-10-10 14:49, Thiago Macieira wrote:
> [...]
>
> > * We think members are cleaner and we don't want to add these
>
> You have members where members are possible.
> But you can't add members to char16_t[]!
Why would we
On 2017-10-10 14:49, Thiago Macieira wrote:
[...]
* We think members are cleaner and we don't want to add these
You have members where members are possible.
But you can't add members to char16_t[]!
* However, we already have some of those! qStartsWith
** Global namespace *and* documented
** f
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,
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
> 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,
Some other comments here and there,
Il 10/10/2017 14:49, Thiago Macieira ha scritto:
[we combined the main and containers session; we did not have time for
QIODevice]
== Intro ==
Suggested topics:
* QIODevice for Qt 6
* adding std::hash for Qt types
As in: we're OK that this should be done.
On Tuesday, 10 October 2017 05:49:48 PDT Thiago Macieira wrote:
> Move to the containers session:
> * use qssize_t
By the way, re: https://bugreports.qt.io/browse/QTBUG-47629
We should use 64-bit in QJsonPrivate too. Specifically, because of the way that
the internal binary JSON format stores va
On wtorek, 17 października 2017 17:28:54 CEST Marc Mutz wrote:
> > (...)
> > Discussion not finished
>
> I certainly hope so, because the above does not make any sense. See my
> talk at QtWS. Returning QStringView is not different from c.begin() or
> str.data(). You need to document the lifetime o
On terça-feira, 17 de outubro de 2017 08:28:54 PDT Marc Mutz wrote:
> On 2017-10-10 14:49, Thiago Macieira wrote:
> > == QStringView ==
> > * NEVER return QStringView (but QRegularExpression wants to)
> > ** Consequence of "never return a reference" (but containers do)
> > ** Lifetime issues
> >
>
On 2017-10-10 14:49, Thiago Macieira wrote:
== QStringView ==
* NEVER return QStringView (but QRegularExpression wants to)
** Consequence of "never return a reference" (but containers do)
** Lifetime issues
auto s = lineedit.text().left(n);
s valid?
* We can be flexible on having exceptio
> (4x difference measured).
wow, good to know.
---
Jean-Michaël Celerier
http://www.jcelerier.name
On Tue, Oct 10, 2017 at 3:33 PM, Thiago Macieira
wrote:
> On Tuesday, 10 October 2017 15:04:29 CEST Jean-Michaël Celerier wrote:
> > > ** Wrapping std::{unordered_}map may be acceptable
> >
On Tuesday, 10 October 2017 15:04:29 CEST Jean-Michaël Celerier wrote:
> > ** Wrapping std::{unordered_}map may be acceptable
>
> Hmmm... from these benchmarks, QHash seems to regularly beat
> std::unordered_map so is it really worth it ?
> => https://tessil.github.io/2016/08/29/benchmark-hopscot
On Tuesday, 10 October 2017 14:49:48 CEST Thiago Macieira wrote:
> * They'd all need to be inline and some could be big
Missing context here: this was about making them templated so they could work
on std::string and other string-like types.
--
Thiago Macieira - thiago.macieira (AT) intel.com
> ** Wrapping std::{unordered_}map may be acceptable
Hmmm... from these benchmarks, QHash seems to regularly beat
std::unordered_map so is it really worth it ?
=> https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html
Besides, with the Qt implementation the performance is more-or-less
[we combined the main and containers session; we did not have time for
QIODevice]
== Intro ==
Suggested topics:
* QIODevice for Qt 6
* adding std::hash for Qt types
* expanding the hash seed to 64- or 128-bit
Move to the containers session:
* use qssize_t
Quick conclusions:
* QRandomGenerator a
62 matches
Mail list logo
