Re: More concise syntax for addressing std::vector* ???
In article <-4CdnUQOEOxFpVvUnZ2dnUVZ_h6WnZ2d@giganews.com>,
Peter Olcott <NoSpam@SeeScreen.com> wrote:
"blargg" <blargg.ei3@gishpuppy.com> wrote in message
news:blargg.ei3-49E50F.21571821032009@sn-ip.vsrv-sjc.supernews.net...
Peter Olcott wrote:
"Juha Nieminen" <nospam@thanks.invalid> wrote in message
news:_c7xl.105$Q%4.94@read4.inet.fi...
Balog Pal wrote:
But if you actually want it like that, just use at()
instead of []
As a bonus, you'll get boundary checks. (May be just
slightly slower, but that's often irrelevant unless
you need to index the vector millions of times per
second.)
Yes, that is not too bad, but, I want to handle boundary
checks myself. The C++ exception handling infrastructure
^^^
Your compiler's
most likely has much more overhead than I want to pay
for,
"most likely" would indicate that you have not checked but you are
guessing on prejudices.
It does not I examined the generated assembly language, and
ran some benchmark testing.
Ah, so you did some testing. But did you benchmark your application
or a little irrelevant code sample comparing exclusively one throw to
one if() ? If the later, obviously a try-throw-catch is a lot more
expensive than a if. However, typical exception using code use a lot
lot less try-throw-catch than typical return code based code.
You should not compare:
for(int i = 0; i < 1000000 ; ++i)
{
if(foo())
;
}
to
for(int i = 0; i < 1000000 ; ++i)
{
try
{
foo();
}
catch(...) {};
}
but to:
try
{
for(int i = 0; i < 1000000 ; ++i)
foo();
}
catch(...) {};
Fixed that for you. The only overhead you'll almost
definitely get with
at() is the range checks (so a compare and branch around
the code that
throws the exception).
No that is not it. I am always doing the range checks
myself, so if C++ is doing them too, it is wasting time.
Also It is not the overhead of the C++ range checks that is
far too expensive, it is the overhead of the case when an
out-of-bounds exception is thrown that is too expensive.
This is most likely far more expensive than a text output
call.
But the exception due to an out-of-bound situation should be
exceptional. Error path cost should not be your main priority since
it should only happen exceptionally rarely when something went
exceptionally wrong. If it is a "normal" situation that an
out-of-bound exception gets thrown, then you have a design issue.
But I still agree; the goal was code that did the same
thing, not code
that added in range checks.