On Thu, Nov 27, 2014 at 12:00 PM, Edward Diener
On 11/27/2014 6:07 AM, Beman Dawes wrote:
We already have an "algorithm" directory, so it might make sense to add a
"sort" sub-directory and category with "spreadsort" as the first specific sort to be added.
Do you mean a directory structure of:
boost libs algorithm sort spreadsort ... possible other sorts
?
Yes, exactly. So sort is at the same level as "string" in the current libs/algorithm hierarchy.
Does this work with modular boost, submodules, and the Boost Build system ?
Sure. See the current boost-root/libs/algorithm. For an example where the components live in separate sub-modules, see boost-root/libs/numeric/conversion. My intuition is that "sort" should be the sub-module rather than having a separate sub-module for each kind of sort, but I'd like to hear from others before that is cast in concrete.
Hasn't there been lots of discussions of the difficulty of having libraries other than directly under boost/libs ?
There were some teething problems, but haven't those all been resolved?
If this is now workable and been resolved, both via Git submodules and Boost Build, I would agree with your suggestion but is there clear online documentation in the modular boost wiki for setting this up ?
The release managers handle the .gitmodules and other top-level setup. AFAIK, the submodule itself is setup like any submodule.
The reason I suggested that 'sort' just change to 'spreadsort' was to avoid the above problems,
That seems best anyhow since there will certainly be additional kinds of sorts added in the future.
but maybe those problems are now completely resolved and I just have not kept up with the discussion. Also Steven Ross will want to integrate 'spreadsort' into the modular boost directory structure and since this is his first contribution to Boost we need to make it understandable to him how to do this.
Yes. One question is "who is the maintainer for the overall sort library?" It would be nice if someone was looking at the big picture, so that there was some consistency between individual sorts for docs, testing, etc. There might be some overall docs, too, to help users choose between algorithms without having to read about each sort algorithm separately. Steven, are you interested in that role?
For adding sorts that are just implementations of classic and well-studied sort algorithms, we need a lighter-weight mechanism than a full formal review, IMO.
I agree. I just wanted to make sure we don't add a sort algorithm without any type of review just because it sounds helpful, should work, and we already have a sort library.
Right. The overall sort library maintainer could help manage issues like that. --Beman