VSIPL 1.6 RTF Avatar
  1. OMG Issue

VSIPL16 — Block refcounting interface error prone, wrong

  • Key: VSIPL16-20
  • Legacy Issue Number: 18218
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    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.

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT