[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