Back to comp.std.c++...

In article <9333415.27868@mulga.cs.mu.oz.au>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>kanze@us-es.sel.de (James Kanze) writes:
>>rfg@netcom.com (Ronald F. Guilmette) writes:
>>|> It would be a real pity if anything about the fundamental design of
>>|> C++ iostreams made it either difficult, or inefficient, or impossible
>>|> to perform (admittedly extra-standard) operations such as setting CBREAK
>>|> mode on an iostream.

Btw, I don't know much about curses (I believe that is what cbreak()
is related to), but curses seems like a good candidate for a C++ class
wrapper.  Borland provides <constream.h> which defines a
iostream-derived class with extra member functions like gotoxy(),
setcolor(), etc.

>>I don't think that there is anything in the fundamental design of
>>iostream's which make this difficult or even inefficient.
>>In fact, Cfront already allows this (although I don't know how
>>efficient it is).  And in this regard, at least, there is nothing in
>>the Cfront implementation that would prevent it from conforming to the
>>upcoming standard.
>The same is also true of the GNU C++ Library (LIBG++),
>which just like Cfront provides a filebuf::fd() member function.

Actually, are ya'll sure this will be legal?  I don't believe it's
legal for an ANSI C compiler to declare fileno() in <stdio.h> or even
use the identifier "fileno" as a parameter in a <stdio.h> function
declaration.  That identifier is in the user's namespace and the user
might #define or declare "fileno" before or after including <stdio.h>.

 #include <stdio.h>
 FILE* fileno() { return fopen("no", "r"); } // legal

I believe the same requirement should apply to <iostream.h>.  What if
the user #define's "fd" to some expression?  That would result in a
compiler error when including GNU's or Cfront's <iostream.h>.

Hopefully Standard C++ will, like Standard C, define not only what
identifiers a standard header can and must use, but what identifiers a
header CANNOT use.  The state of UNIX header files was one of the
biggest shocks when I moved from the the DOS/Windows to UNIX.  I was
accustomed to relatively clean and complete (ANSI C-wise) header
files, at least when compiling in strict ANSI C mode.  Of course, this
was probably possible because one vendor distributed both the C/C++
compiler and the library.

ANSI/ISO may decide that because of C++'s better scoping, namespaces,
and the deprecation of macros, standard headers will be allowed to use
any identifiers they want, as long as such use does not interfere with
the user's declaration of that identifier as anything but a macro.
Otherwise, filebuf::fd() should be renamed to filebuf::__fd().  An
inline function "int filebuf::fd() { return __fd(); }" can be declared
when not compiling in strict ANSI mode.  Or, a new header like
<unixstream.h> (which is a user-defined header in the eyes of the
standard) can be provided which defines:

 int fileno(filebuf* f) { return f.__fd(); }

Jamshid Afshar
jamshid@ses.com

In article <CHH68H.ADt@ses.com> jamshid@castro.uucp (Jamshid Afshar) writes:
>Back to comp.std.c++...
>
>
>Hopefully Standard C++ will, like Standard C, define not only what
>identifiers a standard header can and must use, but what identifiers a
>header CANNOT use.  The state of UNIX header files was one of the
[]
>
>ANSI/ISO may decide that because of C++'s better scoping, namespaces,
>and the deprecation of macros, standard headers will be allowed to use

The library working group is putting the whole standard library
in namespaces .. including the C library.

In effect that means that one identifier is reserved
by the library, probably "std" or "iso" or something.

All the other names will now be available to the user,
provided of course you dont try to define say "memcpy"
in the namespace its already defined in.

None of this applies to macros, however, but they aren't really
part of the language proper. (Boy, I'd sure like to deprecate
that stupid preprocessor  :-)


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA