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/