In article <35095DBA.41C6@wizard.net>, kuyper@wizard.net says...
> Oleg Zabluda wrote:
> ...
>
> > ... Anyway, how else would you
> > make an errno-style error reporting mechanism in C, other then make
> > it a global variable? BTW, all(??) multithreaded environments,
> > provide one errno per thread. Otherwise it would be useless, of
> > course.
>
> Add an extra argument to each I/O function, which is the address of an
> errno variable allocated by the caller. A value of NULL would indicate
> that that there would be no error number reporting. In a C++
> environment, the default value for that argument could be &errno,
> retaining compatibility with the current interface.

I don't think it would be necessary to add it to all the I/O functions
- you should be able to add it in fopen for C and in the ctor and open
methods for streams.  From then on, the stream would store the address
of the variable, and update it as necessary, without other changes
being necessary.

This would remove one the advantages you cite: that of maintaining
different error numbers for different operations on the same stream to
figure out which operation failed.  However, I suspect this
possibility would rarely be put to use, so I'm not convinced that it
would be a tremendous loss.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote in message
<6ebggm$dsf$1@nnrp1.dejanews.com>...

>In general, functions returning a value should NOT have side
>effects.  But I've gotten used to writing procedures with a single
>return value as if they were functions, too.)


A provocative statement for a language like C or C++.  Certainly there are
languages where the compiler can assume that functions, as opposed to
procedures, have no side affects and return a result which depends only on
their arguments.  In some environments, I'm sure there are good reasons to
promote this as a style guide.

However for C or C++ this seems to be too far from "normal".  Examples of
functions with side effects which return values include rand, malloc/new,
ostream::op<<, auto_ptr::release, and a large fraction of <algorithm>.

If you restrict your definition of side effects to things other than
arguments, the list is smaller, but still significant.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6ejgl5$q3j$1@uuneo.neosoft.com>,
  "Bill Wade" <bill.wade@stoner.com> wrote:
>
> jkanze@otelo.ibmmail.com wrote in message
> <6ebggm$dsf$1@nnrp1.dejanews.com>...
>
> >In general, functions returning a value should NOT have side
> >effects.  But I've gotten used to writing procedures with a single
> >return value as if they were functions, too.)
>
> A provocative statement for a language like C or C++.

Agreed.  And it is really playing with words.  What is a function (as
compared with a procedure) in C/C++?

> Certainly there are
> languages where the compiler can assume that functions, as opposed to
> procedures, have no side affects and return a result which depends only on
> their arguments.  In some environments, I'm sure there are good reasons to
> promote this as a style guide.

I think it an essential guide even in C/C++, for an appropriate
definition of "function".  Note, for example, that I also wrote that I
write "procedures" with a  single out parameter "as if" they were
functions in C/C++:-).

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6e3q9d$18a6@r02n01.cac.psu.edu>,
  Oleg Zabluda <zabluda@math.psu.edu> wrote:
>
> jkanze@otelo.ibmmail.com wrote:
> : In article <3504A6CC.5F6A7BC@abraxis.com>,
> :   eddielee@abraxis.com wrote:
> : >
> : > All streams have member functions, inherited from ios, that you can use
to
> : > check for errors or success.
>
> : But they only indicate success or failure, and not why the operation
> : failed.
>
> : In the case of filebuf::open, for example, it is interesting to know
> : whether the open failed because the file didn't exist, or because you
> : didn't have access rights, or because there was a disk error when reading
> : the directory, or a time out on the connection to the file server, or
> : the given filename didn't have a legal syntax, or ...
>
> : Even when simply reading or writing, it is sometimes useful to know
> : whether a problem is do to a disk error, disk full, or a network timeout.
>
> : Of course, all of these possibilities are far to system specific to be
> : considered in the standard.
>
> In C, it was excellently done. Errors are too system specific.
> So, instead of standardizing them, they simply said that a library
> function is free to set errno to anything it likes (whether there
> was an error or not), provided the use of errno in this particular
> function is not documented in the standard (ANSI-C -- 7.1.4).
> Now, the simplest, portable, and often the most useful way to use
> this info is not directly, but through perror() or (to separate
> iostreams from stdio) strerror().

Well, I wouldn't call the use of a global variable "excellently done",
but I pretty much agree with the rest of your comments.

> I wonder, since the appropriate portions of ANSI C were
> referenced in C++ standard verbatim (19.3) does it mean that
> it applies to C++ library functions as well. I would guess
> yes.

It's likely the case in practice, anyway.

If I understand correctly, an implementation is also free to have
filebuf throw an arbitrary exception.  (How it is propagated depends
on istream and ostream.)  It might be a good idea for an implementation
to do this, with perhaps the results of strerror( errno ) as the string
returned from what.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote:
: In article <6e3q9d$18a6@r02n01.cac.psu.edu>,
:   Oleg Zabluda <zabluda@math.psu.edu> wrote:
: >
: > In C, it was excellently done. Errors are too system specific.
: > So, instead of standardizing them, they simply said that a library
: > function is free to set errno to anything it likes (whether there
: > was an error or not), provided the use of errno in this particular
: > function is not documented in the standard (ANSI-C -- 7.1.4).
: > Now, the simplest, portable, and often the most useful way to use
: > this info is not directly, but through perror() or (to separate
: > iostreams from stdio) strerror().

: Well, I wouldn't call the use of a global variable "excellently done",
: but I pretty much agree with the rest of your comments.

I think it is allowed that errno be a macro. For example, it could be

#define errno *ptr_to_real_errno

I am not sure why it would be better though, and I don't have the
ANSI C book here to look for clues. Anyway, how else would you
make an errno-style error reporting mechanism in C, other then make
it a global variable? BTW, all(??) multithreaded environments,
provide one errno per thread. Otherwise it would be useless, of
course.

: > I wonder, since the appropriate portions of ANSI C were
: > referenced in C++ standard verbatim (19.3) does it mean that
: > it applies to C++ library functions as well. I would guess
: > yes.

: It's likely the case in practice, anyway.

: If I understand correctly, an implementation is also free to have
: filebuf throw an arbitrary exception.  (How it is propagated depends
: on istream and ostream.)  It might be a good idea for an implementation
: to do this, with perhaps the results of strerror( errno ) as the string
: returned from what.

That would be great, and was my first wish when I thought
about that.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Oleg Zabluda <zabluda@math.psu.edu> wrote:
> : > In C, it was excellently done. Errors are too system specific.
> : > So, instead of standardizing them, they simply said that a library
> : > function is free to set errno to anything it likes (whether there
> : > was an error or not), provided the use of errno in this particular
> : > function is not documented in the standard (ANSI-C -- 7.1.4).

jkanze@otelo.ibmmail.com wrote:
> : Well, I wouldn't call the use of a global variable "excellently
> : done",
> : but I pretty much agree with the rest of your comments.

Oleg Zabluda wrote:
> I think it is allowed that errno be a macro. For example, it could be
>
> #define errno *ptr_to_real_errno
>
> I am not sure why it would be better though, and I don't have the
> ANSI C book here to look for clues.

Because, in a multithreaded environment, 'errno' must be specific
to each thread.  Consider the situtation when thread A calls fopen()
at the "same" time that thread B calls fread().  Each thread should
be able to discern the errno for its last library call and not
be confused by another thread's last call.  Thus, 'errno' can be
the result of a function call which finds the errno for the calling
thread:

    #define errno  (*_thread_local_errno())

Note that 'errno' is still an rvalue in this case.

> Anyway, how else would you
> make an errno-style error reporting mechanism in C, other then make
> it a global variable?

Since C doesn't have exceptions, there's very few alternatives left.
A well-designed global error code, such as 'errno', is actually
pretty useful in practice.

> BTW, all(??) multithreaded environments,
> provide one errno per thread. Otherwise it would be useless, of
> course.

Exactly.

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6e7peo$r8j@marianna.psu.edu>,
  zabluda@math.psu.edu (Oleg Zabluda) wrote:

> : Well, I wouldn't call the use of a global variable "excellently done"=
,
> : but I pretty much agree with the rest of your comments.
>
> I think it is allowed that errno be a macro. For example, it could be
>
> #define errno *ptr_to_real_errno

It may be a macro.  The resulting expression must evaluate to an lvalue
of type int.

> I am not sure why it would be better though, and I don't have the
> ANSI C book here to look for clues.

How about:

    #define errno (*_getThreadSpecificErrNo())

(where _getThreadSpecificErrNo() returns an int*).

> Anyway, how else would you
> make an errno-style error reporting mechanism in C, other then make
> it a global variable? BTW, all(??) multithreaded environments,
> provide one errno per thread. Otherwise it would be useless, of
> course.

It's still problematic.  You have to pay particular attention when using
it in an expression, for example, since something else in the expression
may modify it.  Consider:

    if ( someSystemFunction() !=3D OK )
        cerr << "Error in someSystemFunction: " << strerror( errno ) << '=
\n' ;

This DOESN'T work, since the first call to operator<< (outputting the
string) may modify errno.  Practically, you have to write:

    if ( someSystemFunction() !=3D OK )
    {
        int                 result( errno ) ;
        cerr << "..." << strerror( result ) << '\n' ;
    }

Note that the equivalent C expression:

    fprintf( stderr ,
             "Error in someSystemFunction: %s\n" ,
             strerror( errno ) ) ;

is safe.  But change it to the (more useful):

    fprintf( stderr ,
             gettext( "Error in someSystemFunction: %s\n" ) ,
             strerror( errno ) ) ;

and it is very likely to fail if the user has set LC_MESSAGES
incorrectly in his environment.

A more reasonable solution would have been for e.g. fopen to
return a struct FallibleFILEPtr, declared as follows:

    struct FallibleFILEPtr
    {
        int                 errorCode ;
        FILE*               filePtr ;
    } ;

Except, of course, that the interface to fopen was fixed long
before C allowed functions to return struct's.  (I'll admit that
the logical signature for fopen would have been:

    void fopen( char const* filename ,
                char const* mode ,      // Or flags, as in filebuf::open
                int*        status ,
                FILE**      result ) ;

In general, functions returning a value should NOT have side
effects.  But I've gotten used to writing procedures with a single
return value as if they were functions, too.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Oleg Zabluda wrote:
...

> ... Anyway, how else would you
> make an errno-style error reporting mechanism in C, other then make
> it a global variable? BTW, all(??) multithreaded environments,
> provide one errno per thread. Otherwise it would be useless, of
> course.

Add an extra argument to each I/O function, which is the address of an
errno variable allocated by the caller. A value of NULL would indicate
that that there would be no error number reporting. In a C++
environment, the default value for that argument could be &errno,
retaining compatibility with the current interface.

I'm not suggesting this change; I'm merely answering your 'how else'
question. However, it does have some advantages, in addition to
simplifying the application to multi-threaded environments.

With the current design, you must capture the value given to errno
before the next time you call a function that might set it. With a
pointer argument, you could maintain different errno's for several
different purposes, interleave calls which set each one, and defer
handling of the errors till later.

With the pointer interface, you could even combine multiple
errno-setting function calls in a single statement, and still be able to
disentangle which one(s) failed, and why. Doing that with the global
interface requires very complicated expressions, and very careful
attention to sequence points.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6e7peo$r8j@marianna.psu.edu>, zabluda@math.psu.edu says...

[ ... ]

> I think it is allowed that errno be a macro. For example, it could be
>
> #define errno *ptr_to_real_errno

Yes - the wording in the standard is that it "expands to a modifiable
lvalue".

> I am not sure why it would be better though, and I don't have the
> ANSI C book here to look for clues.

If memory serves, one of the ideas is to make life easier in
multithreaded programs -- it makes it easier to have a separate
variable for each thread, which as you observed is nearly necessary to
support multithreading.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote:
>
> Well, I wouldn't call the use of a global variable "excellently done",
> but I pretty much agree with the rest of your comments.

It makes multi-threaded stuff impossible. That's why the implementation
I'm familiar with (Borland) actually defines errno as a macro which
dereferences a pointer returned by a function call.

I rather wish the standard had defined the semantics for thread-local
stuff, to which all compilers that claim to support multi-threading
would have to adhere. After all, the exception handling mechanism needs
knowledge of the threading mechanism if they are to work properly, so
it's not as though this would impose some new burden on compiler
writers.

--

Ciao,
Paul
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi

I was just wondering if use of errno was the standard (and correct) way
to determine error information when using fstreams (or filebufs, to
be more exact)?

If so, then is there any sort of push to modify the standard to use
exceptions?  I/O errors are precisely the sort of thing that should
qualify as an exception in program execution, and it amazes me that
fstreams don't use exceptions.

Dylan

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6e05oa$ucn$1@nnrp1.dejanews.com>,
  Dylan Nicholson <dnich@noojee.com.au> wrote:

> I was just wondering if use of errno was the standard (and correct) way
> to determine error information when using fstreams (or filebufs, to
> be more exact)?

There is no standard (and correct) way to determine error information
when using fstreams.  OS's differ widely in the amount and type of
information they provide, so it is almost impossible to standardize
anything in this domain.  The best you can do is read your vendor's
documentation, and lobby him for something you can use.

> If so, then is there any sort of push to modify the standard to use
> exceptions?  I/O errors are precisely the sort of thing that should
> qualify as an exception in program execution, and it amazes me that
> fstreams don't use exceptions.

So make them exceptions.

A filebuf is perfectly free to report errors by exceptions (as far as I
know).

The standard requires the iostream to catch these exceptions, and to take
one of two actions, depending on the state of ios::badbit in the exceptio=
n
mask.  If the bit is set, it must rethrow the same exception; if it is
reset, it must set ios::badbit in the state mask and return.

It's up to you to decide whether you want errors reported by exceptions
or by return codes.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6e05oa$ucn$1@nnrp1.dejanews.com>,
Dylan Nicholson  <dnich@noojee.com.au> wrote:
>Hi
>
>I was just wondering if use of errno was the standard (and correct) way
>to determine error information when using fstreams (or filebufs, to
>be more exact)?

Exceptions do not provide enough information at present because of lack of
granularity and standardization.

>If so, then is there any sort of push to modify the standard to use
>exceptions?  I/O errors are precisely the sort of thing that should
>qualify as an exception in program execution, and it amazes me that
>fstreams don't use exceptions.

The G++ implementation which I use certainly raises exceptions.  I haven't
seen the official ANSI standard so I don't know what it says.
--
Jim Cobban   |  jcobban@nortel.ca                   |  Phone: (613) 763-8013
Nortel (MCS) |                                      |  FAX:   (613) 763-5199
|   "I am not a number.  I am a human being!"
| P. McGoohan, "The Prisoner"
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

All streams have member functions, inherited from ios, that you can use to
check for errors or success.

Dylan Nicholson wrote:

> I was just wondering if use of errno was the standard (and correct) way
> to determine error information when using fstreams (or filebufs, to
> be more exact)?
>
> If so, then is there any sort of push to modify the standard to use
> exceptions?  I/O errors are precisely the sort of thing that should
> qualify as an exception in program execution, and it amazes me that
> fstreams don't use exceptions.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3504A6CC.5F6A7BC@abraxis.com>,
  eddielee@abraxis.com wrote:
>
> All streams have member functions, inherited from ios, that you can use to
> check for errors or success.

But they only indicate success or failure, and not why the operation
failed.

In the case of filebuf::open, for example, it is interesting to know
whether the open failed because the file didn't exist, or because you
didn't have access rights, or because there was a disk error when reading
the directory, or a time out on the connection to the file server, or
the given filename didn't have a legal syntax, or ...

Even when simply reading or writing, it is sometimes useful to know
whether a problem is do to a disk error, disk full, or a network timeout.

Of course, all of these possibilities are far to system specific to be
considered in the standard.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote:
: In article <3504A6CC.5F6A7BC@abraxis.com>,
:   eddielee@abraxis.com wrote:
: >
: > All streams have member functions, inherited from ios, that you can use to
: > check for errors or success.

: But they only indicate success or failure, and not why the operation
: failed.

: In the case of filebuf::open, for example, it is interesting to know
: whether the open failed because the file didn't exist, or because you
: didn't have access rights, or because there was a disk error when reading
: the directory, or a time out on the connection to the file server, or
: the given filename didn't have a legal syntax, or ...

: Even when simply reading or writing, it is sometimes useful to know
: whether a problem is do to a disk error, disk full, or a network timeout.

: Of course, all of these possibilities are far to system specific to be
: considered in the standard.


In C, it was excellently done. Errors are too system specific.
So, instead of standardizing them, they simply said that a library
function is free to set errno to anything it likes (whether there
was an error or not), provided the use of errno in this particular
function is not documented in the standard (ANSI-C -- 7.1.4).
Now, the simplest, portable, and often the most useful way to use
this info is not directly, but through perror() or (to separate
iostreams from stdio) strerror().

I wonder, since the appropriate portions of ANSI C were
referenced in C++ standard verbatim (19.3) does it mean that
it applies to C++ library functions as well. I would guess
yes.


Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]