On Wednesday 14 October 2015 15:59:21 Matthew Woehlke wrote: > On 2015-10-14 07:15, Knoll Lars wrote: > > In addition, it might be tricky to use QStringView in signals and > > slots. > > As I previously stated, I'm pretty sure you *CAN'T* use QStringView to > call slots, except for direct call. In any other case, you risk the > backing data being modified or, worse, deallocated, before the slot > dispatches (this is *especially* dangerous with cross-thread dispatch, > since now you have thread safety to worry about). The only way around > that would be for QStringView to take a COW reference to the underlying > data. > > We already have a class like that. It's called QString. > > What *might* work is if the event dispatcher, when it makes copies of > the arguments, makes a deep copy of QStringView into a QString. I'm not > sure if this is possible, though, and anyway then you're in the same > boat of making a (potentially) unnecessary deep copy if you had a > QString in the first place.
This is nothing new. You cannot pass reference types through cross-thread signal/slot connections. In fact, you cannot pass any non-reentrant type, either. That doesn't prevent API such as QPrintPreviewDialog::paintRequested() from cropping up, and still being useful. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
