Re: What is the correct behaviour?
Alf P. Steinbach wrote:
* James Kanze:
Alf P. Steinbach wrote:
But surely it never was the intention that a C++ standard library
stream, providing strong typing for novices, should successfully
produce
ULONG_MAX+1-432 for input "-432"?
If it was then the streams are IMO even more than triple-ungood, not
just inadvertently complex, cryptic, error-prone, limited, and
inefficient, but by design delivering unusable, unexpected results...
I see you've never used C I/O. Speak about cryptic, error-prone
and limited.
When I think of C i/o I think of 'creat', the biggest mistake in the
design of original Unix (namely, "I'd spell creat with an e"),
I think that was meant to be a joke. I can't imagine anyone
being that arrogant.
and the
slow-reader program for Deep Blue. Something bad happened during
standardization of C: the standardized functionality isn't the de facto
real & useful one.
Well, the de facto real and useful one was subtly different
between Unix and CP/M. Also, the de facto real and useful one
was only really usable at the lowest level, and couldn't
possibly be ported to mainframes of the day (and of today). The
problem is that at that level, you really are OS dependant.
And something bad happened during standardization of
C++, but since C only allows you to inadvertently shoot yourself in the
foot, while C++ allows you to inadvertently level a whole city block,
that something bad that happened for C++ was orders of magnitude worse.
In medium-short, it seems to me that the Wanton Abstractionists and
Generalizationists won, for languages meant for serious systems-level
programming where one needs control, with the result that the
standardized i/o functionality for C is handicapped (thus, Posix) and
for C++ lobotomized while in either case not being any more portable,
and actually just as system-dependent as it would have been with a more
complete, less over-abstracted and actually useful toolset.
Just my humble opinion, of course.
I'd partially agree.
The problem is that one size doesn't fit all, and trying to make
all possible I/O abstractions fit into one model is doomed to
failure. The C++ I/O streams are an excellent abstraction for
streamed text input and output, but the functionality necessary
for things like seeking, bi-directional I/O, binary I/O, etc. is
a hack, more tacked on than part of the basic abstraction, and
not very easily used.
Posix is NOT an alternative, even on Posix systems. Posix is
(intentionally) a much, much lower level abstraction. It is
something to build on---when I need an I/O abstraction other
than streamed text, I write my own, building on Posix. (But of
course, I don't have to be 100% portable. As far as my customer
is concerned, if it runs under Solaris, it's fine, and if it
also runs under Linux, we can consider it "portable".)
[snip]
Of course, a perhaps even simpler solution would be to modify
stage 2 in ?22.2.2.1.2/3 to remove + and - from the list of
atoms if the target type is unsigned. This would at least
eliminate the ambiguity concerning negative unsigned values.
That sounds like a kludge, chewing-gum and elastic bands applied to stop
the rattling in one special case, instead of a general solution.
It is a kludge. (Although I think you also suggested, in
another posting, that we shouldn't accept a - sign if we were
inputting to an unsigned type.) However, if we suppose the TR
results in requiring failbit to be set if the converted value
isn't representable, it sounds like the smallest modification of
the standard which would define a reasonable behavior for
unsigned values. And I don't think that the committee is in a
mood to rewrite all of the specifications for numeric
conversions for the next release of the standard. (The goal is
for it to be C++0x, and given the bookkeeping overhead necessary
between the final draft and the standard itself, I think this
means only two or three more meetings to finalize all of the
wording. And a lot of very interesting and useful proposals are
still very far from a first draft of the wording in the
standard.)
I remember when I once jokingly remarked -- was it here? -- that we
ditch the whole standard library except the original STL parts (which
weren't even an original basis but added in quite late, IIRC).
Why caution the STL parts? They don't work very well in
application code, and are certainly more poorly designed than
iostream.
I think that there is a problem in general with the library, in
that it does try to be all things to all people. The more I
think of it, the more I think that maybe we need several
different standard libraries (in different namespaces?) for
different levels: what is good for an applications programmer
isn't necessarily good for someone working at the lower levels.
Having a general facility for streamed text I/O, for example, is
considered almost essential for an application programmer, but
that facility doesn't lend itself at all to being a base for
building up other abstractions.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]