H,
One hand raised.
The original use case is buried in the Qt history, when I was asking /
digging why we had that, I found that in some really rare and obscure cases it
may be useful. For example when you want to control the life time of a data in
your container. Imagine QVector::fromRawData which doesn't copy the data but
just update d, the internal header:
char t* = strdup(...);
{
QVector<char> tmp = QVector<char>::fromRawData(t);
tmp.setSharable(false);
Qt.Api.call(tmp);
}
free(t);
In my opinion we can safely deprecate it.
Cheers,
Jędrek
________________________________________
Od: development-bounces+jedrzej.nowacki=digia....@qt-project.org
[development-bounces+jedrzej.nowacki=digia....@qt-project.org] w imieniu Thiago
Macieira [thiago.macie...@intel.com]
Wysłano: 20 lutego 2014 08:32
Do: development@qt-project.org
Temat: [Development] RFC: Deprecating setSharable / isSharable in our
containers and QString
... and removing them in Qt 6
Please raise your hand if you knew we had that feature.
Please raise your hand if you've ever used them in your own code.
I doubt anyone has raised their hands to the second question and there mustn't
be more than 2 people who did for the first question. This is a very obscure
feature in our containers, which are normally implicitly shared: they can be
made unsharable.
However, this is not a performance optimisation. All non-const calls will
still check the reference count to see if they need to detach or not. Though
you may be sure that the calls will not throw exceptions, those functions are
still noexcept(false). So code generation is still bad.
And most importantly, we're paying the price for this obscure feature in EVERY
SINGLE ref or deref of any container using QArrayData or QRefCounter. That's
one extra comparison in each of those, plus the generation of the copy code
for the ref-up.
I'd like to remove the feature in Qt 6. Opinions?
Where it's used in Qt 5 (aside from tests):
src/corelib/tools/qiterator.h: { c->setSharable(false); i = c->begin(); n =
c->end(); } \
src/corelib/tools/qiterator.h: { c->setSharable(true); } \
src/corelib/tools/qiterator.h: { c->setSharable(true); c = &container; c-
>setSharable(false); \
src/corelib/tools/qiterator.h: { c->setSharable(false); i = c->begin(); n =
c->end(); } \
src/corelib/tools/qiterator.h: { c->setSharable(true); } \
src/corelib/tools/qiterator.h: { c->setSharable(true); c = &container; c-
>setSharable(false); i = c->begin(); n = c->end(); return *this; } \
src/corelib/tools/qset.h: { c->setSharable(false); i = c->begin(); n = c-
>end(); }
src/corelib/tools/qset.h: { c->setSharable(true); }
src/corelib/tools/qset.h: { c->setSharable(true); c = &container; c-
>setSharable(false);
Read: Java-style mutable iterators. And the above is slightly broken, because
you can always just create a second mutable iterator on the same container,
which would set it back to sharable when the iterator got destroyed. It also
doesn't stop the iterator from getting invalidated if you modify the container
outside the iterator.
STL-style iterators currently have the requirement that you should not create
a copy of the container while iterating for mutation. And even then, I can't
see right now an operation in the Java-style mutable iterators that would
break by removing those setSharable() calls, not after the fixes to insert()
we've done.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
