[Iostreams] How to check whether file has ben opened?
Hi, I'm using Boost 1.42.0 and I have the same problem like vandamme described in this post at the end: http://groups.google.com/group/boost-list/browse_thread/thread/c290c987bf1fa... The following code will assert if the file "test" does not exist: std::string filename("test"); boost::iostreams::streamboost::iostreams::file_source file; file.open(filename.c_str()); if (file.is_open()) { // assert fires if file "test" does not exist assert(boost::filesystem::exists(filename)); } The indirect_streambuf doesn't check the device and just returns true if open has been called (independent of whether open has been successful). If I use the std::ifstream supplied with MSVC 9.0 is_open() returns false if the file does not exits. Checked by replacing file declaration with: std::ifstream file; Is this a bug? If not how can I test whether opening the stream succeeds? Thanks, Daniel
Daniel Eiband wrote:
Hi, I'm using Boost 1.42.0 and I have the same problem like vandamme described in this post at the end:
http://groups.google.com/group/boost-list/browse_thread/thread/c290c987bf1fa...
The following code will assert if the file "test" does not exist:
std::string filename("test"); boost::iostreams::streamboost::iostreams::file_source file;
file.open(filename.c_str()); if (file.is_open()) { // assert fires if file "test" does not exist assert(boost::filesystem::exists(filename)); }
The indirect_streambuf doesn't check the device and just returns true if open has been called (independent of whether open has been successful).
If I use the std::ifstream supplied with MSVC 9.0 is_open() returns false if the file does not exits. Checked by replacing file declaration with:
std::ifstream file;
Is this a bug? If not how can I test whether opening the stream succeeds?
I think you should file a bug. This can't be the intended behavior. Regards, Roland
Daniel Eiband wrote:
I think you should file a bug. This can't be the intended behavior.
Thanks for the reply. I created ticked #4054 for this issue.
Regards,
Daniel Hi,
just wanted to mention that for this specific library (iostreams) it is best to try to create a patch yourself. The original maintainer is no longer active. Daniel James has started to process patches. So the fastest way to remove that problem is adding a patch to your ticket. Regards, Roland
The original maintainer is no longer active. Daniel James has started to process patches. So the fastest way to remove that problem is adding a patch to your ticket.
Hi, I am quite new to the Iostreams library and just started to implement my first devices. I am willing to deliver a patch, but this is not a trivial problem. I looked into the documentation and the users guide tells the following about exception policies: http://www.boost.org/doc/libs/1_42_0/libs/iostreams/doc/index.html - "These member functions throw exceptions to report errors": So the best a file device can do when opening fails is throwing a failure exception. This is currently not the case (e.g. basic_file ignores the return value of the filebuf::open() call). - "With streams, therefore, the user has a choice whether to enable exceptions": This is currently not the case for boost::iostreams::stream. Exceptions of devices (which is the recommended/only way of reproting errors in devices) are passed to the user code ignoring exception masks. Furthermore, the failbit is not set when an operation like open fails (also see bug https://svn.boost.org/trac/boost/ticket/3935) Two actions that pop up to my mind: -> Considering the design choice in the above mentioned exception documentation, file devices must throw exceptions when open(), close(), ... fails. -> The ugly part: Ignore failbit/badbit/eofbit and exception mask or translate exceptions back to iostate for boost::iostreams::stream? This affects not only opening or closing the stream but also all other exceptions e.g. bad_seek() (failbit also not set in current implementation). Should this discussion go to a different mailing list? Who is more experienced with iostreams? Kind regards, Daniel
Daniel Eiband wrote:
The original maintainer is no longer active. Daniel James has started to process patches. So the fastest way to remove that problem is adding a patch to your ticket.
Hi,
I am quite new to the Iostreams library and just started to implement my first devices. I am willing to deliver a patch, but this is not a trivial problem. I looked into the documentation and the users guide tells the following about exception policies:
http://www.boost.org/doc/libs/1_42_0/libs/iostreams/doc/index.html
- "These member functions throw exceptions to report errors": So the best a file device can do when opening fails is throwing a failure exception. This is currently not the case (e.g. basic_file ignores the return value of the filebuf::open() call).
- "With streams, therefore, the user has a choice whether to enable exceptions": This is currently not the case for boost::iostreams::stream. Exceptions of devices (which is the recommended/only way of reproting errors in devices) are passed to the user code ignoring exception masks. Furthermore, the failbit is not set when an operation like open fails (also see bug https://svn.boost.org/trac/boost/ticket/3935)
Two actions that pop up to my mind:
-> Considering the design choice in the above mentioned exception documentation, file devices must throw exceptions when open(), close(), ... fails.
-> The ugly part: Ignore failbit/badbit/eofbit and exception mask or translate exceptions back to iostate for boost::iostreams::stream? This affects not only opening or closing the stream but also all other exceptions e.g. bad_seek() (failbit also not set in current implementation).
Should this discussion go to a different mailing list? Who is more experienced with iostreams?
Kind regards,
Daniel
Hi, when it comes to the iostream internals, I am quite new to the library myself. I am mostly using it for memory mapped files and compression/decompression. The latter has some bugs, too, for which I hope to find the time to send patches eventually... I guess you should take the discussion to the boost developers list. Regards, Roland
participants (2)
-
Daniel Eiband -
Roland Bock