Op 01/02/2016 om 15:16 schreef Marc Mutz:
On Monday 01 February 2016 10:18:25 Jędrzej Nowacki wrote:
So it would look like that:
fields.erase(std::remove_if(fields.begin(),
fields.end(),
[&name](const QPair<QByteArray, QByteArray>
&header)
{
return qstricmp(name.constData(),
header.first) == 0;
}),
fields.end());
// I hope that formating is still ok, and the code is not wrapped.
I am a great fanboy of algorithms and the STL, as should be clear by now :)
But I find the inlined lambda worse than an explicit loop. This is write-only
code, imo. Esp. since we can't (yet) use auto in the parameter list, but even
then, I'd always give a lambda a name (cf. my mail in response to Christian).
While I applaud the naming of things, especiallly things non-trivial, I
don't agree that an inlined lambda equates to write-only code. It can
be, but doesn't need to be. The lambda-to-return a lambda looks more
write-only than an inlined lambda does, IMHO.
While self-documenting code is great, I don't think it should come at
the price of outlandish constructs like lambdas-returning-lambdas. It
cleans up the code at the place you call the code, I give you that, but
it makes the lambda definition itself too complicated. I prefer a
comment if you think that documenting what is captured at the call site
is needed.
auto firstEqualsName = [&name](const QPair<QByteArray, QByteArray> &header)
{
return qstricmp(name.constData(), header.first) == 0;
};
fields.erase(std::remove_if(fields.begin(), fields.end(),
firstEqualsName /*captures &name*/),
fields.end());
Though for this particular construct, I certainly prefer a special
function. The erase + remove_if, both using the same end iterator always
annoys me. So something like:
removeWhereFirstEquals(container c, const QByteArray& name);
André
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development