Re: Read a file line by line and write each line to a file based on
the 5th byte
On May 15, 3:21 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Juha Nieminen:
Alf P. Steinbach wrote:
I think you should be clear that what you're advocating is
not using operator[] instead of at, but using a checking
version of operator[].
Which is precisely what at() does...
Sorry, no.
'at' is restricted in how it reports a bounds error, namely
via an exception, while operator[] is not so restricted. So
when we're talking about 'at' we're talking by default about
the reporting mechanism (exception) mandated by the standard.
While when we're talking about a checking [], then we're
necessarily talking about some compiler-specific reporting
mechanism, typically a crash.
And James' point is (presumably) that he prefers an invalid
index to assert() or always do the crash thing (*nix core dump
or Windows JIT debugging), rather than throwing an exception
-- because an invalid index indicates a bug, unlike e.g. the
exhaustion of some dynamic resource. Of course, countering
that, the standard's exception class hierarchy does have an
exception class dedicated to logic errors. But AFAIK very few
regard that hierarchy as a good design...
Exactly.
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. There are
almost certainly programs which depend on it, 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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34