How to get the file no from an ostream object?

[pembed2003]

Hi all,
Given something like:

std:fstream out_file("path");

how do I extract the file descriptor from out_file? Is it possible?
What I want is to extract the file descriptor and then pass it to
flock like:

flock(???, LOCK_EX);

Any suggestion? Is it ok to mix flock with std:fstream? If it's
dangerous, what options do I have? Thanks!

 

[John Harrison]

Hi all,
Given something like:

std:fstream out_file("path");

how do I extract the file descriptor from out_file? Is it possible?
What I want is to extract the file descriptor and then pass it to
flock like:

flock(???, LOCK_EX);

Any suggestion? Is it ok to mix flock with std:fstream? If it's
dangerous, what options do I have? Thanks!

It's not possible with the standard file streams in standard C++.

Your only options are to write your own file stream classes, see The
C++ Standard Library by Josuttis for explanations and examples, or to find
someone else who has already done this work for you.

john

 

[Greg Schmidt]

Hi all,
Given something like:

std:fstream out_file("path");

how do I extract the file descriptor from out_file? Is it possible?

Nope. Seems an unfortunate omission. Anyone know why it was left out?

What I want is to extract the file descriptor and then pass it to
flock like:

flock(???, LOCK_EX);

What I did once when I needed a descriptor to pass to a legacy library was
to use fopen to open the file, and create an ofstream with the constructor
that takes a descriptor. Less than optimal, for sure, but it worked for my
purposes.

Any suggestion? Is it ok to mix flock with std:fstream? If it's
dangerous, what options do I have? Thanks!

Don't know about flock, but I recall that there are buffering issues, so
you may need to flush whenever switching between the two modes of access.

 

[Owen Jacobson]

Nope. Seems an unfortunate omission. Anyone know why it was left out?

Because there's no guarantee that there *is* an underlying file descriptor
in the sense that flock expects? Because if it *was* possible to extract
the file descriptor, it might not be in the state other code expects it to
be, and even if it was it very likely wouldn't stay that way?

Consider, if you will, that fstreams generally buffer their input and
output. A naive implementation of a "get_fd" function might not guarantee
that the buffers are flushed. And then, once you have it, how do you
propose to keep the file descriptor and the stream in something
approximating the same state? The whole thing's a mess, and best avoided.

What I did once when I needed a descriptor to pass to a legacy library was
to use fopen to open the file, and create an ofstream with the constructor
that takes a descriptor. Less than optimal, for sure, but it worked for my
purposes.

I don't see a constructor that accepts an int in std:stream.

Don't know about flock, but I recall that there are buffering issues, so
you may need to flush whenever switching between the two modes of access.

flock is defined as part of POSIX, not C or C++. Any interaction it has
with C or C++ is undefined as far as the C++ language is concerned.
However, you might be able to get away with opening the file a second time
with the POSIX open call (using the same filename) and using that handle
for flock. Just don't read or write from or to it.

Not guaranteed, of course. If you *really* need it and you want to do it
"right", use POSIX i/o for things that need flock.

 

[Greg Schmidt]

[good answers to my questions deleted]

I don't see a constructor that accepts an int in std:stream.

Not std:stream, std:fstream. Maybe it's a VC++7.1 extension? My code
looks like this:

FILE *fd = fopen (filename.c_str(), "wb");
ofstream ofs (fd);

FILE appears to be a structure here, not just an int. I wouldn't think it
possible to silently convert a FILE* to a char* for the constructor, nor
would I think that the resulting ofs would be .good() if it did, but it all
works for me so it must be fully supported. I can't find now where it was
in the docs that told me I could do this (I didn't just try it on a whim),
but I've never been very impressed with the MS documentation so this is not
surprising.

 

[Owen Jacobson]

[good answers to my questions deleted]

I don't see a constructor that accepts an int in std:stream.

Not std:stream, std:fstream. Maybe it's a VC++7.1 extension? My code
looks like this:

Which is what I actually meant to type. My apologies. I believe that
iostream.h, the pre-standardization version of the iostream header, and
fstream.h, likewise, did frequently have fstream classes that could accept
an existing FILE* or int during construction.

FILE *fd = fopen (filename.c_str(), "wb");
ofstream ofs (fd);

FILE appears to be a structure here, not just an int. I wouldn't think it
possible to silently convert a FILE* to a char* for the constructor, nor
would I think that the resulting ofs would be .good() if it did, but it all
works for me so it must be fully supported.

....on your specific compiler. Be wary of that; porting your code later
might be problematic.

I can't find now where it was in the docs that told me I could do this
(I didn't just try it on a whim), but I've never been very impressed
with the MS documentation so this is not surprising.

GNU libstdc++:
<http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-3.4/classstd_1_1basic__ofstream.html>

CPlusPlus.com reference docs:
<http://www.cplusplus.com/ref/iostream/ofstream/ofstream.html>

MSDN (VC++ 98):
<http://msdn.microsoft.com/library/d...n-us/vclang98/html/FSTREAM_BASIC_OFSTREAM.asp>

If it was there, it's certainly gone now.

 

[Greg Schmidt]

Which is what I actually meant to type. My apologies. I believe that
iostream.h, the pre-standardization version of the iostream header, and
fstream.h, likewise, did frequently have fstream classes that could accept
an existing FILE* or int during construction.

I'm definitely using fstream, not fstream.h.

...on your specific compiler.

That's what I meant, fully supported in my working environment. It also
probably helps me avoid synchronization and buffering issues that after
this initialization, I only access the file through one or the other
variable, not through both (there's a big switch, and I wanted to keep this
common code in one place rather than duplicating it for each case).

Be wary of that; porting your code later
might be problematic.

There's almost no chance of this code being ported, and if it is this will
be the least of my worries. I try to stick to standard, portable code
whenever possible, but this app is simply a GUI interface (to some custom
hardware) which is being used during development and testing, and will be
abandoned afterwards. The parts that will likely survive into the
follow-up app (e.g. the parts that deal with the hardware) are AFAIK all
standard compliant, but the GUI parts are all MFC, and the code in question
falls into the latter block.

Still, good to know that this isn't a general solution, and that it might
even go away with a compiler upgrade.