On 27 Nov 2014 at 16:26, Gottlob Frege wrote:
And, the reverse question (which Niall is asking), how much of Boost has moved to C++11 or greater, even if a large(?) percentage of the community hasn't.
If you would replace that choice of wording with "how much of _new boost development_ has moved to C++11 or greater ..." then I am in complete agreement.
And if so, what does that say about Boost and/or C++ adoption. ie is Boost pushing the adoption of C++11? Would boost push C++11 better if its libraries were backwards compatible (so as to "ease" people into C++11) or should a library abandon old C++ and "force" users to move forward?
If I was to write a new library, that _could_ be old-C++ compatible, but with extra work, should I put in that extra work?
I think there are interesting questions here for Boost and C++. Not sure if Niall is heading towards those questions or others.
I'm not sure if I'm heading towards those questions either, mainly because I don't think myself competent to judge right now. Currently right now I am intending to simply do a review and report of libraries close to ready for community review at C++ Now 2015. If during the preparation for that presentation I feel there is a bigger picture there I probably would pivot, but I am currently thinking that such synthetic analysis is better done in 2016 after a bit more reflection.
The further question, which I think should be discussed here or at BoostCon/C++Now, is what is Boost's role *today*? Is boost still a stepping stone to the standard? (I find that with the standard's new pace, and with its push to use TS's, "stepping stone" is now a more minor role for boost. For better or worse - ie I'm not sure if it is good for the standard.) Or is boost now a place for good libraries, most of which aren't general enough to be in std, but are really good and really useful when you need them? Or is boost a maintenance effort for old libraries for older compilers. (I don't think Boost is just that, but is it part of its role?)
I'm of the opinion, much to the annoyance of some on the committee, that the current transference of new library forms to std::experimental under the aegis of WG21 is unsustainable and inevitably doomed to fail. I think it will yield huge gains initially, but cannot work well over time simply because library design by committee very rarely works well in the long run. In my opinion, the correct and proper way of doing new standard library design is through attracting and retaining a substantial user base in a competitive market place of libraries. That is what made Boost popular and unique in the first place - it offered tools which other libraries, including the STL, aspired to. My current employment has me work regularly with ASIO and the ASIO way of thinking about concurrency as epitomised by N4045. I find much disagreeable about that whole way of thinking about concurrent design, but I would never claim it isn't battle hardened and proven good. As much as how ASIO does things is ugly, it is very effective and not far from ideal efficiency when designed around its assumptions [1]. This does present me a quandry though. If I had to vote on something like N4045 entering the standard my gut says vote no because I think we can do a lot better. But don't get me wrong, N4045 is currently the only game in town remotely approaching standards quality readiness through actual empirical practice rather than ivory tower top down deesign [1]. And if I were on the committee, I'd probably end up voting yes precisely because it is the only game in town. Niall [1]: ASIO's design is "zero copy to the kernel" rather than "zero copy to the NIC DMA engine" where the overwhelming problem child is Linux, as OS X and FreeBSD and Windows "do the right thing" with zero copy DMA if ASIO is properly prodded with 4k aligned no-COW scatter-gather buffers. Much of why Linux is that problem child is due to Linus personally himself, but we'll skip that for now (search google if you want to know more). Suffice it to say that Linux provides proprietary syscalls, and ASIO does not use them, but it probably wouldn't require too much effort to construct a framework where ASIO /could/ invoke proprietary Linux syscalls if certain additional restrictions were placed on ASIO using code. I may have some facilities regarding this in proposed Boost.KernelAlloc, but if benchmarking doesn't show enormous performance benefits I am inclined to consign Linux to second tier support status to be honest, I don't see the payback for the maintenance overhead for a special code path just for Linux alone here. -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/