Edward Diener-3 wrote
Having worked for approximately 30 different companies in my career as largely a computer programming consultant I am well aware of many programming shops, even within major corporations, who have no clue about reusability of software.
There is absolutely nothing Boost can do for such places, because the general understanding of program creation is so low and in the hands of programming managers and their like who do not understand programming design in any way.
I have fought too many losing battles with companies for which I have consulted, trying to convince people whose programming talent is low, that using reusable libraries such as Boost will make it easier to accomplish their goals.
LOL - you're preaching to the choir here. But I don't think things are totally hopeless and I think Boost CAN improve the situation. I remember when STL became available. There was a lot of negative reaction due the to fact that it had a lot of unfamiliar concepts such as function objects, iterators, and others. But slowly it did get taken up. One reason for this success was the quality of design of STL (not perfect but as good as C++ permitted), and the quality of STL documents (SGI website, STL Reference, (Musser), and Scott Meyers Effective STL. To a small extent the same has happened with Boost and things will likely improve at least for those parts of Boost incorporated in the standard. Books like Boris Schaling's will also have a positive effect. In my view, the single most effective Boost could do is to raise the standards for documentation of Boost libraries and help library authors meet these standards. This is a primary focus of the Boost Library Incubator. There's one big problem however. There isn't a strong consensus on what high quality C++ library is. I've tried to make the case for my viewpoint in the incubator (Advice, Concepts) And I think this has helped some - but still there are lots of people who I haven't yet been able to sway to my point of view. This is a work in progress. TL;DR; For reference - I'll include a short summary of my views on this subject: a) All template parameters type requirements should be explicitly documented. b) The above preclude the usage of documentation tools - specifically DOxygen which cannot support the creation of documentation in accordance with a) above. c) All template parameters should be at compile time so that that the compiler will trap when a user attempts to use a type which does not meet the documented requirements. d) C++ does not currently support the above in the language itself. But this is no reason not to check the parameter types using Boost Concept Checking Library or other means. It's not a lot more complex than that - and would seem to me to be uncontroversial - but there has been a lot of resistance to this point of view. I'm still working on that. As an example, I will site the Boost Units library. Not that I'm not picking on this particular library, there are many examples in Boost, but this one is close to my heart. This is an incredible piece of work. Usage of this library would be hugely beneficial in many, many programs. But the documentation of this library makes it very, very hard to understand how to use it. A naive programmer cannot simple spend an hour looking over the documentation and get his own simple example working. He then moves on - for good reason. For Boost to continue forward - it has to appeal to the "rest of us". That means a) more libraries, b) of much higher quality, c) supporting more niches areas, d) which can be written by more people That is the motivation and purpose of the Boost Library Incubator. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Incubator-Status-Report-tp4668747p4... Sent from the Boost - Dev mailing list archive at Nabble.com.