Good question!
Personally, I think that both should accept u"foo" as input. However, the
following code does not compile:
QString s(u"foo");
I have no idea if this is intentional or not and if there will be problems with
QString/QStringView overloads.
However, since the overloads are going to be revisited anyway, maybe it is
possible to remove some QString overloads
In favor of the QStirngView ones and thus allow accepting unicode literal in
QString as well.
I don’t think that accepting char* should be the desired use-case. Yes, it
works in the first case because QT_NO_CAST_FROM_ASCII
is disabled by default, but I don’t think we should encourage that use-case -
if the unicode literal is working for both cases, that should become
the «right way» to go.
So the question is - is it possible to allow to construct QString from unicode
literal?
Ivan
> 12 мая 2020 г., в 16:12, Giuseppe D'Angelo via Development
> <development@qt-project.org> написал(а):
>
> On 5/12/20 12:20 PM, Иван Комиссаров wrote:
>>> * Exceptions can be done where significant performance gains can be
>>> demonstrated and the API will by design not require a copy of the data
>>> (e.g. XML writer, stream writers, date time handling)
>> Let me disagree here. The decision should be taken on the fact if the object
>> takes ownership of the string (and thus QString is used) or it only «looks»
>> into it.
>
> I agree. This however leaves us with questions regarding the API. E.g.:
>
> class Attribute {
> public:
> // OK: takes ownership
> void addAttribute(const QString &key, const QString &value);
>
> // does not take ownership
> bool hasAttribute(QStringView key) const;
> };
>
> Is it OK that you can call addAttribute("foo", "bar") but not
> hasAttribute("foo")? (And similar)
>
> Thanks,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> _______________________________________________
> 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
