VSIPL16 — Block refcounting interface error prone, wrong

This issue is copied from an internally-filed issue at Mentor that dates
back to the early days of the specification, circa 2005. I expect it
will be marked as "out of scope" for the VSIPL++ 1.2 FTF, but it should
be considered for a future 2.0 revision of the spec.

The specification requiring Blocks to implement reference counting
has several problems. First, it overconstrains implementations;
they may well have a better way to implement storage management,
if permitted. Second, as an interface it is clumsy and fails to
take advantage of C++ language strengths (most particularly,
destructors) for better safety. Finally, it is far from clear
that the library should ever dispose of a user block. If the
user created it, isn't the user's responsibility to dispose of
it when the user chooses, by whatever means the user chooses?

If in fact the library should take responsibility for discarding
a user's block when it is no longer needed, it suffices to provide
a way for the user to ask that ownership be transferred to the
library, without going into detail about how the library will
manage it afterward.

...

Note that this is also an exception-safety issue. In particular,
with the existing interface block storage could easily leak if an
exception were thrown before whoever was responsible to decrement
the count got to it.

If the spec were to say that all blocks derive from

template <bool isManaged, bool isConst,
typename valueT=..., typename mapT=...>
class vsip::Block_base;

then that base class and the views could handle all the refcounting
business invisibly. Besides being exception-safe and less messy,
it would be incrementally more convenient for users to define their
own block types. (Cf. std::iterator<>.)

Of course users could keep the library from deleting a managed block by
keeping their own view on it, too.

It is possible to implement the library so that blocks and programs
written to the old interface would still work as before.