On 5/21/16 10:26 AM, Peter Dimov wrote:
Hartmut Kaiser wrote:
As said, I find the classification of a library as being 'C++14 only' to be completely useless.
Agreed - but maybe there is something interesting to consider. Let's call it "Boost-Lite" Boost-Lite would be subset of boost with minimal dependencies outside the standard library. So it would not include those parts of boost already incorporated inside the standard library: std::shared_ptr, etc. It would also not include boost component which which are superceeded by newer standard library features and components - no need for boost::type_of, etc. Basically, this is the way that new code is being written today. New code doesn't have to be backwards compatible becauses it's new. So Boost-Lite would be a subset of Boost. It would be all of boost with that part which is generally not necessary excluded. I realize that this is not what Naill has been proposing so it's effectively off topic. But bear with me a little. I see the appeal of Boost-Lite to those making new code (libraries and Applications) who want to keep dependencies and maintainence burden minimized. This Boost-Lite would be just a subset of Boost. A different distribution. Anyone could make it. If this is what is desired the way to go about it is to: a) Announce one's new project - Boost-Lite b) Announce a list of requirements for a library to be included in the Boost-Lite distribution. This would include the library subset I mentioned above. If the promoter wants, he could add his own favorite extra requirements - e.g. CMake (in a certain way) required. or whatever. c) Announce a list of libraries which full fill the requirements Boost-Lite specifies. Some of the newer libraries would like already qualify, Many of the older ones wouldn't and many of the older one's would be considered redundant so they wouldn't matter. d) Sit back and watch library authors to make changes or versions of their libraries which qualify to be added to Boost-Lite. If you're correct in your assessment, you'll be flood with new / updated libraries. This is serious practical proposal, you don't need to write any code, you could have started it years ago. Instead you're after us like it's our problem. Just get going and then see if how many people you can get on board. Actually, I see more application for this idea. I could easily envision someone conjuring up a special boost distribution called Boost-Embedded. This would have all he old stuff - because many embedded systems only have older compilers and can't compile C++11+ code. So maybe someone want's to distribute this. I see the ability to do things like this as potentially useful. Though I don't know if anyone things it's so important/useful to actually do some work on it. If not, of course it doesn't matter. But I would like to see us continue our slow progress on modularization. It's quite possible that C++ modules in a couple of years could have a big impact on this. Parties interested in this should participate on the relevant committees. Sorry for the long post - I'm just trying to salvage something constructive. Robert Ramey
In the context of the hypothetical C++14 only Boost 2.0, this means that the libraries have access to std::shared_ptr, std::thread and so on, which in turn means that they don't need to depend on boost::shared_ptr, boost::thread and so on. This makes it possible for a "Boost 2.0" library to be completely independent of the rest of "Boost 2.0", at least in theory. And if it's independent of the rest of the "Boost 2.0" libraries, why should it depend on, say, a common build system or a common test infrastructure? So outdated. It's $current_year!
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost