On 5/13/2015 11:32 PM, Niall Douglas wrote:
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.
"Rebooted" meaning what ?
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.
Of course it matters, because 'we' are part of the "collective vote" of those developing libraries.
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.
I am actually laughing because you are so over the top in your assurance that everyone sees things in your own way, as if it were a fait accompli.
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.
Please document APIBind as fully as you can and I, and probably many others, will be happy to look at it and see what it is about.
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.
How about the choice of not wishing to have a standalone library and use whatever of Boost or anything else one wants ?
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.
Let it come then. I doubt that current Boost will go away. Boost currently consists of some 125+ libraries. Perhaps I am misinterpreting your attitude, but you seem to think that new C++ library developers have no use for any of those libraries and will find all they need to create their libraries in C++11/C++14 and its standard libraries. I do not find that to be true at all and I see nothing which supports those facts in libraries proposed for inclusion into Boost. I have nothing against those who want to create libraries that require C++11/C++14 implementations and still be part of Boost. If their design means that they do not need to depend on any current Boost libraries that's fine also. But to limit C++ library developers to only what is in the C++ standard library, and to place all of the usefulness of Boost libraries off limits to their development efforts, seems a foolishly willful effort for no gain at all and a great loss of potential functionality. I do not know if that is what you are proposing, or whether it is called Boost 2.0 or whatever. But if it is, it is not a goal of software development which I would ever pursue. I have already worked in enough programming jobs as a computer consultant where some boss, sometimes knowing next to nothing about software development, decides that useful software libraries should not be used. Inevitably inferior technologies are chosen which are written from scratch, wasting time, programming effort, leading to a poorer design, and a buggier product. Software dependencies are always a problem which must be solved by an intelligent system to deal with them. But they are far better than having to rewrite code which already exists, has been tested, and found useful, just become someone might fear that a dependency on some useful library will create unnamed and unimagined problems in the future.