Re: [Development] char8_t summary?
On 12/07/2019 16.05, Mutz, Marc via Development wrote: > On 2019-07-12 17:27, Matthew Woehlke wrote: >> On 11/07/2019 15.01, Thiago Macieira wrote: > [...] >>> Except that the whole point of those methods is that they can be more >>> efficient when the encoding is known and therefore templating won't >>> help. >> >> So those cases can employ specializations. Or, perhaps better, wrap the >> implementation bits where it matters in `if constexpr`. > > You should, maybe, take a look at qstring.cpp before you make such > uninformed statements. I was thinking in terms of what I would do if I was implementing things from scratch; not how I would refactor existing code. That said, I took a look at startsWith, and... surprise! It is *already a template*. So at least in that case, it isn't obvious why adding more combinations would be so terribly onerous. For that matter, making it a template (with explicit extern instantiations) would already be an improvement since it would cut down the several extant definitions into one definition and some declarations (which could even be enumerated by macro magic). So, perhaps you should suggest a more specific example? -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
On 2019-07-12 17:27, Matthew Woehlke wrote: On 11/07/2019 15.01, Thiago Macieira wrote: [...] Except that the whole point of those methods is that they can be more efficient when the encoding is known and therefore templating won't help. So those cases can employ specializations. Or, perhaps better, wrap the implementation bits where it matters in `if constexpr`. You should, maybe, take a look at qstring.cpp before you make such uninformed statements. When you do, keep in mind that these 12k5loc do not even contain direct (as in zerocopy) utf-8/l1 and utf-8/utf16 comparisons, yet. Optimizing those is what earns you a slot at CppCon. Well, not anymore, that ship has sailed. Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Evolving the Qt Project Security Policy
Hi Volker, A few comments - I wrote the original policy and I'm happy that you're taking the time to evolve it: > In addition, we have also been discussing a few aspects in The Qt Company > where we would like to see the policy evolve, such as: > > * the integration of CVE handling into the process of disclosing > vulnerabilities > At the time of writing, getting a CVE was difficult as a result of bottlenecks within the issuing process (see https://lwn.net/Articles/679315/ for background). These issues have now been resolved so I agree they should be assigned. It may also be worth considering including a CVSS score. > * the documentation of security-relevant software engineering processes > that The Qt Company operates today, such as external code audits or > fuzzing; evolving such processes should be part of the discussion > At the time of writing, these activities were not present. I'd be happy to look at details of them and discuss. If we're going to then there should also be some consideration made towards threat modelling and the development of a loosely formalised SDLC. > * reviewing the way the core security team is operating > Indeed. Cheers Rich > > > See https://bugreports.qt.io/browse/QTWEBSITE-860 for details. I’d be > very happy about all contributions. > > Note that for the moment, the scope of this continues to be Qt itself, > rather than surrounding infrastructure and processes. > > > Cheers, > Volker > > [1] https://wiki.qt.io/Qt_Project_Security_Policy > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
On 11/07/2019 15.01, Thiago Macieira wrote:
> On Thursday, 11 July 2019 13:41:49 -03 Matthew Woehlke wrote:
>> On 11/07/2019 05.05, Mutz, Marc via Development wrote:
>>> There is a cost associated with another string class, too, and it's
>>> combinatorial explosion. Even when we have all view types
>>> (QLatin1StringView, QUtf8StringView, QStringView), consider the overload
>>> set of QString::replace(), ignoring the (ptr, size) variants:
>>>
>>>{QL1V, QU8V, QSV, QChar} x {QL1V, QU8V, QSV, QChar}
>>>
>>> that's 16 overloads. And that's without a possible QUtf32StringView.
>>
>> So?
>>
>> The right way to handle this is for those methods to be templated, in
>> which case a) the code only needs to be written O(1) times, not O(N)
>> times, and b) users can potentially specialize for their own string
>> types as well.
>
> Except that the whole point of those methods is that they can be more
> efficient when the encoding is known and therefore templating won't help.
So those cases can employ specializations. Or, perhaps better, wrap the
implementation bits where it matters in `if constexpr`.
> Templating won't make overload resolution any faster, but will make
> compilation times slower.
For Qt, yes. This could be significantly (entirely?) mitigated with
explicit, external instantiations, such that only the one source in Qt
itself that compiles the instantiations is significantly affected.
> And if we want to make use of the fact that a string
> is UTF-8, the templates won't work.
Eh? char8_t is a detectable and distinct type. (Wasn't that the whole
point of this thread?) So is QUtf8String if such a thing were to come
into existence.
>> If done cleverly, even the (pointer, size) variants should be able to
>> wrap the arguments in a View, such that those method definitions are
>> trivial.
>
> View = (pointer,size) pair.
I meant that e.g. it would not be hard to make:
foo(CharType const* s, SizeType L)
...be a simple wrapper around:
foo(View::type s);
...which is itself either a template (per above), or several
non-template functions taking various types of views (status quo). No
combinatorial explosion of code per possible pointer type.
--
Matthew
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
On Thursday, 11 July 2019 13:41:49 -03 Matthew Woehlke wrote:
> On 11/07/2019 05.05, Mutz, Marc via Development wrote:
> > There is a cost associated with another string class, too, and it's
> > combinatorial explosion. Even when we have all view types
> > (QLatin1StringView, QUtf8StringView, QStringView), consider the overload
> > set of QString::replace(), ignoring the (ptr, size) variants:
> >
> >{QL1V, QU8V, QSV, QChar} x {QL1V, QU8V, QSV, QChar}
> >
> > that's 16 overloads. And that's without a possible QUtf32StringView.
>
> So?
>
> The right way to handle this is for those methods to be templated, in
> which case a) the code only needs to be written O(1) times, not O(N)
> times, and b) users can potentially specialize for their own string
> types as well.
Except that the whole point of those methods is that they can be more
efficient when the encoding is known and therefore templating won't help.
Templating won't make overload resolution any faster, but will make
compilation times slower. And if we want to make use of the fact that a string
is UTF-8, the templates won't work.
Right now, we know bytelength(latin1string) == codepointlength(utf16string),
so we know how to efficiently replace and we apply that knowledge to indexOf,
startsWith, endsWith, etc.. That's not the case for UTF-8, so algorithms will
begin to differ very quickly.
> If done cleverly, even the (pointer, size) variants should be able to
> wrap the arguments in a View, such that those method definitions are
> trivial.
View = (pointer,size) pair.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Evolving the Qt Project Security Policy
Volker Hilsheimer (22 May 2019 11:01) wrote: > the Qt Project Security Policy is currently documented as a wiki page > at [1]. Since QUIPs are the official way to document processes, I’m > proposing that we are moving the policy to a QUIP. That was reviewed as https://codereview.qt-project.org/c/meta/quips/+/262502 This has now become QUIP 15, https://quips-qt-io.herokuapp.com/quip-0015-Security-Policy.html Merged 2019-07-05. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Kavindra Palaraja for approvership
+1 Disclamer: We work for the same company ;-) Am 7/11/19 um 5:27 PM schrieb Paul Wicking: > > Hi all, > > > > I’d like to nominate Kavindra Palaraja as approver. She is a very > active contributor and reviewer, in particular for documentation > related changes, focusing on the Qt Automotive platform. She’s a > former employee of Trolltech and Nokia, and has a lot of experience > with Qt’s documentation. Currently, she is employed as tech writer for > Luxoft. > > > > If you're curious, here's a list of her changes: > > > > https://codereview.qt-project.org/q/owner:kpalaraja%2540luxoft.com > > > > and a list of changes she's on as a reviewer: > > > > https://codereview.qt-project.org/q/reviewer:kpalaraja%2540luxoft.com > > > > > > Best, > > Paul > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
> please, if it can be avoided, don't add yet another string-related class to > Qt. Knowing > when to properly use QString, QByteArray, QLatin1String, QStringLiteral, > QStringRef and > QStringView (I may have missed a few) is already a challenge. And I imagine > for people > new to Qt it can even be a strong deterrent (after all, strings are something > you tend > to use even in a simple Hello World - the first app most people see or write > in a new > language/ framework). I totally agree. Maybe this helps (I could not find such a document): https://bugreports.qt.io/browse/QTBUG-77020 -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
