Should this work?

[Atila Neves]

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