Dear Phil, Oh great, so this is another review where what we're supposed to be
reviewing is a moving target? That's frustrating. I've not followed much of the discussion, really due to lack of time but I'll also claim that it allows me to form my own opinions without undue influence from what other people think - and now having read the documentation linked from the review announcement I hear that I should have been looking at another branch.
Apart from the extra work that this causes for reviewers, it also is in danger of leading to "design by review". Rapidly re-designing something based on a jumble of feedback from multiple people in a short time is not a good way to produce the best solution to a problem, IMHO.
Nobody is asking you to review a moving target: I was simply expressing that the other review comments have been mentioned in other threads and cleaned up in a feature/boost.review branch. That doesn't mean you have to review it: it just means I am taking your feedback into account. This also does not mean I am changing the code in any material way: I had a good design with a few flaws, some feedback was very valid and concerning, and others were less concerning. The design of the abstraction has not changed at all, and the reviewers here are not designing out_ptr. Glen:
That's why multiple companies with large C legacies have used it with the already enormous success that are smart pointers.
Is this referring to "out_ptr" here or again, something like it?
Both. There is a wide degree of existing practice and multiple individuals and companies coming up with the same (but separate) implementations, and companies and individuals using my version of out_ptr (not too many users of the boost version yet because it's still under review, but the standalone version has field experience). Sincerely, JeanHeyd