This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: How to ...
- To: libstdc++ at sourceware dot cygnus dot com
- Subject: Re: How to ...
- From: "George T. Talbot" <george at moberg dot com>
- Date: Fri, 22 Sep 2000 15:52:17 -0400
- Organization: Moberg Research, Inc.
Phil Edwards wrote:
>
> On Thu, Sep 21, 2000 at 08:57:36PM +0200, Theodore Papadopoulo wrote:
> >
> > I know that the current goal of gcc and libstdc++-v3 is to
> > implement the C++ standard. However, that standard does not seem to
> > have considered the possibility of getting the file descriptor for
> > iostreams.
>
> It was considered and rejected. Not all environments use file descriptors.
> Of those that do, not all of them use integers to represent them.
How about:
class basic_file
{
.
.
.
typedef __whatever__ __np_file_descriptor;
.
.
.
__np_file_descriptor __np_get_descriptor() const {
return ... };
.
.
.
};
> > This is very annoying when trying to use some system calls
> > such as mmap that requires such file descriptors and obliges the
> > users to use the old C interface.
>
> This can cause all kinds of problems. Once you've opened a file with an
> [io]fstream and started doing things with it, data can be buffered inside
> the fstream. Using the file descriptor to mmap an open fstream's file
> would essentially be doing an "end run" around the buffered data.
>
> This would be one of those features that's easy to use incorrectly.
I agree with Mr. Edwards here. In general, that's not what an iostream
is for.
One thing that I do in my program, which links to the last snapshot you
guys made that wasn't part of GCC, is this:
"socketostream.h"
template<typename _CharT, typename _Traits = char_traits<_CharT>
>
class basic_socketostream : public basic_ostream<_CharT,
_Traits>
{
public:
basic_socketostream(int iSocket)
: basic_ostream<_CharT, _Traits>(0),
m_iSocket(iSocket),
m_fb(iSocket, "socket", ios::out)
{
this->init(&m_fb);
}
virtual ~basic_socketostream()
{
shutdown(m_iSocket, 2);
#ifdef WIN32
#error "close() probably isn't right for a socket!"
#endif
}
private:
int m_iSocket;
filebuf m_fb;
};
typedef basic_socketostream<char> socketostream;
You guys still support this non-standard filebuf constructor, right?
This might help Mr. Papadopoulo.
P.S. Unrelated, to the list: If you mistakenly have a close() call in
~basic_socketostream() above, it causes a memory leak deep in libstdc++
2.90.3. I posted to the list about this a while ago, but never heard
anything back. I've got a test program that demonstrates the memory
leak if anyone wants it. In general, it seemed that any error when
close() is called in a filebuf will cause a memory leak in 2.90.3.
--
George T. Talbot
<george at moberg.com>