This is the mail archive of the libstdc++@sources.redhat.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: How to ...



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>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]