Topic: Why doesn't the standard specify a way of getting at the OS roots of a stream.
Author: Barry Margolin <barmar@genuity.net>
Date: Mon, 1 Apr 2002 21:32:17 GMT Raw View
In article <3ca4df89.268508812@nntp.interaccess.com>,
Thaddeus L Olczyk <olczyk@interaccess.com> wrote:
>On Wed, 27 Mar 2002 16:19:17 CST, Barry Margolin <barmar@genuity.net>
>wrote:
>>Since the functions that actually *use* the FileDescriptor would have to be
>>OS-specific, what's wrong with an OS-specific function to get it in the
>>first place (like Unix's fileno() and fdopen() functions)? Is there really
>>a big gain from having the conversion functions and type declaration in the
>>portable part of your program rather than the OS-dependent part?
>
>OK.
>1) voo foo(ostream &s)
> {
> // How do I now get the underlieing fileno here?
> ....
> }
>2) voo foo(ostream &s)
> {
> ...
> s.FileDescriptor()=OS_Specific::FileDescription;
> ...
> }
> Oops. This is broken because we changed from compiler A which had
> a stream::FileDescriptor to compiler B which does not have this
> method. Instead it uses streambuf::fileid(). God I hate to think
> what will happen if we port to compiler C which doesn't allow us
> to set the FileDescriptor.
The same thing as would happen if you were trying to port to an operating
system where this doesn't even make sense.
Since this is OS-specific, it should be specified by the OS vendor, not the
language standard. Then all implementors of C++ for *that* OS would have
to implement that mechanism. For instance, it could be specified in POSIX,
just as fileno() and fdopen() are for C.
Vendors for other OSes may choose to copy that interface to make it easier
to port, much as many non-Unix vendors provide POSIX APIs.
--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: "Sriram Chandrasekaran" <sriram@ulticom.com>
Date: Tue, 2 Apr 2002 15:28:28 GMT Raw View
Hello,
When we use the word OS_specific, we are trying to make it not portable.
Secondly , there must be a package that actually can give OS_specific
details and the object can then be serialized and passed !
It should not be part of the language.
"Barry Margolin" <barmar@genuity.net> wrote in message
news:bk4q8.10$P3.225@paloalto-snr1.gtei.net...
> In article <3ca4df89.268508812@nntp.interaccess.com>,
> Thaddeus L Olczyk <olczyk@interaccess.com> wrote:
> >On Wed, 27 Mar 2002 16:19:17 CST, Barry Margolin <barmar@genuity.net>
> >wrote:
> >>Since the functions that actually *use* the FileDescriptor would have to
be
> >>OS-specific, what's wrong with an OS-specific function to get it in the
> >>first place (like Unix's fileno() and fdopen() functions)? Is there
really
> >>a big gain from having the conversion functions and type declaration in
the
> >>portable part of your program rather than the OS-dependent part?
> >
> >OK.
> >1) voo foo(ostream &s)
> > {
> > // How do I now get the underlieing fileno here?
> > ....
> > }
> >2) voo foo(ostream &s)
> > {
> > ...
> > s.FileDescriptor()=OS_Specific::FileDescription;
> > ...
> > }
> > Oops. This is broken because we changed from compiler A which had
> > a stream::FileDescriptor to compiler B which does not have this
> > method. Instead it uses streambuf::fileid(). God I hate to think
> > what will happen if we port to compiler C which doesn't allow us
> > to set the FileDescriptor.
>
> The same thing as would happen if you were trying to port to an operating
> system where this doesn't even make sense.
>
> Since this is OS-specific, it should be specified by the OS vendor, not
the
> language standard. Then all implementors of C++ for *that* OS would have
> to implement that mechanism. For instance, it could be specified in
POSIX,
> just as fileno() and fdopen() are for C.
>
> Vendors for other OSes may choose to copy that interface to make it easier
> to port, much as many non-Unix vendors provide POSIX APIs.
>
> --
> Barry Margolin, barmar@genuity.net
> Genuity, Woburn, MA
> *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to
newsgroups.
> Please DON'T copy followups to me -- I'll assume it wasn't posted to the
group.
>
> ---
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: olczyk@interaccess.com (Thaddeus L Olczyk)
Date: Wed, 27 Mar 2002 18:22:31 GMT Raw View
OK. There is the portability issue, but at least something uniform can
be specified.
struct OS_Specifc
{
FileDescriptor desc;
}
OS_Specific &stream::getDescriptor();
void stream::setDescriptor(OS_Specific &desc);
where FileDescriptor is the underlying descriptor of the file.
This would do two things.
1) It would gaurantee that you can map descriptors to streams, if they
are available.
2) It would gaurantee that libraries on specific platforms would look
similar. If done right it wouold also let you seperate out the
nonportable parts.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: Barry Margolin <barmar@genuity.net>
Date: Wed, 27 Mar 2002 16:19:17 CST Raw View
In article <3ca1e2cb.203806500@nntp.interaccess.com>,
Thaddeus L Olczyk <olczyk@interaccess.com> wrote:
>This would do two things.
>1) It would gaurantee that you can map descriptors to streams, if they
>are available.
>2) It would gaurantee that libraries on specific platforms would look
>similar. If done right it wouold also let you seperate out the
>nonportable parts.
Since the functions that actually *use* the FileDescriptor would have to be
OS-specific, what's wrong with an OS-specific function to get it in the
first place (like Unix's fileno() and fdopen() functions)? Is there really
a big gain from having the conversion functions and type declaration in the
portable part of your program rather than the OS-dependent part?
--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]
Author: olczyk@interaccess.com (Thaddeus L Olczyk)
Date: Thu, 28 Mar 2002 17:47:31 GMT Raw View
On Wed, 27 Mar 2002 16:19:17 CST, Barry Margolin <barmar@genuity.net>
wrote:
>In article <3ca1e2cb.203806500@nntp.interaccess.com>,
>Thaddeus L Olczyk <olczyk@interaccess.com> wrote:
>>This would do two things.
>>1) It would gaurantee that you can map descriptors to streams, if they
>>are available.
>>2) It would gaurantee that libraries on specific platforms would look
>>similar. If done right it wouold also let you seperate out the
>>nonportable parts.
>
>Since the functions that actually *use* the FileDescriptor would have to be
>OS-specific, what's wrong with an OS-specific function to get it in the
>first place (like Unix's fileno() and fdopen() functions)? Is there really
>a big gain from having the conversion functions and type declaration in the
>portable part of your program rather than the OS-dependent part?
OK.
1) voo foo(ostream &s)
{
// How do I now get the underlieing fileno here?
....
}
2) voo foo(ostream &s)
{
...
s.FileDescriptor()=OS_Specific::FileDescription;
...
}
Oops. This is broken because we changed from compiler A which had
a stream::FileDescriptor to compiler B which does not have this
method. Instead it uses streambuf::fileid(). God I hate to think
what will happen if we port to compiler C which doesn't allow us
to set the FileDescriptor.
3) Gee. All those nice stream management routines would work real nice
for our socket streams, except that even though the socket streams
work like any other stream in the OS. Looks like we have a tough
decision ahead: rewrite all those routines, or try to create from
scratch a socketstreambuf when the basic implementation will do,
or worse:: copy and paste the standard streambuf and modify it to
work with sockets.
PS:
I looking again at OS_Specific, it's clear I missed something. There
should be a second member...bool OS_Specific::hasDescriptor.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html ]