On Monday, 15 July 2019 09:41:24 PDT Matthew Woehlke wrote:
> Note also that I suggested having the template definition out-of-line;
> it doesn't need to be in (e.g.) qstring.h or anywhere that will affect
> *user* compile times. Only the TU responsible for instantiating them
> would be affected,
On 14/07/2019 02.28, Mutz, Marc via Development wrote:
> If you're still not convinced, here's QStringView::endsWith() as a
> template:
>
> template
> requires std::is_convertible_v Qtf8StringView, || ... QLatin1StringView ...
> Q_ALWAYS_INLINE
> bool endsWith(Prefix ) const {
>
On 13/07/2019 21:39, Volker Hilsheimer wrote:
With an (ideally) single template-based API we don’t have peopleusing Qt get
lost in the jungle for overloads and string classes. For the implementation, we
can specialise the templates to call the suitable internal functions that
implement the
On 13/07/2019 15.39, Volker Hilsheimer wrote:
> As I understood the template suggestion, it’s more about not having
> to add 64 different overloads (or several more string classes) to
> the Qt API, and less about unifying all implementations into a single
> set of algorithms.
Right. At some
On Thursday, 11 July 2019 17:27:29 CEST Paul Wicking wrote:
> I’d like to nominate Kavindra Palaraja as approver.
+1
- Paul
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
