Re: Read a file line by line and write each line to a file based
on the 5th byte
* James Kanze:
On May 15, 3:21 pm, "Alf P. Steinbach" <al...@start.no> wrote:
However, I think that when the intention is to guarantee crash
behavior then it shouldn't be guaranteed via some implied
usage of proper compiler option and restriction to a compiler
that supports it.
And further, the possibility of having [] yield crash behavior
through some compiler specific means is really not an argument
in favor of [], since at least in principle the same can be
done for 'at'. It's not like compilers are somehow prevented
from offering non-conforming features such as crashing 'at',
and it's not like one is relying on the standard when
advocating []: one is then relying on very much in-practice
tool usage, not guaranteed anywhere. So just saying that [] is
preferable to 'at' is misleading because it compares a
/customized/ version of [] to the default 'at', while the
proper comparision is IMHO between either /default/ raw
indexing [] versus 'at', where 'at' wins handily wrt. to bug
detection, or between /customized/ [] versus customized 'at',
where there's no difference -- so, wrt. this, 'at' is either
better, or the same.
A compiler cannot crash if there is a bounds error in at(),
because the standard says exactly what it should do.
Re-quoting myself from above, "It's not like compilers are somehow prevented
from offering non-conforming features".
Consider for example the MSVC treatment of a "throw()" specification...
In short, when you're in compiler-specific land, that's where you are at. :-)
There are almost certainly programs which depend on it,
For those programs don't ask the compiler to use non-compliant crashing 'at'.
With separate programs, your example, it's simple.
However, with g++, how do you compile one part of the program with checking
behavior of [], when some other part is an object file or lib compiled with
non-checking []? This is a rhetorical question. It's my intention that instead
of answering the question literally (involving source code changes), you compare
it to your own argument regarding 'at', and note that for [] it's more serious.
Hence, above consideration combined with the apparent complete lack of compilers
that implement the crashing 'at' :-), plus the fact not all compilers in common
use support a range-checking [], e.g. note that MSVC 7.1 does not, my suggestion
of using an alternative notation, like some indexing routine or macro.
<example>
// This program intentionally has Undefined Behavior: arbitrary result or e.g. a
crash.
#include <iostream>
#include <string>
#include <stddef.h> // ptrdiff_t
#include <assert.h>
typedef ptrdiff_t Size;
typedef ptrdiff_t Index;
template< typename C >
Size nElements( C const& c ) { return c.size(); }
template< typename C >
typename C::value_type& operator^( C& c, Index i )
{
assert( 0 <= i && i < nElements( c ) );
return c[i];
}
template< typename C >
typename C::value_type const& operator^( C const& c, Index i )
{
assert( 0 <= i && i < nElements( c ) );
return c[i];
}
int main()
{
using namespace std;
string const s = "Blah blah...";
cout << "'" << (s^43) << "'" << endl;
}
</example>
Hm, I'd prefer @, as (I think) it is in Smalltalk, but no such in C++...
Also, the % operator has better precedence, but is less mnemonic/readable. And
there is the problem of a container with a value-producing []. That's a thorny
one, but it's late, and I leave the thinking to you (there must surely be a
practical solution, if not TMP auto-magic then just specialization).
But, anyway, for the novice I just recommend 'at', and I think it's a disservice
to them to recommend [] (even though it might in practice be the better choice
for the professional) because it's tool specific and not necessarily available.
and there are
probably a few cases where it is even a reasonable solution,
even if I've never seen them. (Jeff's use of at earlier in this
thread might actually be one, if the correct behavior if the
line is too short is to raise an exception---although more
likely, even in that case, you'd want some different exception.)
Finally, one's notational options are not limited to 'at' and
[], so playing the one against each other is a false
dichotomy.
If you're just using std::vector, those are really the only two
choices. (Unless you're using iterators, in which case, you'll
normally get the behavior of [].)
For example, where bounds checking with guaranteed crash is
desired, one might use a notation such as 'in(v,i)', or even
'v AT(i)', then *guaranteeing* the checking rather than
relying on unspecified compiler support and options.
My own experience would suggest that the exception is
appropriate rarely enough that there really isn't a need to
support it in the standard. In my pre-standard array classes,
there were two access functions: operator[] and unsafeAt. The
first was guaranteed to result in an assertion failure, and the
second resulted in truely undefined behavior. That was state of
the art in 1990, more or less. The standard library represents
state of the art ca. 1970. But we're stuck with it.
I agree with this. :-)
Cheers,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!