Re: [boost] New Library Proposal: dual_state
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Sunday, July 10, 2005 10:23 PM To: boost@lists.boost.org Subject: Re: [boost] New Library Proposal: dual_state
Eelis van der Weegen <gmane@contacts.eelis.net> writes:
So, in conclusion, the motivation for your dual_state is very valid, but personally I think Boost.Optional is a more appropriate design.
IMO the "guaranteed object delivery" feature makes for a useful specialization of the Boost.Optional design. However, it would be nice to have both; it's not an alternative to Boost.Optional.
I agree. These are two separate ideas, each with its own utility.
There's a lot of resonance with the Boost.Parameter library in here.
Where can I find information on Boost.Parameter? One additional thought occurred to me. How does Boost.Optional handle cases where object construction fails? I'm not sure how many approaches exist to the problem of failed constructors, but I think most programmers agree that constructors should rarely (if ever) be allowed to throw an exception. Would it make sense for Boost.Optional to detect failed constructors and consider those objects uninitialized? Here is a contrived example: // -- begin class construct_status { /* TBD */ }; class foo : public construct_status { int *i; public: foo() throw() : i(new(nothrow) int) { if( !i ) { this->construct_status::set_bad(); } else { this->construct_status::set_good(); } } }; boost::optional<foo> x = foo(); if( !x ) { // end up here if the foo constructor called construct_status::set_bad } // -- end It seems that if Boost.Optional users must always test for initialization anyway, we could add a valid object check for free. I would be interested to hear what others think about this. -Andy
On 7/10/05, Jost, Andrew <Andrew_Jost@mentor.com> wrote:
One additional thought occurred to me. How does Boost.Optional handle cases where object construction fails? I'm not sure how many approaches exist to the problem of failed constructors, but I think most programmers agree that constructors should rarely (if ever) be allowed to throw an exception. Would it make sense for Boost.Optional to detect
I dont agree. I think that if an object failed to be constructed, it MUST throw...
failed constructors and consider those objects uninitialized? Here is a contrived example:
IMO, the "catching exception"-way is better. If someone wants to return with an unitialized object, then it must try/catch and return an unitialized object then(very ugly, but I cant see a better way)...
// -- begin class construct_status { /* TBD */ };
class foo : public construct_status { int *i; public: foo() throw() : i(new(nothrow) int) { if( !i ) { this->construct_status::set_bad(); } else { this->construct_status::set_good(); } } };
boost::optional<foo> x = foo(); if( !x ) { // end up here if the foo constructor called construct_status::set_bad } // -- end
I dont think this code will work as expected. The foo will be constructed before optional<foo> starts, so boost::optional will never get a chance to catch the exception, neither starts to be constructed. In this code the if will never be reached. I dont even think there's a way to do what you want, because the object wont be constructed inside boost::optional.
It seems that if Boost.Optional users must always test for initialization anyway, we could add a valid object check for free. I would be interested to hear what others think about this.
But IMO, an exception means that something really wrong happened, and as so, the code that probably knows how to handle this is way up to where the exception happened. And after all, that's why exceptions wind up automatically.
-Andy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
One additional thought occurred to me. How does Boost.Optional handle cases where object construction fails? I'm not sure how many approaches exist to the problem of failed constructors, but I think most programmers agree that constructors should rarely (if ever) be allowed to throw an exception. Would it make sense for Boost.Optional to detect
I dont agree. I think that if an object failed to be constructed, it MUST throw...
Even more importantly... Objects can fail to construct, or only partially construct, based on some resource exception. C++ doesn't provide a guarantee that constructors will never throw. So saying that "...counstructors should rarely..." could be equated to "why bounds check". The fact is that you should be handling failure conditions, even if they are rare.
failed constructors and consider those objects uninitialized? Here is a contrived example:
IMO, the "catching exception"-way is better. If someone wants to return with an unitialized object, then it must try/catch and return an unitialized object then(very ugly, but I cant see a better way)...
Failed constructors cannot be considered unitialized, as objects may get partially constructed. And, justifiably, most programmers dont need to care if an object fails to construct, thus allowing the exception to eventually cause the program to exit. But if you need to ensure that objects get fully constructed, you need to try/catch. There is a good write up of this in the book 'More effective C++' by Scott Meyers Mathew Robertson
"Jost, Andrew" <Andrew_Jost@mentor.com> writes:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Sunday, July 10, 2005 10:23 PM To: boost@lists.boost.org Subject: Re: [boost] New Library Proposal: dual_state
Eelis van der Weegen <gmane@contacts.eelis.net> writes:
So, in conclusion, the motivation for your dual_state is very valid, but personally I think Boost.Optional is a more appropriate design.
IMO the "guaranteed object delivery" feature makes for a useful specialization of the Boost.Optional design. However, it would be nice to have both; it's not an alternative to Boost.Optional.
I agree. These are two separate ideas, each with its own utility.
There's a lot of resonance with the Boost.Parameter library in here.
Where can I find information on Boost.Parameter?
In the CVS at libs/parameter (new docs in progress at libs/parameter/doc) and boost/parameter. An earlier version of the tutorial docs are at http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost-sandbox/boost-sandbox...
One additional thought occurred to me. How does Boost.Optional handle cases where object construction fails? I'm not sure how many approaches exist to the problem of failed constructors, but I think most programmers agree that constructors should rarely (if ever) be allowed to throw an exception.
No, that's approximately 180 degrees away from correct. Bjarne Stroustrup used to recommend it, and it appears that a few people still think it makes sense, but in fact throwing from constructors is a very good idea because it allows us to establish simple class invariants. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
Felipe Magno de Almeida -
Jost, Andrew -
Mathew Robertson