I agree that std.algorithm is better than <algorithm>, but let's
not pretend that C++11 never happened (that happens from time to
time on this forum). The modern C++ version isn't _that_
different:
for(auto& blah: myContainer) { //for-loop condition on one
line
doSomething(blah->impl->myDataField);
if(find(blah->impl->mySubContainer.begin(),
blah->impl->mySubContainer.end(), key) ==
blah->impl->mySubContainer.end()) {
//decltype is way shorter than
std::vector<MyType<Blah>>
//and change-resistant
return decltype(blah)::iterator{};
}
}
Again, I think that std.algorithm is better and that passing a
pair of iterators to everything when 99.9% of the time they'll be
begin() and end() anyway is a massive PITA. I'm a D convert.
Nobody here makes a point of posting D1 code and IMHO there's
also no point in posting C++98 / C++2003 code.
Atila
// You can't even write the for-loop conditions in a single
// line!
for (std::vector<MyType<Blah> >::iterator it =
myContainer.start();
it != myContainer.end();
it++)
{
// What's with this (*smartPtr)->x nonsense everywhere?
doSomething((*((*it)->impl)->myDataField);
// What, I can't even write a simple X != Y if-condition
// in a single line?! Not to mention the silly
// redundancy of having to write out the entire chain of
// dereferences to exactly the same object twice.
if (find((*(*it)->impl)->mySubContainer, key) ==
(*(*it)->impl)->mySubContainer.end())
{
// How I long for D's .init!
std::vector<MyTypeBlah> >::iterator empty;
return empty;
}
}
OK, let's get one thing straight here. Comparing Phobos to STL
is truly
unfair. I spent almost 2 decades writing C++, and wrote code
both using
STL and without (from when STL didn't exist yet), and IME,
Phobos's
range algorithms are *orders* of magnitude better than STL in
terms of
usability. At least. In STL, you have to always manage pointer
pairs,
which become a massive pain when you need to pass multiple
pairs around
(very error-prone, transpose one argument, and you have a nice
segfault
or memory corruption bug). Then you have stupid verbose syntax
like:
// You can't even write the for-loop conditions in a single
// line!
for (std::vector<MyType<Blah> >::iterator it =
myContainer.start();
it != myContainer.end();
it++)
{
// What's with this (*smartPtr)->x nonsense everywhere?
doSomething((*((*it)->impl)->myDataField);
// What, I can't even write a simple X != Y if-condition
// in a single line?! Not to mention the silly
// redundancy of having to write out the entire chain of
// dereferences to exactly the same object twice.
if (find((*(*it)->impl)->mySubContainer, key) ==
(*(*it)->impl)->mySubContainer.end())
{
// How I long for D's .init!
std::vector<MyTypeBlah> >::iterator empty;
return empty;
}
}
Whereas in D:
foreach (item; myContainer) {
doSomething(item.impl.myDataField);
if (!item.mySubContainer.canFind(key))
return ElementType!MyContainer.init;
}
There's no comparison, I tell you. No comparison at all.
> > I actually feel a lot more productive in D than in C++ with
> > strings. Boost's string algorithms library helps fill the
> > gap
> > (and at least you only have one place to look for
> > documentation
> > when you are using it) but overall I prefer my experience
> > working
> > in D with pseudo-member chains.
>
> I found that what I got out of taking the time to learn
> std.algorithm and std.range was worth far more than the
> effort
> invested.
>
Perhaps you're right. But I think there's ***HUGE*** room for
improvement. The key in your sentence is, it shouldn't require
'effort'; if it's not intuitive to programmers with decades of
experience, then there are probably some fundamental design (or
documentation/accessibility) deficiencies that needs to be
prioritised. How is any junior programmer meant to take to D?
No offense, but IME, junior programmers tend to pick up these
things
much faster than experienced programmers with lots of baggage
from other
languages, precisely because they don't have all that baggage
to slow
them down. Old habits die hard, as they say.
That's not to say that the D docs don't need improvement, of
course. But
given all your objections about Phobos algorithms despite
having barely
*used* Phobos, I think the source of your difficulty lies more
in the
baggage than in the documentation. :)
T
