Boost logo

Boost :

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
  template<class InputIterator> std::vector<node_ptr_type>
node_ptrs(InputIterator start, InputIterator finish, value_type
    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);
    for(; start!=finish; ++start, to_use ? ++to_use : to_use)
        _allocator.construct(to_use, std::forward<typename
        ret.push_back(node_ptr_type(_allocator, std::forward<typename
    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
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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at