[Development] Question about QCoreApplicationData::*_libpaths

[Thiago Macieira]

On Tuesday 19 January 2016 23:43:40 Marc Mutz wrote:
> > > - equal_range on hashed containers
> > 
> > No idea what that is.
> 
> http://en.cppreference.com/w/cpp/container/unordered_map/equal_range
> 
> It's the correct way to find all values matching a given key (as opposed to
> QHash::values(const Key &), which forces a QList down your throat).

Thanks.

> > > - range inserts, ctors, assignments
> > 
> > Already done for QVector for Qt6. However, since I wrote this on top of
> > QGenericArray, I can't push it to Qt 5.
> 
> I don't understand this. It can clearly be implemented in Qt 5, so what
> you're saying is that you implemented it in a Qt 5-incompatible fashion and
> _won't_ (as opposed to "can't") backport?

I *won't* backport to QVector, therefore I can't push those features.

I implemented them in 2012. I've only been maintaining them alive for the last 
3.5 years.

> > > - exception safety guarantees
> > 
> > Done since Qt 5.0 by João, but missed the release deadline. It's
> > QGenericArray using QArrayDataPointer and QArrayDataOps.
> > 
> > Also, we changed our policy towards exception-safety since 5.0 and this
> > work is no longer needed.
> 
> Sending your user's needs to /dev/null is a very easy way to fix it, yes.

Well, the policy was agreed upon by the whole mailing list. We decided we 
don't care about exceptions, not even in containers.

> This is what I meant and what Lars called me polemic for. *Qt* doesn't need
> this → we don't care. But please, everyone, use our super-cool containers
> and not the shitty STL ones, because we use camelCase and they use
> underhanded_names.

Engineer's motto: use the right tool for the right job. If you need 
performance or to squeeze the last bit of performance, use the Standard 
Library containers. If you need to work quickly, the Qt containers are better.

> BTW: here and in the following, I'm not saying *you* should implement all
> this. I'm just picking on you because a) I know you can take it and b) it
> exemplifies very well what started this thread (back when this was still
> about std::optional and why QOptional would be a bad idea).

And note: I am against QOptional. I'd rather make people wait for the Standard 
Library, unless we really need something ourselves (like qAsConst).

> > > - move semantics on realloc / insertions
> > 
> > This is easy to implement in QArrayDataOps. However, due to CoW, we'd have
> > to duplicate the code paths depending on whether the refcount was 1 or
> > not. That's a runtime decision, so I don't think this is worth it.
> 
> Oh, CoW again...
> 
> Howard Hinnant has reported a 10x (or was it 100x?) slowdown on
> std::vector<std::string> reallocation, depending on whether the std::string
> move ctor was marked as noexcept (std::vector refuses to move during
> reallocations when the type isn't nothrow_move_constructible).
> 
> So, very much worth it, I think.

Not if the element type is CoW. Then the copies are cheap. Moreover, we have 
relocatable types, while the Standard Library doesn't yet.

> > > - emplace (with Q_COMPILER_UNIFORM_INIT ifdef)
> > 
> > Done in QGenericArray, but not really relevant since we don't support
> > move-
> > only types.
> 
> emplace is not about move-only types. move-only types can be appended with
> push_back(T&&). emplace is about constructing into the final place. Without
> any move or copy ctor called. As Alexandrescu put it: no work is less work
> than some work.

While true, the benefit is small.

> > > - not requiring op= / default ctor in QVector
> > 
> > Not interesting to me.
> 
> That wouldn't be a problem if it would be interesting to *anyone*. Again,
> development stopped half-way.
> 
> And this is a very annoying one. When porting from QList (which doesn't
> require default ctors), you end up adding an artificial default ctor to the
> payload type, which, surprisingly often, doesn't have one.

Actually, I misread the proposal. You're talking about the *default* 
constructor, which is actually something I agree on and should fix. I had read 
as the *copy* constructor (i.e., move-only types).

Note: if it's already fixed in QGenericArray, then my motivation to have a fix 
in Qt 5 drops considerably.

> > > - move-only payload types (hard with CoW)
> > 
> > Ditto.
> 
> Which means QVector will not be able to hold unique_ptrs or std::threads.
> Well done.

Right. It hasn't been able to hold QObjects since Qt 2 and not many people 
have complained.

> > > - atomic operations on QSharedPointer
> > 
> > Explain more, please.
> 
> You can CAS on a shared_ptr instance, as if it was a normal pointer:
> 
> http://en.cppreference.com/w/cpp/memory/shared_ptr/atomic

Interesting. Well, std::atomic<QSharedPointer<T>> should just work. If it 
doesn't, you get to blame your Standard Library.

I don't think we should extend our atomics to other types. Our classes are 
QAtomicInteger<T> and QAtomicPointer<T>.

> > > - alias ctors for QSharedPointer
> > 
> > Ditto.
> 
> http://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr
> 
> ctor #8

That's easy to implement.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center