Re: [boost] minor scoped_ptr/scoped_array feature request
Thorsten Ottosen <[EMAIL PROTECTED]> writes: > - Original Message - > From: "Peter Dimov" <[EMAIL PROTECTED]> > [nip] >> In general, it is recommended practice to always assert() preconditions in >> client code, instead of relying on in-library asserts. First, the library > is >> not required to have asserts, and second, the earlier you catch > precondition >> violations, the better (call stacks aren't universally available). > > I don't get this. It's a poor library if it does not even check its > own preconditions in eg. debug mode. Not all preconditions are effectively checkable. > Moreover, if you put the precondition in the library, you take the > burden away from the client No you don't. Either it's a precondition or it's not. If the library documents behavior in case of a "precondition violation", it's not a precondition anymore. The client can call the function and reasonably expect the documented behavior. > this is highly recommeded since it encapsulates commen code _one_ > place, not O(n) places! You can always add wrappers that add the checking you desire, and more importantly, implement some useful (to you) response to a failed check. However, there's no way to take away checking if it gets put in the library, and there's no way to change the response in case of a failed check if it's not the response you need. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] minor scoped_ptr/scoped_array feature request
- Original Message - From: "Peter Dimov" <[EMAIL PROTECTED]> > From: "Thorsten Ottosen" <[EMAIL PROTECTED]> > > From: "Peter Dimov" <[EMAIL PROTECTED]> > > [nip] > > > In general, it is recommended practice to always assert() preconditions > in > > > client code, instead of relying on in-library asserts. First, the > library > > is > > > not required to have asserts, and second, the earlier you catch > > precondition > > > violations, the better (call stacks aren't universally available). > > > > I don't get this. It's a poor library if it does not even check its own > > preconditions > > in eg. debug mode. Moreover, if you put the precondition in the library, > you > > take the burden away from the client; this is highly recommeded since it > > encapsulates > > commen code _one_ place, not O(n) places! > > Note that "recommended practice" in my statement above means "recommended > for library users." When you say "highly recommended" you mean "recommended > for library writers." Yes, but note that having both is less fortunate. Either we agree that library writers check preconditions and then clients don't or we agree that clients check preconditions and library writers don't. One reason that C is such a pain in the *** to use is because its the cliets responsibility to check conditions , e.g. int * i = malloc( sizeof( i ) ); assert( i ); Libraries should always check as much as possible. regards Thorsten, AAU ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] minor scoped_ptr/scoped_array feature request
From: "Thorsten Ottosen" <[EMAIL PROTECTED]> > From: "Peter Dimov" <[EMAIL PROTECTED]> > [nip] > > In general, it is recommended practice to always assert() preconditions in > > client code, instead of relying on in-library asserts. First, the library > is > > not required to have asserts, and second, the earlier you catch > precondition > > violations, the better (call stacks aren't universally available). > > I don't get this. It's a poor library if it does not even check its own > preconditions > in eg. debug mode. Moreover, if you put the precondition in the library, you > take the burden away from the client; this is highly recommeded since it > encapsulates > commen code _one_ place, not O(n) places! Note that "recommended practice" in my statement above means "recommended for library users." When you say "highly recommended" you mean "recommended for library writers." ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] minor scoped_ptr/scoped_array feature request
- Original Message - From: "Peter Dimov" <[EMAIL PROTECTED]> [nip] > In general, it is recommended practice to always assert() preconditions in > client code, instead of relying on in-library asserts. First, the library is > not required to have asserts, and second, the earlier you catch precondition > violations, the better (call stacks aren't universally available). I don't get this. It's a poor library if it does not even check its own preconditions in eg. debug mode. Moreover, if you put the precondition in the library, you take the burden away from the client; this is highly recommeded since it encapsulates commen code _one_ place, not O(n) places! regards Thorsten Ottsen, AAU ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] minor scoped_ptr/scoped_array feature request
From: "Dan Gohman" <[EMAIL PROTECTED]> [...] > Documentation: > > set > > void set(T * p); // never throws > > Stores a copy of p, which must have been allocated via a C++ new > expression or be 0. Behavior is undefined if the stored pointer > is not 0. Rejected, sorry. :-) Introducing undefined behavior for its own sake is never a good design. You can always use BOOST_ASSERT(!p); p.reset(new X); in client code to emulate the behavior of your proposed 'set'. In general, it is recommended practice to always assert() preconditions in client code, instead of relying on in-library asserts. First, the library is not required to have asserts, and second, the earlier you catch precondition violations, the better (call stacks aren't universally available). So "by the book" you'd have written BOOST_ASSERT(!p); p.set(new X); that's not really that different from the above to warrant an interface change. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] minor scoped_ptr/scoped_array feature request
I've been using scoped_ptr and scoped_array in several large
projects, and I'm very happy with them.
One feature that they lack that would be useful for me is a set
member function. It would be similar to reset, except that it
would require the stored pointer to be 0. This would allow user
code to more explicitly describe what is happening.
For example, in a constructor, it is not always easy to
initialize scoped_ptr members until the body of the constructor.
Using reset to initialize them works, but reset means ``invoke
delete on the current pointer and then assign it with this new
value''. In the constructor body (and in similar situations)
there would never be an existing object, so a set method would
be more descriptive.
The requirement that the stored pointer be 0 is important
because it ensures that the set function wouldn't compromise
any of the guarantees that scoped_ptr and scoped_array provide.
Here's how it would look in scoped_ptr:
Documentation:
set
void set(T * p); // never throws
Stores a copy of p, which must have been allocated via a C++ new
expression or be 0. Behavior is undefined if the stored pointer
is not 0.
Implementation:
void set(T * p) // never throws
{
BOOST_ASSERT(ptr == 0);
ptr = p;
}
Dan
--
Dan Gohman
[EMAIL PROTECTED]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
