In article <rfgCHpntG.Dsr@netcom.com> rfg@netcom.com (Ronald F.
Guilmette) writes:

|> In article <KANZE.93Nov29160920@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:

|> >One last standardization issue: 'ios::fd()' will *not* be defined in
|> >the upcoming standard, for the reasons that Jamshid presented.
|> >However, since it should be a member function, it can be added without
|> >interfering with the user name space; an implementation may add this
|> >function as an extension.

|> Sorry James, but I don't think so.  Consider the following code.  Would you
|> not agree that it *must* work?

|>  #define fd {{{{{{{{{{{{
|>  #include <iostream.h>

|>  int main () { return 0; }

Actually, I have no idea what the final standard will say with regards
to this.

My personal opinion is that it *should* be possible to add functions
within standard library classes.  On the other hand, this would mean a
restriction in the namespace available for #define's.  To be frank, I
don't know what the real solution should be.

Realistically, if the extensions are functions (as above), then the
implementor could simply use conditional compilation, ie: #ifdef
POSIX, or something along those lines.  (There is a POSIX flag which
is already used in C for a similar purpose, although I forget exactly
what it is called.)

Of course, this would presumably result in a violation of the one
definition rule, which, of course, leads to undefined behavior.  But
since we are talking about an extended implementation anyway, the
implementor is free to implement the undefined behavior in such a way
that it works.

|> >(I believe that most MS-DOS implementations
|> >have something similar to obtain the DOS file handle.  If MS-DOS and
|> >Unix do the same thing, then it *is* a standard, independantly of what
|> >ISO or ANSI decide...

|> You have a very novel view of language standardization.

|> Perhaps we should just disband X3J16 and SC22/WG14 now and simply arrange
|> a lunch meeting between Bill Gates and Ray Noorda (sp?), whereupon they
|> can sort out the remaining details of C++. :-)

I think that is actually what happened with the BASIC standard.  I
know that there was a standardization committee for BASIC; I think
they even came up with a standard.  But Microsoft didn't follow it,
and the market placed Microsoft compatibility above the standard.

In the same vein, I would be willing to bet that Unix compiler vendors
get a lot of error reports because their compilers "misunderstand" the
'far' keyword.  I imagine that there is a whole generation of C
programmers who are convinced that Unix compilers only implement a
subset of the language, since they don't understand 'far'.  And I
would not be surprised if a Unix compiler vendor actually recognized
the keyword and ignored it, only to keep the crowd happy.  (If I were
a Unix compiler vendor, I think I would.)

For the moment at least, unlike the case of BASIC, both Microsoft and
USL (and Borland) are playing the standards game, and are active and
important members of the standardization committee.  More importantly,
neither of them are trying to use their weight to push a particular
position, but are rather seeking a consensus.  This is, of course, as
it should be, but remembering the way IBM acted in the FORTRAN 90
standardization efforts, it is not automatic.

You put a smiley after your comment, but if Bill Gates and Ray Noorda
(and maybe Philippe Kahn) did decide to work things out between them,
and to ignore X3J16 and SC22/WG14, which group do you think will have
more market influence?  (Although maybe things are changing.  IBM
didn't get their way with FORTRAN 90.)
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <KANZE.93Nov29160920@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>
>One last standardization issue: 'ios::fd()' will *not* be defined in
>the upcoming standard, for the reasons that Jamshid presented.
>However, since it should be a member function, it can be added without
>interfering with the user name space; an implementation may add this
>function as an extension.

Sorry James, but I don't think so.  Consider the following code.  Would you
not agree that it *must* work?

 #define fd {{{{{{{{{{{{
 #include <iostream.h>

 int main () { return 0; }

>(I believe that most MS-DOS implementations
>have something similar to obtain the DOS file handle.  If MS-DOS and
>Unix do the same thing, then it *is* a standard, independantly of what
>ISO or ANSI decide...

You have a very novel view of language standardization.

Perhaps we should just disband X3J16 and SC22/WG14 now and simply arrange
a lunch meeting between Bill Gates and Ray Noorda (sp?), whereupon they
can sort out the remaining details of C++. :-)

(Follow-ups to comp.std.c++ please.)

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <2cbup3$qs8@jake.esu.edu> sherwood@esu.edu (Brian Sherwood) writes:
>Hello all,
>
>Technical note: Using g++ on a DECstation 5000 running ULTRIX 4.3
>
>A while ago I make a post asking how to do non/blocking IO in C++ using
>something equevilant to C's CBREAK mode.  Many people responded saying
>that I would do it the same way that I do it in C.  Thank you to
>everyone who responded, but I seem to be rather slow in understanding
>this, please forgive my stupidity.  I was under the impression that you
>should not mix C's stdin and C++'s cin.  Are you saying that I should
>do the following:
>
>   ioctl (fileno (stdin), TIOCGETP, &orig_modes);
>   new_modes = orig_modes;
>   new_modes.sg_flags |= CBREAK;
>   ioctl (fileno (stdin), TIOCSETP, &new_modes);
>
>and then use cin??

No.  You definitely should NOT try to apply the fileno() function to an
object of some C++ stream type (e.g. `cin').  You will probably get a
compile-time error if you do that.

You have raised what I think is an interesting question however.  How
does one go about applying these kinds of operations (e.g setting CBREAK)
to the underlying file-handle associated with a C++ stream?

Will there be a fileno() member function for the "standard" iostream class
so that you could say:

 ioctl (cin.fileno(), TIOCGETP, &orig_modes);

and/or:

 ioctl (cin.fileno(), TIOCSETP, &new_modes);

??

I (for one) don't know, because I haven't been following the evolution of
the stream classes within X3J16.  Perhaps Jerry Schwarz or some other member
of X3J16 will be good enough to answer this question.

(Follow-ups to comp.std.c++ please.)

--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCGsAEM.B5r@netcom.com>,
Ronald F. Guilmette <rfg@netcom.com> wrote:
>Will there be a fileno() member function for the "standard" iostream class
>so that you could say:
> ioctl (cin.fileno(), TIOCGETP, &orig_modes);
>and/or:
> ioctl (cin.fileno(), TIOCSETP, &new_modes);

I would be unpleasantly surprised if Standard C++ required any support
for UNIX-like integer file handles.  Standard C didn't (fileno(),
open(), close(), etc. are *not* ANSI C functions).

Jamshid Afshar
jamshid@ses.com