Printable View
if I have a raw file descriptor, for example, a socket descriptor, is there any way to take that descriptor and pass it to any type of iostream object to create an iostream that reads and writes that file descriptor? file descriptors are a very common and portable part of most APIs, and if there is no way to do this, it seems like a huge oversight in the design of the iostreams library.
I have written one for this purpose before, actually. I can try to dig it up for you if you would like.
I am not certain I understand what you mean. I believe you mean using a file descriptor in order to read and write from the file described by the file descriptor. If that is the case I don't see why not. That is what fstream does. This is done by the constructor, as noted here
http://publib.boulder.ibm.com/infoce...y/ref/i196.htm (don't know if this is standard or whatever)
I ll test it and see...
EDIT: Does NOT work, should pay more attention on the above side. Sorry
A lot of the problem with that, C_ntua is that a socket is not always considered the same as a file descriptor. In Linux these are treated as being the same animal however Windows does not appreciate you trying to fool it into using a socket as a file descriptor.
This is what you are looking for http://publib.boulder.ibm.com/infoce...y/ref/i196.htm
Note that the site says that boost has better functions for this. So use those. They do exactly what you want. Google for examples...
EDIT: (Seeing the above post) Well, then I believe you have no choice but writing it yourself. Or modifying the existing ones to match your specific data. Or be "clever" and find the actual type of the socket handler (lets say int) and cast it. Or cast it and test it (bad idea). Or... create it and learn in the process. Personally... I would do the third one (shame shame on me)
unfortunately, it appears that the GNU standard C++ library does not support the iostream::iostream(int fd) overload, as it says "invalid conversion from int to const char*" when I try to call it that way.
here is what I have tried apart from the above:
but this doesn't seem to be supported either.Code:FILE* i = fdopen(socket, "r");
FILE* o = fdopen(socket, "w");
std::filebuf ibuf(i, std::ios_base::in);
std::filebuf obuf(o, std::ios_base::out);
my_ifstream.rdbuf(ibuf);
my_ofstream.rdbuf(obuf);
I'm running OpenSuse linux with kernel 2.6.x and gcc 4.2.1, and there are about 6 libstdc++ files in my /usr/lib directory, so I don't even know which one is getting linked in.
What the hell... your code is entirely plausable on OpenSuSE... I have an OpenSuSE box. The one I wrote was to accomodate windows. So it wouldn't be of as much use. Hmmmmmmm I am a little stumped. Why not just use the C functions?
Any particular reason you can't use this?
http://www.boost.org/doc/libs/1_36_0...escriptor.html
There is absolutely no way to get a standard iostream for a file descriptor, except for a few standard library implementations which provide this functionality as an extension.
Not sure exactly how I would use it. it doesn't exactly give any examples, and there isn't any immediately apparent way to read from or write to an instance of any of the classes described in that link. I really don't know anything about boost, so I'm sort of lost here.Quote:
Originally Posted by CornedBee
while we're on the subject, can you recommend any good books dealing with boost?
There's three books that are partially or in whole about Boost, AFAIK:
"Beyond the C++ Standard Library" introduces a few of the oldest and most important Boost libraries.
"C++ Template Metaprogramming" is about template metaprogramming, but also has a section on the MPL and a short section on the Preprocessor library.
"The Boost Graph Library" is exactly what the name says.
Here's the link to the whole documentation of the IOStreams library:
http://www.boost.org/doc/libs/1_36_0...doc/index.html
An example of how to use an arbitrary device with the generic streams (and thus gain standard iostreams syntax) is at the bottom of this page:
http://www.boost.org/doc/libs/1_36_0...c_streams.html
I checked out the boost iostreams and file_descriptor_sink/source, and I was able to make it compile/link with the following code:
but this crashes when I try to read this way. Any ideas on why this might be happening?Code:typedef stream<file_descriptor_sink> ofdstream;
typedef stream<file_descriptor_source> ifdstream;
//in my socket class declaration:
int m_sock; // the actual socket descriptor
ofdstream* ofs;
ifdstream* ifs;
ofdstream& GetOstream(void) { return *ofs; }
ifdstream& GetIstream(void) { return *ifs; }
//in my socket class constructor:
ofs = new ofdstream(m_sock);
ifs = new ifdstream(m_sock);
//in my function that uses the socket, in which the socket object is called sock:
ifdstream& ifs = sock.GetIstream();
ofdstream& ofs = sock.GetOstream();
std::string text_in;
ifs >> text_in;
No. Can you get a backtrace?
it doesn't generate a backtrace. my SIGSEGV handler catches it and exits. I could try debugging, but I'm pretty sure it's crashing either in the boost_iostreams lib or inside std::istream, so I'd have basically no options for fixing it.
Both Boost and GCC are open source, so you have the option of fixing it. More to the point, since many people use these libraries, knowing about a segfault and fixing it would be important to us. Please use a debugger to get a backtrace.
I will try that when I get a chance, but it will have to wait until monday, as I am done with work for the week. I'll let you know the results when I have them.
I was able to debug the program... had to do it from the command line because it is a multi-process server, so I had to attach to a child process, but I was able to find the spot where it crashed.
the line from the debugger was:
I'm not really sure where to go from here.Code:0xb7d01adc in std::istream::istream::sentry::sentry () from /usr/lib/libstdc++.so.6
Hmm, looks like the problem is in Boost.Iostreams after all. Most likely, it crashes when trying to skip whitespace. Unless the streambuf is for some reason null - that would crash there, too. Can you ensure that
just before the I/O operation that leads to the crash?Code:assert(static_cast<std::istream&>(stream).rdbuf());
inserting that line causes it to crash at that line.
The call to rdbuf() crashes? Now that is seriously weird. This is the implementation:
Or does the assertion simply fail?Code:basic_streambuf<_CharT, _Traits>*
rdbuf() const
{ return _M_streambuf; }
the debugger shows that it crashes (SIGSEGV) right at the assert() line. In fact, it doesn't even show that it entered the rdbuf() function.
OK, I'm stumped.
I know this is an old thread but in case anyone else finds this:
Try using boost::iostreams::file_descriptor like this:
stream is now an std::iostream which you can both read and write to and of course fd is the file descriptor which you can lock.Code:int fd = open("filename.txt", O_RDWR);
if (fd == -1) throw "Failed to open file";
io::stream<io::file_descriptor> stream(fd, true);
Well, after the better part of a day of dabbling in the black arts of the various C++ streams classes, I've constructed the following test code that _seems_ to work, and I thought it would be nice to share. I'm not really sure it works properly, so I welcome review by those more steeped in the black arts.
Code:#include <fstream>
#include <iostream>
#include <string>
#include <cmath>
#include <cassert>
#include <cstdio>
#include <stdlib.h>
#include <string.h>
#include <ext/stdio_filebuf.h>
using namespace std;
//std::ofstream stream_002;
int main(){
char *f_template;
f_template = new char(12);
memcpy(f_template, "/tmp/XXXXXX", 12);
int fd = mkstemp(f_template);
std::cout << "File Descriptor # is: " << fd << " file name = " << f_template <<std::endl;
// FILE *frp=fdopen(fd, "r"); // convert it into a FILE *
FILE *fwp=fdopen(fd, "w"); // convert it into a FILE *
// create a file buffer(NOT an iostream yet) from FILE *
// __gnu_cxx::stdio_filebuf<char> frb (frp, ios_base::in);
// Uses:
// stdio_filebuf (std::__c_file *__f, std::ios_base::openmode __mode, size_t __size=static_cast< size_t >(BUFSIZ))
__gnu_cxx::stdio_filebuf<char> fwb (fwp, std::ios_base::out);
// so fwb is of type stdio_filebuf
// istream my_temp_in (&frb); // create a stream from file buffer
std::iostream my_temp_stream_out (&fwb); // create a stream from file buffer
std::fstream my_temp_fstream;
// streambuf *bsbp;
// bsbp = my_temp_out.rdbuf();
// my_temp_fstream.rdbuf(bsbp);
my_temp_fstream.std::ios::rdbuf(my_temp_stream_out.rdbuf());
// my_temp_out << "iostream : Some test text" << std::endl;
// my_temp_out.flush();
my_temp_fstream << "fstream : Some test text" << std::endl;
my_temp_fstream.close();
// while(1){}
// Now take a look in your temp directory for the file
//name printed from the above cout statement. If you cat it out,
//you should see the "test text".
return 0;
}
(from: Streams and File Descriptors - The GNU C Library)
11.1.1 Streams and File Descriptors
When you want to do input or output to a file, you have a choice of two basic mechanisms for representing the connection between your program and the file: file descriptors and streams. File descriptors are represented as objects of type int, while streams are represented as FILE * objects.
File descriptors provide a primitive, low-level interface to input and output operations. Both file descriptors and streams can represent a connection to a device (such as a terminal), or a pipe or socket for communicating with another process, as well as a normal file. But, if you want to do control operations that are specific to a particular kind of device, you must use a file descriptor; there are no facilities to use streams in this way. You must also use file descriptors if your program needs to do input or output in special modes, such as nonblocking (or polled) input (see File Status Flags).
Streams provide a higher-level interface, layered on top of the primitive file descriptor facilities. The stream interface treats all kinds of files pretty much alike—the sole exception being the three styles of buffering that you can choose (see Stream Buffering).
The main advantage of using the stream interface is that the set of functions for performing actual input and output operations (as opposed to control operations) on streams is much richer and more powerful than the corresponding facilities for file descriptors. The file descriptor interface provides only simple functions for transferring blocks of characters, but the stream interface also provides powerful formatted input and output functions (printf and scanf) as well as functions for character- and line-oriented input and output.
Since streams are implemented in terms of file descriptors, you can extract the file descriptor from a stream and perform low-level operations directly on the file descriptor. You can also initially open a connection as a file descriptor and then make a stream associated with that file descriptor.
In general, you should stick with using streams rather than file descriptors, unless there is some specific operation you want to do that can only be done on a file descriptor. If you are a beginning programmer and aren't sure what functions to use, we suggest that you concentrate on the formatted input functions (see Formatted Input) and formatted output functions (see Formatted Output).
If you are concerned about portability of your programs to systems other than GNU, you should also be aware that file descriptors are not as portable as streams. You can expect any system running ISO C to support streams, but non-GNU systems may not support file descriptors at all, or may only implement a subset of the GNU functions that operate on file descriptors. Most of the file descriptor functions in the GNU library are included in the POSIX.1 standard, however.
==========================
anyone please present by a example about this ? how to open a connection as a file descriptor and then make a stream associated with that file descriptor ?.
anyone has any idea ?