Re: Read a file line by line and write each line to a file based
on the 5th byte
* 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...
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.
Finally, one's notational options are not limited to 'at' and [], so playing the
one against each other is a false dichotomy.
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.
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!