[Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Marc Mutz]

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.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts