[Development] Question about QCoreApplicationData::*_libpaths

Marc Mutz marc.mutz at kdab.com
Tue Jan 19 18:50:15 CET 2016


On Tuesday 19 January 2016 17:07:12 Thiago Macieira wrote:
> On Tuesday 19 January 2016 10:07:43 Marc Mutz wrote:
> > > That doesn't mean types without CoW are immune from the problem. There
> > > are lots of discussion in the std mailing lists about constexpr data,
> > > so in the
> > > future a const std::string could potentially point to .rodata and thus
> > > be affected by this problem too.
> > 
> > But only _locally_. As soon as you copy the std::string, you're insulated
> > from that problem, unlike in CoW, where it can strike anywhere the string
> > happens to be copied to.
> 
> I am not sure. This is of course speculative since such code does not
> exist. But it's entirely possible that std::string's move constructor
> could propagate the reference to that .rodata.
> 
> std::string someString()
> {
> 	return constexpr_string("foo");
> }

It is speculative, but I don't think this example would propagate the 
reference, because you cannot move from a const object.

> std::string g_string;
> void f()
> {
> 	// move-construction
> 	static std::string s_string = someString();
> 
> 	// causes move-assignment operator to be called
> 	g_string = someString();
> }
> 
> Also, people using deep-copy types tend to keep references more often than
> people using cheap CoW types.

Yes. Or they form shared_ptrs to it. But then the syntax makes it glaringly 
obvious that a reference is manipulated (as opposed to a value).

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



More information about the Development mailing list