On 4/3/2015 4:15 PM, Robert Ramey wrote:
Eric Niebler-4 wrote
Eric Niebler-4? What happened to the first 3 Eric Nieblers?
Speaking strictly for myself here: the reason I haven't pushed to get my recent open source contributions into Boost is not because I consider my code of higher quality. If anything it's quite the opposite. Getting a library into Boost is so daunting and time-consuming that -- at least for the work I'm doing these days -- I just don't have the time.
My view is that if developing for Boost is taking extra time, you're doing it wrong.
I don't have the time to produce Boost-quality documentation.
If producing Boost quality documentation is taking extra time, you're doing it wrong.
I'm not being facetious here. I think that one can't really verify that his library is correctly conceived and design until he tries to document it.
I completely agree. And I have been documenting it. I have on my machine a 170 page proposal that I intend to submit for the next committee meeting. It exhaustively documents a not insignificant fraction of range-v3. It represents about 6 months of work. Trouble is, it is about as usable as documentation as any other part of the C++ standard. Which is to say: not at all. Writing Boost documentation would be a whole other 6 months. You see choice I had to make.
In our world that means as clearly specified set of type requirements along with any other pre-conditions. The problem is that if you leave this until you're done, you discover that you've wasted a huge amount of time developing something that you don't really use - or could have been simpler.
and to exhaustively test everything.
If you're not writing the test as soon as you write a component how do you debug it? - or if your code doesn't need debugging (because its Eric Niebler I'm addressing here) How is anyone else sure it doesn't need debugging? You can't really progress without a test.
I was selling range-v3 short. It *does* have fairly extensive tests. I was able to crib much of them from libc++. <snip>
Concepts are coming.
dream on. The current versions looks to be captured in the "concepts lite" paper which is quite ill-conceived in my view. I have a huge problem with what I presume to be the canonical example they've chose "sortable".
The "canonical example" they chose is the STL. See here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf Despite what you think, concepts are real and they're coming. If you dislike the Concepts Lite approach, you're not alone, but that's what we're getting. It's certainly not all that C++0x concepts were, but there's some good things about that, and having built a non-trivial concepts-based library (range-v3 uses a Concepts Lite emulation layer), it's really not bad. Range-v3 would be impossible without something like concepts, and real language support will help immensely, IMO.
I talked about that at CPPCon. But besides that, we've had a simpler and "good enough" implementation of type requirements checking in the Boost Concept Checking library for over ten years - and hardly anyone uses it.
Maybe that's because it has usability problems, and doesn't actually solve the problems concepts are intended to solve. You can't do concepts-based overloading with Boost.Concepts, for instance. Boost.Concepts gives only hard errors.
A more elaborate version of something that isn't used is going to be used even less - not likely a success in my book.
<shrug> Predicting is hard, especially about the future.
But then we never take any kind of poll about which features/libraries are actually used by C++ programmers. So we don't really have any idea what's really successful. This is perhaps a good thing.
[end detour]
I needed to get on the Concepts train, and it was going to pull out of the station with or without me.
LOL - no way - it's guys like who are actually driving the train!
The Concepts TS happened completely without me. Concepts TS 2 -- the concept-infication of the STL -- was already being talked about. If it seems like I'm driving the train now, it's only because I talked a good game. :-)
It would take half a year to make range-v3 Boost-worthy. By that time, I'd have missed my chance to get ranges baked in from day 1.
at the risk of repeating myself, you won't save any time by trying to shortcut the process.
I won't repeat myself.
Maybe that speaks to Boost's review process,
Factor the Boost review process out of the discussion. Make a boost quality library and let the Review process take care of itself.
The main motivation for getting a library reviewed and accepted by boost is to get a certification of one's competence and accomplishment. You don't need any more of this from Boost. It wouldn't hurt, but you don't need it like the rest of us.
Thank you.
but it doesn't speak to the quality of Boost's code, which I consider very high.
It's variable. Considering the whole library - not just the code - In many case it needs to be higher - a lot higher.
There's parts of Boost *I* would design differently. But that's not a quality judgement.
I realize that doing an end-run around Boost to get ranges in the standard is deflating for everybody who has worked to make Boost what it is. That includes me.
I understand why people would look at it this way. And I think they're drawing on the wrong lesson. By skipping the Boost Review process, you're making a rational decision under the circumstances. It's a sign that boost has to evolve to stay current and relevant. How it has to evolve is something under active discussion. To me it's not deflating - it's inspiring!
FWIW, if someone were to volunteer to polish the docs and tests and run it through a review, I'd be overjoyed to see range-v3 in Boost. Ditto for Meta.
well finish them off and submit them to the incubator. Meta in particular would be interesting for a few reasons a) looks like you have it mostly done
Few docs. Few tests. The only reason it exists as a thing at all is because Gonzalo factored it out of range-v3 and made a repo for it.
b) it's small interesting component of current interest - C++11+ and MPL replacement discussion c) it would let you demonstrate/test and lend credibility to the incubator d) it's the most likely way you might get someone to take over this part of the project - see free outsourcing above. e) Under "suggestions for libraries" there are two suggestions. Seems that Meta would fit in typlists - which I would prefer as library name as it dovetails better with A's book(s). I would like a separate smaller library for metafunctions - but I'm not sure if you've got that factored out or not.
Meta is both typelists and metafunctions[^1]. They were separate, but that didn't buy anything so I put them together. I agree that Meta would be a good thing to throw up on the incubator, and even to run through the Boost review process. It's a slightly different approach to metaprogramming, and I would need the feedback and usage before I could take it to the committee. (Range-v3 was different since it's similar in principle to Boost.Range.) Unfortunately range has eaten up all my time and probably will for a while. [^1]: Meta doesn't have metafunctions per se. In Meta they're template aliases and alias classes. -- Eric Niebler Boost.org http://www.boost.org