Issue 18220: View's block reference-counting is inconsistent (vsiplxx-rtf) Source: (Mr. Brooks Moses, brooks.moses(at)dpdx.net) Nature: Revision Severity: Minor Summary: The description of how block reference-counting works with view-allocated blocks is inconsistent. In 6.1.1. [block.alloc], it is stated that "For a block allocated by a view constructor, the effect of creation should include the effect of invoking increment_count." In 8.1 [view.view], however, the contrary requirement is given: "A constructor that does allocate its block must not invoke its block's increment_count member function." These do not appear to be consistent -- or, at the very least, are very confusing. I suppose that the intended meaning is that, when a view allocates a block, the act of creating that block should increment the count, but that the view constructor should not otherwise increment the count. However, that's not at all clear from the text. Further, in 6.1.1, there is this note: "Note: For a block allocated by a view constructor, the number of increment_count invocations should meet or exceed the number of decrement_count invocations if the block is to be used. When the number of decrement_count invocations exceeds, not just equals, increment_count invocations, the block should be deallocated." This seems at first glance to be inconsistent with the definition of decrement_count, which states that the block will be deallocated when the value reaches zero, not goes below zero. It is only consistent if we assume that the phrase "the effect of invoking increment_count" does not include the effect of incrementing the number of times we consider increment_count to have been invoked! Much of this would be clarified if we simply explicitly stated, in the block requirements, that the "use count" should be set to one in the block constructor, rather than the "effect of calling increment_count" wording. Then we could omit the 6.1.1 paragraph 7 note entirely. (That points out a related omission: We do not actually specify the initial use-count value for the general case; for blocks that are not Dense and not created by a view constructor, a conforming implementation could initialize the use-count to infinity. Or three, just for perversity. This is probably not desirable.) 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:48:50 -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 (#23 from me) X-OriginalArrivalTime: 23 Oct 2012 20:48:50.0145 (UTC) FILETIME=[CE1A4510:01CDB15F] Name: Brooks Moses Employer: Mentor Graphics mailFrom: brooks_moses@mentor.com Terms_Agreement: I agree Specification: VSIPL++ Section: 6.1.1. [block.alloc], 8.1. [view.view] FormalNumber: ptc/2012-07-27 Version: 1.2 - FTF Beta 1 Doc_Year: 2012 Doc_Month: August Doc_Day: 10 Page: 25, 48 Title: View's block reference-counting is inconsistent. Nature: Bug Severity: Minor B1: Report Issue Description: The description of how block reference-counting works with view-allocated blocks is inconsistent. In 6.1.1. [block.alloc], it is stated that "For a block allocated by a view constructor, the effect of creation should include the effect of invoking increment_count." In 8.1 [view.view], however, the contrary requirement is given: "A constructor that does allocate its block must not invoke its block's increment_count member function." These do not appear to be consistent -- or, at the very least, are very confusing. I suppose that the intended meaning is that, when a view allocates a block, the act of creating that block should increment the count, but that the view constructor should not otherwise increment the count. However, that's not at all clear from the text. Further, in 6.1.1, there is this note: "Note: For a block allocated by a view constructor, the number of increment_count invocations should meet or exceed the number of decrement_count invocations if the block is to be used. When the number of decrement_count invocations exceeds, not just equals, increment_count invocations, the block should be deallocated." This seems at first glance to be inconsistent with the definition of decrement_count, which states that the block will be deallocated when the value reaches zero, not goes below zero. It is only consistent if we assume that the phrase "the effect of invoking increment_count" does not include the effect of incrementing the number of times we consider increment_count to have been invoked! Much of this would be clarified if we simply explicitly stated, in the block requirements, that the "use count" should be set to one in the block constructor, rather than the "effect of calling increment_count" wording. Then we could omit the 6.1.1 paragraph 7 note entirely. (That points out a related omission: We do not actually specify the initial use-count value for the general case; for blocks that are not Dense and not created by a view constructor, a conforming implementation could initialize the use-count to infinity. Or three, just for perversity. This is probably not desirable.) - Brooks