On Tue, May 17, 2011 at 6:11 AM, Germán Diago
2011/5/17 Germán Diago
: To see what BOOST_THROW_EXCEPTION does exactly, read the following: http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/BOOST_THROW_EXCEPTIO... http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/throw_exception.html
I already read it. But I can't figure out why it segfaults at all. I have no idea.
I found the error. It had nothing to do with the macro. But I don't know wether this is a bug or not in class shared_ptr:
I have a shared_ptr<FILE> f(fopen(file_that_doesnt_exists, "rb"), &fclose); call.
If fopen returns null I think that the custom deleter is still called even if the class was constructed with a null pointer. Maybe I should make sure myself that fopen doesn't return NULL, because, anyway when you construct a shared_ptr you are passing a valid resource and it is not checked.
Not a bug; a shared_ptr may hold ownership of an object even when shared_ptr::get() returns 0. You could use boost::shared_ptr<FILE> my_fopen( char const * name, char const * mode ) { if( FILE * f = fopen(name,mode) ) return boost::shared_ptr<FILE>(f,fclose); else BOOST_THROW_EXCEPTION(file_open_error()<< boost::errinfo_errno(errno) << boost::errinfo_api_function("fopen") << boost::errinfo_file_name(name) << boost::errinfo_file_open_mode(mode)); } Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode