On 15/05/2020 06.39, Edward Welbourne wrote:
Thiago Macieira (15 May 2020 02:30) replied
On Thursday, 14 May 2020 12:34:54 PDT Matthew Woehlke wrote:
On 14/05/2020 14.58, Thiago Macieira wrote:
Which is:
b) misspelling "iteratable"
Be that as it may, that ship has sailed:
https://www.go
On 14/05/2020 14.58, Thiago Macieira wrote:
>>> Which is:
>>> b) misspelling "iteratable"
On Thursday, 14 May 2020 12:34:54 PDT Matthew Woehlke wrote:
>> Be that as it may, that ship has sailed:
>>
>>https://www.google.com/search?q=iteratable
>>
>> Even Google thinks so, and if you insist othe
On Thursday, 14 May 2020 12:34:54 PDT Matthew Woehlke wrote:
> On 14/05/2020 14.58, Thiago Macieira wrote:
> > Which is:
> > b) misspelling "iteratable"
>
> Be that as it may, that ship has sailed:
>
>https://www.google.com/search?q=iteratable
>
> Even Google thinks so, and if you insist oth
> To have type-erased containers, we need to go back to something like
java.lang.Collection.
C++20 offers coroutines which allows the same things without java-like type
hierarchies though
(and with much more flexibility as you don't even need to have an actual
container existing somewhere - your f
On 14/05/2020 14.58, Thiago Macieira wrote:
Which is:
b) misspelling "iteratable"
Be that as it may, that ship has sailed:
https://www.google.com/search?q=iteratable
Even Google thinks so, and if you insist otherwise, 12k results instead
of 2M.
--
Matthew
On Thursday, 14 May 2020 04:20:43 PDT Иван Комиссаров wrote:
> I don’t see the problem here. Ranges library operates on views only, so
> there *should be* (I am just not aware of it’s name) the type that
> corresponds to the «forward access iterator» (well, in case of QSet, that
> would be bidirect
On Thursday, 14 May 2020 02:33:43 PDT Marc Mutz via Development wrote:
> On 2020-05-14 02:15, Thiago Macieira wrote:
> > On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote:
> >> std::span Project::productsSpan() const & { return
> >> d->products; }
> >> std::span Project::produc
On Thu, May 14, 2020 at 11:46:29AM +0200, Marc Mutz via Development wrote:
> > Please stop with this crusade of yours to end all CoW, get rid of
> > QList, etc. It is misguided and harmful to the ecosystem at large.
>
> You are entitled to your opinions just as I am. The difference is that I put
>
I don’t see the problem here. Ranges library operates on views only, so there
*should be* (I am just not aware of it’s name) the type that corresponds to the
«forward access iterator» (well, in case of QSet, that would be bidirectional
but not random access iterator) range.
If there’s no such v
On 2020-05-13 17:27, Matthew Woehlke wrote:
On 12/05/2020 12.59, Marc Mutz via Development wrote:
AsidE: If you think that CoW is still a thing today: no. SSO is a
thing these days, and it seems that QString will not have it in Qt 6,
either. NOI favours SSO, QString-everywhere cements the naïve
On 2020-05-14 02:15, Thiago Macieira wrote:
On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote:
std::span Project::productsSpan() const & { return
d->products; }
std::span Project::productsSpan() const && = delete;
Now implement either or both of these functions if interna
On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote:
> std::span Project::productsSpan() const & { return d->products; }
> std::span Project::productsSpan() const && = delete;
Now implement either or both of these functions if internally you have a
QSet.
--
Thiago Macieira -
On 13/05/2020 03.04, Lars Knoll wrote:
I don’t see a need to take a QStringView in those cases. With the
exception of some low level APIs, Qt’s APIs should be safe to use. An
overload taking a QStringView would either need to copy the data (in
which case we could just as well only offer the QStri
On 12/05/2020 12.59, Marc Mutz via Development wrote:
AsidE: If you think that CoW is still a thing today: no. SSO is a thing
these days, and it seems that QString will not have it in Qt 6, either.
NOI favours SSO, QString-everywhere cements the naïve CoW world of the
1990s for yet another deca
On 2020-05-13 09:56, Philippe wrote:
On Tue, 12 May 2020 18:59:35 +0200
Marc Mutz via Development wrote:
QString-everywhere cements the naïve CoW world of the
1990s for yet another decade.
CoW naive? Really not, this method is at the heart of many strategic
technologies.
eg.:
* virtual memo
On Wed, 13 May 2020 at 12:46, Marc Mutz via Development
wrote:
> In the not so hypothetical case that Qt is used to visualize results of
> some business calculations, chances are that thrid-party libraries will
> use std::string or std::u16string, and not QString, requiring the use of
> QString::f
On 2020-05-13 11:31, Marco Bubke wrote:
auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is
destroyed
AFAIK you can say that a rvalue should not return a reference by using
ref-qualified member functions.
View getView() const & { return v;}
Qt is so many years behind the mains
Nope, that would not be C++ if it wasn’t broken:
class C1
{
public:
std::string_view getMember() const & { return member; }
std::string member;
};
std::string_view m = C1().getMember(); // compiles!
You have to delete the method explicitly:
std::string_view getMember() const && = delete
On Wed, 13 May 2020 at 12:37, Marco Bubke wrote:
> auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed
> AFAIK you can say that a rvalue should not return a reference by using
> ref-qualified member functions.
> View getView() const & { return v;}
However,
whatever_fu
On 2020-05-13 09:04, Lars Knoll wrote:
On 12 May 2020, at 18:59, Marc Mutz wrote:
[...]
Most other classes:
* Only take and return QString
This is wrong. By taking a QString in the API of non-string-related
APIs, you expose QString as an implementation detail of the class.
Think QRegion, w
auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed
AFAIK you can say that a rvalue should not return a reference by using
ref-qualified member functions.
View getView() const & { return v;}
___
Development mailing list
Devel
Btw, I actually have an argument for returning a view=)
The ongoing c++20 ranges have exactly the same problem with the lifetime
issues. For instance, this won’t compile:
auto results = std::vector{1, 2, 3, 4, 5, 6}
| std::views::filter([](int n){ return n % 2 == 0; })
| std::views::tr
> 13 мая 2020 г., в 09:04, Lars Knoll написал(а):
>
> The above example is rather weirdly constructed.
>
> But anyhow, those data lifetime issues when using views as return values
> extensively are a lot less obvious to spot when a human reads the code. APIs
> should be safe to use wherever
On Tue, 12 May 2020 18:59:35 +0200
Marc Mutz via Development wrote:
> QString-everywhere cements the naïve CoW world of the
> 1990s for yet another decade.
CoW naive? Really not, this method is at the heart of many strategic
technologies.
eg.:
* virtual memory used by most of operating system
> On 12 May 2020, at 18:59, Marc Mutz wrote:
>
> Hi Lars,
>
> Let me pick important points one per email here:
>
> On 2020-05-12 09:49, Lars Knoll wrote:
> [...]
>> For String related classes:
>> * All methods not taking ownership of the passed arguments take a
>> QStringView
>
> Almost (see
Hi Lars,
Let me pick important points one per email here:
On 2020-05-12 09:49, Lars Knoll wrote:
[...]
For String related classes:
* All methods not taking ownership of the passed arguments take a
QStringView
Almost (see below).
* If the method stores a pointer to the passed data it should
26 matches
Mail list logo
