I agree that the code is fragile and it is not the best api ever, that is why I believe we could deprecate it.
I remember the idea of injecting allocator into containers, I do not remember why it died (was it memory expensive?). From api perspective it would be a better solution. 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 18:01 Do: development@qt-project.org Temat: Re: [Development] ODP: RFC: Deprecating setSharable / isSharable in our containers and QString Em qui 20 fev 2014, às 12:14:24, Nowacki Jedrzej escreveu: > 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. The problem with that is that it might cause extra memory allocations when something accidentally copies it in your called function. And you also wrote a nice example that calls a function, instead of trying to return it (which would trigger a deep copy). In any case, you may remember from the pre-5.0 discussion that I want to introduce an "external data" type of handler. So the above would be: char *t = strdup(...); QVector<char> tmp = QVector<char>::fromRawData(t, strlen(t), free); Qt.Api.call(tmp); When all copies go out of scope, QVector calls free(data()). -- 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