----- Original Message ----- From: "David Abrahams" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Thursday, December 12, 2002 3:45 PM Subject: Re: [boost] Formal review: Optional library
> > > > In order to achieve this, I considered fundamental the following > > rule of thumb: > > If optional<> is replaced by a pointer, and provided that uninitialized > > optionals are defined as null pointers, any exression using optionals > > should either fail to compile or behave exactly the same. > > This rule allows the programmer to unambiguously infer the > > semantic of a given expression using optional. > > Have you got even a single real use-case where an optional can be > usefully substituted for a pointer in generic code? > > I think it's important to have a few of these in hand before > predicating interface design principles on the idea. > Fair enough. I have not exactly replaced it in a completely generic code (a templated algorithm), but I had (A) replaced optional<T> by shared_ptr<T> many times: this happens when the optional object grows too much for the deep-copy of optional<>. In this case, I switch to shared_ptr<> with dynamic allocation. The recievers of the optional objects never had to change beyond the type of the variables used. (B) replaced optional<T> as function arguments with pointers. At some point I realized that the code inside the function would actually behave exactly the same even if the argument were pointers instead of optional<>. Then I deprecated optional<> as arguments to functions because they were unnecesary; but the point is that I never had to worry about the semantics inside the function. I concede that the above 'design principle' is more a desire than an achieved goal, but it is a useful one, IMO. If you change from optional<> to pointers, the lower the impact the better. Maybe the proposed interface doesn't give you this much, but clearly, allowing relop to compare values without the explicit dereference would spoil any chance of fulfilling this principle. As it is currently specified, changes would have to be made on the value-semantics (container-like) part of the interface. relational operators will appear on boolean contexts just like safe_bool, so you would have expressions testing for initialization states: ( opt == 0 ), and expressions testing for value equality: ( opt1 == opt2 ) both with the same syntax. Fernando Cacciola _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
