We can't use use takeLast on a const QList. cend() is meant to be used as a default when no URLs are given.

That's why you should declare it non-const and clear the list in postLaunch as you process the urls. m_startUrls is no longer used after startup.

BrowserWindow *window

Same here, no move semantics.

BrowserWindow *window

range-for would be faster than modifying m_startUrls at each iteration.

If you use range-for, remember to qAsConst(m_startUrls)

const QString &url

That contradicts what @drosca said:
https://phabricator.kde.org/D27655?id=76386#inline-157609

A single takeFirst()/takeLast() is ok, but a loop over takeFirst() or takeLast() is *really* suboptimal.

My suggestion was a single take, and then a C++11 range-for.

I can't since I need to use QString &url as @dfaure wanted. Thus it can't be const.

This will invoke a copy of the list, which is what I'm trying to avoid.

I hadn't realized that this code actually modified url (hence the const in my suggestion).

Modifying the args list is a bit of an unexpected side effect.

I think for (QString url : args) would indeed be better then, or the more traditional for (const QString &arg : args) { QString url = arg; ..... } so that it doesn't look like someone simply forgot a const &...

Note that copying QList is just increasing/decreasing a refcount, this isn't a full copy like what would happen with std::list or std::vector.

The traditional Qt way is to pass a const & in those methods, and copy into a member variable at the end of the chain where you end up in a constructor. Cheap copy.

The possibly more modern way is indeed pass by value and std::move, but only for constructors; don't do this for setters.

This code is maintained by drosca though, so if he doesn't like std::move, use const & everywhere.