Subject: Re: [boost] Boost Incubator Status Report
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-11-09 11:36:41
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-tp4668747p4668845.html Sent from the Boost - Dev mailing list archive at Nabble.com.