Re: behaviour of vector<T>::operator[]
- From: "Gene Bushuyev" <spam@xxxxxxxxxxxxx>
- Date: Tue, 06 Sep 2005 21:59:49 GMT
"Jason Winnebeck" <gillius-ng@xxxxxxxxxxxxxxxxxx> wrote in message
news:%237ivQtxsFHA.2592@xxxxxxxxxxxxxxxxxxxxxxx
>I would think that the point of the question is to see what you can do
>simply. I would imagine that writing a function to do this and the
>technical ability to do this is not out of the question for the original
>poster.
>
> One of the points of using [] over .at is that it is more intuitive and
> (IMO) readable than .at. Also, using [] might be important for generic
> programming. That said, I'm not sure a non-standard (to other programmers
> reading the code ) macro or a templated function is a good solution. To
> me, "mydata[5]" is OK, but "At( mydata, 5 )" looks too unintuitive when
> the only benefit of the non-cannonical code is bounds checking in debug
> mode.
Of course, that's not the only solution. You can always use some form of
assert to check the precondition. In fact, you probably wouldn't like error
message at() function is throwing anyway. It varies from implementation to
implementation, but generally what() function I've seen returned just
"vector" with no more information. So even for this reason most people will
avoid at(), resorting to their own checks. Moreover for debug purposes, you
don't want the exception that at() throws, you need some form of assert that
aborts your program right where the bug is and doesn't unwind the stack.
>
> I'm guessing the right solution is what Plauger said was going into
> Whidbey. I applaud MS and/or the library writer(s) as appropriate for
> doing things because I have been wishing for that feature for quite awhile
> myself.
I am not that sure. Firstly, as I mentioned above, debug checks should not
be based on exceptions. Secondly, I for example, rarely use debug build for
debugging because it's impractically slow. I'd rather do a release build
without optimizations or select optimizations in some places. In many cases
I need to run the code at full throttle, having only few places checked.
What I think we need is a checked implementation of the standard library,
that would allow a degree of flexibility of turning on and off certain
checks in certain places using some sort of asserts, not exceptions.
- gene
.
- Follow-Ups:
- Re: behaviour of vector<T>::operator[]
- From: Sean Connery
- Re: behaviour of vector<T>::operator[]
- References:
- behaviour of vector<T>::operator[]
- From: Sean Connery
- Re: behaviour of vector<T>::operator[]
- From: Gene Bushuyev
- Re: behaviour of vector<T>::operator[]
- From: Jason Winnebeck
- behaviour of vector<T>::operator[]
- Prev by Date: Re: behaviour of vector<T>::operator[]
- Next by Date: Re: behaviour of vector<T>::operator[]
- Previous by thread: Re: behaviour of vector<T>::operator[]
- Next by thread: Re: behaviour of vector<T>::operator[]
- Index(es):
Relevant Pages
|
Loading