Rob Stewart-6 wrote
b) The above preclude the usage of documentation tools - specifically DOxygen which cannot support the creation of documentation in accordance with a) above.
What's wrong with the tparam attribute?
I didn't know about this - I'll take a look at it. When I looked at DOxygen, I concluded that, though it might be possible, it wasn't easy to create a page describing a concept. Indeed, I've never seen DOxygen which included concept pages or description of template parameters. If you have information/experience with this, feel free to add that information to the page in the Incubator where I discuss my impressions of various documentation tools in the context of Boost quality library development.
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.
I assume you meant to write that template parameters should be checked at compile time, in which case I agree. Unfortunately, the tools we have for that are awkward presently. We're awaiting concepts.
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.
When possible, I agree. Unfortunately, the use of BCCL can change the characteristics of a type such as making an otherwise trivially copyable type non-trivially copyable.
This is news to me. Assuming this is true - it's easy to use static assert to get the same effect. My point is - Don't wait for language support - start using what we already have.
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
There is certainly room for the niche libraries you mention, since they won't be standardized.
I believe that the idea that the idea that every good library should be part of the standard is a bad idea. Basically it can't scale and is likely reached the end of the road. We've already made C++ so large (by requiring libraries) that we're down to 3 suppliers of C++ compilers. I don't see hope for new entrants - which we used to have. Coupling the language to libraries has a huge downside. Admittedly, accepting Boost libraries into the standard has been a huge boon to Boost. But let's not get too stuck on that. Use our credibility and imprimatur to fix the real problem - a world inundated with crappy, fragile, opaque software that is so bad people keep more of it.
To your point of libraries "for the rest of us", one way that Boost causes itself problems is by our dissatisfaction with simpler designs. We're enamored with more esoteric designs. The imposition of templates when polymorphism would suffice, even if suboptimal, turns off many, the STL notwithstanding. Perhaps we need to encourage both kinds of libraries.
I absolutely agree. I want to take this head on. a) encourage better documents. I believe that one reason we have over elaborate designs which lose sight of the ultimate purpose is that we don't insist on readable documents and clearly define, orthogonal, de-coupled concepts (not the C++ concepts - but in the real sense of "concept). b) we need to upgrade our deployment to permit subsets so that components can be dropped without a huge trauma. c) we need to permit the creation of better components which might compete with existing ones. We need to look more like silicon valley rather than downtown detroit.
The other difficulty is that many companies are pleased to use high quality, free libraries, like those from Boost,
Everyone likes free stuff
but are reluctant to permit sharing those created in-house.
Often because they don't want the world to see how crappy their code is. I've done work or a fair number of companies, and I never seen any code which would meet the admittedly low bar of the Boost Inclubator - much less for Boost itself. That's why most of are here - because it's a place where doing a good job is actually appreciated.
The result is that many potential additions to Boost and, ultimately, the Standard are excluded.
And I hope the incubator will be a place which can promote and enforce software quality even for C++ software which for one reason or another isn't not headed for the standard. There is lots of stuff that is really good - but wouldn't really fit in the standard. Boost Spirit? Serialization? I doubt it. Safe Numerics? I think this should be in standard 15 years ago - but it doesn't seem to create much interest. Looking forward - lets focus less on the standard and more on rolling back the tide of crappy software that we're drowning in. 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.