Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-14 07:35:58

On 14 Aug 2014 at 9:37, Andrzej Krzemienski wrote:

> > This could change in a month - and it will if I have anything to say
> > about it.  There is absolutely no advantage to not doing this.
> >
> 
> There appears to be a number of things where Robert and Niall would agree:

I think myself and Robert are maybe even 90% in fundamental 
agreement. It's funny actually, because we both started off quite far 
away from one another in opinion and he has changed his opinion to 
become closer to mine in many areas, and I thank him for that. I 
can't say how much I've changed my opinion to more closely match his 
as it's hard to see yourself from the outside, but I will say this: 
despite that I don't think his Incubator stands a chance because the 
Boost culture is the true problem so he's trying to substitute 
technological fixes for cultural problems, I am absolutely happy to 
support his effort there and I truly hope I am wrong and he is right 
on that (I might add that AFIO was one of the very first libraries - 
the second? - to be added to the Incubator).

No, where I am fundamentally coming from is asking the question "why 
do engineers like Dave Abrahams leave Boost?" Of course only Dave 
knows that, and it's his business anyway so you should ignore the 
named personalisation, but I find it an extremely useful abstract 
thought exercise about the wider cultural malaise and what's gone 
wrong. And, for the record, Dave leaving did harden my attitudes 
significantly. I suspect the same is true for Robert.

> 1. A library with templates in the interface should _document_ the
> requirements: in html or similar documentation

We're definitely in strong agreement that documentation needs to be 
better. There is some significant variance in what better means.

> 2. Unless there are reasons to do otherwise, such library should attempt to
> issue a diagnostic message during compilation that the requirements on
> types have not been satisfied. This doesn't need to be Boost.ConceptCheck
> (if no consensus can be reached on using it). Probably a static assert with
> a type trait should be enough:
> 
> template<class T>
> quick_sort(iterator<T> begin, iterator<T> end)
> {
>   static_assert(is_less_than_comparable<T>::value, "T is not
> LessThanComparable");
>   static_assert(is_swappable<T>::value, "T is not Swappable");
>   // do the work
> }
> 
> Not an ideal, but perhaps less controversial.

The above is what I do in my own code - indeed, just last night I 
wrote this for my concurrent_unordered_map:

  /*! \brief Factory function for many node_ptr_types, optionally 
using an array of preexisting
  memory allocations which must be deallocatable by this container's 
allocator.
  */
  template<class InputIterator> std::vector<node_ptr_type> 
node_ptrs(InputIterator start, InputIterator finish, value_type 
**to_use=nullptr)
  {
    static_assert(std::is_same<typename std::decay<typename 
InputIterator::value_type, value_type>::value>::type, "InputIterator 
type is not my value_type");
    std::vector<node_ptr_type> ret;
    size_type len=std::distance(start, finish);
    ret.reserve(len);
    for(; start!=finish; ++start, to_use ? ++to_use : to_use)
    {
      if(to_use)
      {
        ret.push_back(node_ptr_type(_allocator));
        _allocator.construct(to_use, std::forward<typename 
InputIterator::value_type>(*start));
        ret.back().p=to_use;
      }
      else
        ret.push_back(node_ptr_type(_allocator, std::forward<typename 
InputIterator::value_type>(*start)));
    }
    return ret;
  }

BTW I haven't even attempted to compile the above yet, so there are 
probably typos and besides the vector reserve should only be done for 
trivial iterators. This is part of my extensions to the N3645 
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3645.pdf) 
extensions to mapping STL containers which I got greenlit by Howard 
Hinnant and Jonathan Wakely - the new node_ptrs() factory function 
lets you manufacture many nodeptrs at once using a burst/batch 
allocator which can reduce your amortised memory allocation costs 
*very* significantly.

Anyway, if I feel that bad template parameters would generate 
unhelpful error messages, I'll usually throw in some sort of 
clarifying static_assert like the above. I view these as very similar 
to C-style asserts - there to be useful during development, not as 
parameter constraints.

In practice in writing actual code, I suspect the code output varies 
little between me and Robert. It is odd how profound philosophical 
disagreement can have such little real effect on code written - 
someone should really write a book on that topic actually.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/