Ricky65

Notice how Andrei is using an Apple laptop. o_0

Hi Herb,

Congratulations on another greak talk.

I think it's great how std::begin() and std::end() unify containers and built-in arrays with a clean and simple syntax.

In addition, I think the commitee should include a global std::size() function. This would surely be preferable to the ugly ARRAYSIZE/countof macro hacks which are so commonplace. In his "Notes on Programming" Alexander Stepanov writes - "I made size into a member function in STL in an attempt to please the standard committee. I knew that begin, end and size should be global functions but was not willing to risk another fight with the committee." Thankfully the committee made begin and end global in C++11 but we are still waiting on global size.

I would also make std::front() and std::back() global too.

These additions would make life far easier for all programmers and shouldn't be too difficult to implement.

I would suggest that <utility> is probably the best place for the functions I've mentioned.

Kind regards

Riccardo Marcangelo

P.S

Perhaps even a global std::at() function to provide bounds checking for built-in arrays .

Example:

int myarr [] = {1, 2, 3, 4};

int a = myarr[4];

int b = std::at(myarr, 4);//error!

Thank you for replying to my questions, Herb.

I agree that range-for doesn't have much of an advantage over for_each in the presence of lambdas. However, I'm glad range-for was standardized. I agree that range-based STL algorithms and polymorphic lambdas make range-for almost redundant, but they are not standard at the moment. range-for has automatic type deduction today (if it were implemented). Also it is possible to break and continue with range-for which I can't do with for_each, even with range-based STL and polymorphic lambdas.

Personally, using std::for_each with a lambda in VS 2010 is sufficient for most of my needs. I have created my own for_each_n algorithm (I'd love to see something like it in the standard btw) for when I want to only do something with the first, say 10 elements in a range. I couldn't do that with range-for.

You mention that if range-based STL algorithms and polymorphic lambdas were added there would be "little incentive" to use range-for. I agree with you but I still think range-for will be popular as some programmers have the perception that built-in language facilities are superior to library alternatives.

Regarding non-copyable classes, although boost::noncopyable may be easier to use and teach I still feel it is only a partial solution. The problem being that using a base class with private copy constructor and assignment operators makes a class non-POD. I think boost::noncopyable using defaulted and deleted functions would combine the best of both.

Something like:

class noncopyable

{

public:

noncopyable() = default;

noncopyable(noncopyable const &) = delete;

noncopyable & operator=(noncopyable const &) = delete;

};

Thanks for this Herb, I really enjoyed it.

I have a few questions:

Why do you prefer std::for_each over range-based for? Is it because range-for isn't implemented in VS11 (it's not in the dev preview) or is std::for_each faster because of loop unrolling? Or another reason?

Instead of boost::noncopyable howcome C++11 defaulted and deleted functions weren't added. I know it would be slightly more verbose, two lines instead of one to disable copy, but I think they are superior. Lack of time?

P.S binary_search which returns a bool. that made me laugh. lol. Over the years, I wonder how many C++ programmers have rolled their own binary search which returns an iterator? Not the finest moment for the STL!