Issue 18218: Block refcounting interface error prone, wrong (vsiplxx-rtf) Source: (Mr. Brooks Moses, brooks.moses(at)dpdx.net) Nature: Revision Severity: Minor 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. Resolution: In the interest of closing the current RTF so that the solutions to resolved issues can be made publically available, this issue is deferred to the next RTF. Disposition: Deferred Revised Text: Actions taken: October 23, 2012: received issue Discussion: End of Annotations:===== te: Tue, 23 Oct 2012 13:20:59 -0700 From: Brooks Moses User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Subject: VSIPL++ issue (#20 from me) X-OriginalArrivalTime: 23 Oct 2012 20:20:59.0845 (UTC) FILETIME=[EA86B750:01CDB15B] Name: Brooks Moses Employer: Mentor Graphics mailFrom: brooks_moses@mentor.com Terms_Agreement: I agree Specification: VSIPL++ Section: 6.1 [block.req] FormalNumber: ptc/2012-07-27 Version: 1.2 - FTF Beta 1 Doc_Year: 2012 Doc_Month: August Doc_Day: 10 Page: 39 and others. Title: Block refcounting interface error prone, wrong Nature: Bug Severity: Minor B1: Report Issue Description: 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 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.