Ricky65 Ricky65

Niner since 2011


  • Static If I Had a Hammer

    Notice how Andrei is using an Apple laptop. o_0

  • Day 2 Keynote - Herb Sutter: C++11, VC++11 and Beyond

    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


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


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

    int a = myarr[4];

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

  • Writing modern C++ code: how C++ has evolved over the years

    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



    noncopyable() = default;

    noncopyable(noncopyable const &) = delete;

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



  • Writing modern C++ code: how C++ has evolved over the years

    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!