[Development] Views

[Иван Комиссаров]

C++ standart is a software and like any software, it has bugs.
It’s good that «auto_ptr» bug was fixed among with auto a {42};

However, reading the dev list it seems that people claim that *everything* that is done by the Committee is a bug and there’s only the «Qt way» of doing things like it was back in Qt4 days.

If Qt wants to stay alive, it should adopt to the changes in C++ where reasonable. Sorry, I can’t buy an argument «we should always return a copy of a container because someday somewhere in KDE was a bug and the copy helped to solve it». Why we should force the way of doing things for the 1% case? Maybe we should force the way suitable for 99% cases and solve that 1% case in the other way? Like add a new function foo2 with new signature?

> 20 мая 2019 г., в 22:10, André Pönitz <apoenitz at t-online.de> написал(а):
> 
> At some time The Commitee decided to standardize auto_ptr, but not 
> {shared,unique,...}_ptr. People calling auto_ptr unusable for most
> practical purposed were chastised for not seeing the light. A while
> later The Committee changed their opinion...
> 
> Andre'
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development

What’s wrong with

qFind(foo(), x);

? I actually have a strong feeling that Ranges will solve that problem too adding something like std::find(Range, T value);

Having std::begin(), std::visit() and std::get() it doesn’t seem that bad idea to have a free functions for *everything*

If someone don’t like the std::vector::empty() method, he can use qIsEmpty(T) function.

Problem solved?

> 20 мая 2019 г., в 22:18, André Pönitz <apoenitz at t-online.de> написал(а):
> 
> 
> Exhibit A:
> 
>     foo().contains(x)
> 
> 
> Exhibit B:
> 
>     {
>         ... container = foo();
>         std::find(container.begin(), container.end(), x) != container.end();
>     }
> 
> 
> Andre'
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development