Re: Is the 'as if' rule appliable here? (A reawakening)
Gennaro Prota schrieb:
Thanks for the reawakening :-)
When I wrote this reply I considered for a while to
replace "reawakening" by "resurrection", which would
better fit into the current time (although ~one week too
early), but thematically worse ;-)
One clarification: my original post
question was intended as "shall we necessarily use a string?", not
exactly as "is this specific implementation conforming?"
Sorry, but from both your response and the contents of
the older reference I could not see this intend.
Basically, I think that if a string is required then the extractor is
over-specified.
I agree, although I cannot surely decide whether the current
wordings demand that. This would lead us to the definition
and conformance against as-if again.
But, as you say too, one could use a built-in array, or another
bitset object, and (what I meant to be) the main question --"is
it ok to avoid using a string?"-- would remain.
From my view-point a well-written replacement using e.g.
a C array of fixed length would be sufficient to provide this
guarantee. The tricky point might be the situation of too
little free store, where an bad_alloc is thrown. E.g. can we
interpret the note given in 1.9
"For instance, an actual implementation need not evaluate
part of an expression if it can deduce that its value is not
used and that no side effects affecting the observable behavior
of the program are produced."
that every expression involving new/delete (in which hidden
way ever) *must* necessarily have observable side-effects
and that this means that we cannot replace them by
alternative options?
Viewing from the point of a global memory provider (new/delete)
this assumption applies.
But the standard often provides unexpected rear exits, e.g.
in the section about temporaries:
"Even when the creation of the temporary object is avoided
(12.8), all the semantic restrictions must be respected as if
the temporary object had been created."
Maybe a really *good* language lawyer can conclude from
this that it is possible to write the currently specified IO
extraction of bitset without a basic_string?
Personally I would say - although not granted by the
standard - that most resource limitations shouldn't be
included in the as-if rules. Here an artifical example: The
standard often writes some as-if code, which no
programmer would probably write, e.g. from stage 2 of
22.2.2.1.2:
"if ( ct == use_facet<numpunct<charT> >(loc ).decimal_point() )
c = '.';
bool discard =
( ct == use_facet<numpunct<charT> >(loc ).thousands_sep()
&&
use_facet<numpunct<charT> >(loc ).grouping().length() != 0 );"
Consider a reference-counter-like facet system as described
in 22.1.1.1.2/2. Theoretically I can write a program, which
systematically calls use_facet<numpunct<charT> >(loc ),
lets say std::numeric_limits<size_t>::max() - 2 times. The
following invokation of the above code, as written, would
lead to a welldefined unsigned overflow and can probably
have some funny effects on the lifetime management of the
facets. Does this mean that I'm not allowed to shorten the
above code using only *one* call to use_facet<numpunct<
charT> >(loc ), because that would possibly change side-
effects? Surely not.
IIRC, at the time I wrote the post I was
working on the inserters and extractors of boost::dynamic_bitset; I've
always been bothered by the coupling of std::bitset with
std::basic_string and I'd have liked dynamic_bitset not to go through
the same route. Alas, that has been a lost battle; apparently I was
also completely impotent against this:
<http://groups.google.com/group/comp.std.c++/browse_frm/thread/188ddd204ebd67da/739035f50ae29ab8>
It depends on the view point, whether a battle has lost
here or not. It's rather obvious that there exists several
nastinesses with current binding between bitset and
string. Although closed as NAD the following report
points out similar problems with std::string and bitset:
http://www2.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#116
And the pure fact, that
http://www2.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#396
does still exists, is a sign that bitset IO is still an
active area. But I have to agree with Martin Sebor,
speaking in your "battle thread" - this not meant as
an attack ;-) - that we have to life with most currently
existing "features" like to_string from bitset.
Best is: Don't use it, if you don't have to. It would be
nice, if a standard *alternative* would be provided, but
the committee will never *replace* it by such thingee.
IMO its not sufficient to argue with "unwanted coupling"
here, because - as James Kanze recently said - there
also exists pro-arguments for using std::string in the
interface of other standard library components.
One of the lessons I learned from this discussion is,
that the bitset-string-connection is maybe a good
example, where *too early* and *too much* was done
in the first try. It's not so easy, to decide, what to leave
and what to use. Similarily std::exception's will now
have *additional* const char* c'tors parallel to those
taking std::string, and filestream will now have
*additional* std::string c'tors parallel to const char*.
My point wasn't performance, though.
But this is a reasonable argument, here, too,
especially if we consider that bitset is actually a
similarily lightweight replacement for enumerations
(sort-of).
It was about avoiding coupling to
the unnecessary (and IMHO, totally unrelated, abstraction-wise) string
facility. I suspected that, given that basic_string was already
required by other bitset parts, the committee found it convenient to
express the extractor requirements in terms of it, though nobody meant
that basic_string had to be used necessarily. That's why I asked.
I understand that now and I also agree that
that the already existing string-bitset connection
probably lead to the "natural" solution to define
the IO insertion and extraction in terms of a
bitset-string transformation, but I'm not yet
conveniced that the current words would not
allow an alternative non-string transformation.
Greetings from Bremen,
Daniel
---
[ 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.comeaucomputing.com/csc/faq.html ]