| Duoas (6734) | |||
|
This code is being modified... It currently has a couple of bugs. Hey all, I just wanted to play around with this kind of stuff so I thought I'd share. This is a stdiobuf implementation of my own design. The purpose is to allow you to wrap a C stdio FILE* with a std::iostream. I make no claims as to correctness or efficiency. (But I think I did a pretty good job...) It is sometimes convenient to do this kind of thing and get the full power of C++ while interfacing with C. It won't prevent you from doing particularly stupid things with it though.
Due to post size, the file must be split. The remainder follows below. | |||
|
Last edited on
|
|||
| Duoas (6734) | |||
You can also use it much like you use a normal std::fstream, except it works through a FILE*, of course... It is most convenient, however, if you have an open FILE* that you wish to perform some C++ manipulations on... All commentary and feedback welcome. --Michael | |||
|
Last edited on
|
|||
| computerquip (1892) | |
|
Excellent job! When would I want to use this? btw, your namespace is pretty awesome. | |
|
|
|
| Duoas (6734) | |||
|
Thanks! :-) Uses Use it whenever you must use a FILE* but still want C++ super powers. Typical instances are when interfacing with a C library and when playing with tmpfile() and the like. For example:
Other Issues An unresolved issue is whether the destructor should endeavor to automatically close the file or not, or whether this should be a flaggable option. This is what I am currently most concerned with. I'd like to figure out what I want to do before this page archives (and becomes non-editable). Namespace Thanks. "Duoas" is a phonetic writing to help people (of any language) properly pronounce "dúthomhas", which is Gaelic for "enigma". Which... having explained it it's not much of a mystery anymore... Alas. At least it's unique... :-] | |||
|
|
|||
| firedraco (5414) | |
| IMO, it should close it (if only to make it seem more like an fstream). | |
|
|
|
| Duoas (6734) | |
|
That was my first thought too. Here's the scenario I am wondering about: a foreign library gives me a FILE* to read/write data, but I only want to manipulate the stream for a short bit -- said library will manipulate the stream further after I am done with it. If I close it, that is a problem for the interfacing code. I am pretty sure I will update it to make closing an option. My current thought is that it should only automatically close the FILE if it opened the file to begin with. There will be an optional argument to modify this behavior, as well as an "unlink" or "disassociate" method or something... Hmm, I like that. I think I'll do that now... | |
|
|
|
| RedX (156) | |||
Why does this work? You did not supply any operators to convert to either int or bool or anything else... | |||
|
|
|||
| Duoas (6734) | |
|
It is inherited from the std::basic_iostream. I still need to fix this. There are still a couple of bugs to fix, and as this is just a fun hack I had to put it on the back burner for a while. I'll try to fix it sooner than later though (before this topic gets archived...) | |
|
|
|
| RedX (156) | |
| I've seen that it derived from that. but how does std::basc_iostream know that you have successfully opened a file? | |
|
|
|
| Incubbus (675) | |
because the !operator has been internally overloaded to do a tf.fail() or tf.bad()[Or what it has been - I don´t remember, but it checks for the error flags]
| |
|
|
|
| Duoas (6734) | |
|
Yes, the ! operator and the void* operator are overloaded to correspond to fail() and good(), respectively. http://www.cplusplus.com/reference/iostream/ios/operatornot/ http://www.cplusplus.com/reference/iostream/ios/operator_voidpt/ | |
|
|
|
| QWERTYman (458) | |
| "Enigma", you are epic. | |
|
|
|
| RedX (156) | |
|
Well i don't want to be nit-picky but you don't provide implementations of neither of those. All i could find was pbackfail(); I want to know this to better understand how the iostream class is setup. | |
|
|
|
| Incubbus (675) | |||
That´s because
| |||
|
|
|||
| Grey Wolf (3172) | |
|
Duoas, I thought you might be interested, just run your code through Visual Studio 2010 with my standard 'release' settings (but without treat warnings as errors), including: + warning level 4 [-Wall just spat the dummy with 127 warnings in un/semi-related code] + Code Analysis enabled (all rules) » VC had a problem the and on line 186 (of stdiostream.hpp).1 » warning C4244: 'argument' : conversion from '__int64' to 'long', possible loss of data on line 202 » warning C4100: 'which' : unreferenced formal parameter on line 195 » warning C4244: 'argument' : conversion from 'std::streamoff' to 'long', possible loss of data on line 211 » warning C4100: 'which' : unreferenced formal parameter on line 208 » warning C6031: Return value ignored: 'fsetpos' on line 131 1 Turned off language extensions to get around this. Why support for and, or, et al is removed with language extensions turned on I will never understand. | |
|
|
|
| Duoas (6734) | |
|
Ah, that's because I forgot to #include <ciso646>. Thanks for the feedback. I'll probably work on this today... | |
|
|
|