On 13 May 2015 at 19:21, Hartmut Kaiser wrote:
3. Is there a common theme in choice of library design and use of third party libraries?
What would this information give you? Finding new 'design patterns'? This is the only question I'd support going after as it would help other library authors to take advantage from 'best practices' and 'lessons learnt'.
You mean https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook?
You connect this analysis of 'C++11/14 mandatory libraries' (a classification I find to be deeply troubling, btw) with 'rebooting Boost'. Is that intended or just a coincidence?
Two years ago I felt Boost should be rebooted for reasons. Now I know Boost is being rebooted by the new library authors. I had suspected it before, but now I know. I think it'll be a lot more obvious next year when the new authors have seen community review. In the end it doesn't matter what you or I or anyone else thinks what should be the case. What matters is the collective vote by those writing libraries: their design choices, their preferences, and their code. I'd like to think I persuaded everyone to adopt my arguments, but in truth I think it was always going that way no matter anything I said.
Regardless, my impression deepens, that all of this is an attempt to take over Boost for your own (commercial) interests and to force your own library onto everybody else. An attempt which I will not support.
Heh. I would just *love* to know what interests, especially commercial, those might be. The truth is this Hartmut: 1. I wanted AFIO standalone. The only Boost library I knew of capable of standalone is ASIO. ASIO achieves standalone though a fairly laborious macro based dependency injection method which either injects the STL11 or Boost into the asio namespace. 2. I didn't want all that brittle manually written machinery ASIO uses. I felt using C++ 11 and a bit of libclang AST programming I could largely automate it and save myself a ton of work. 3. As I implemented it, I realised the same mechanism could do version binding too. And that it would likely be extremely useful to any other Boost author wanting both standalone and Boost options and to let them evolve their library without worrying about dependency breakage as much. 4. APIBind is *ridiculously* simple. People seem to think it some big complex thing. All it is is a set of conventions for naming really. C++ 11 and programmer discipline takes care of the rest. Hence we are where we are. I don't claim APIBind is finished. I do claim it's good enough for my purposes, and with a bit of extra work it probably would be good enough for other people too. It's up to each library maintainer if they wish to use APIBind, or do as Chris did with ASIO and do it all by hand. Or ignore dependency injection, and use no Boost at all. Whatever happens, it is extremely clear to me a C++ 11/14 only Boost distro is coming simply through the authors in question continuing to support standalone modular use. Even if I were to vanish tomorrow. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/