[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] std::vector::at() in group-quote code
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] std::vector::at() in group-quote code |
Date: |
Fri, 13 May 2016 15:51:30 +0200 |
On Fri, 13 May 2016 13:27:22 +0000 Greg Chicares <address@hidden> wrote:
GC> Vadim--I notice that you've used std::vector::at() throughout the
GC> group-quote code in preference to operator[](). Is that because
GC>
GC> (1) it provides extra safety at an incremental cost that is negligible
GC> in the context of generating PDF files, or
Yes. However I am consciously trying to change my thinking from "at()
provides extra safety" to "operator[] is unsafe and should be only used
where the performance is absolutely critical", so, after making one too
many mistake (not in lmi, please be reassured) with indices and not finding
it immediately because of the use of operator[], I've decided to always use
at() and only switch to operator[] if justified by profiling.
In C++98 I still can't quite prevent myself from using operator[] in the
completely trivial loops, e.g.
for(size_t n = 0; n < vec.size(); ++n)
{
... use vec[n] ...
}
but in C++11 even this is not necessary as you can/should just write
for(auto const& x: vec)
{
... use x ...
}
instead.
GC> (2) it actually costs nothing (when it doesn't throw) with a modern
GC> compiler such as we're using, even on msw with sjlj semantics?
I can't say it doesn't cost anything, just the extra check does make a
difference and, of course, SJLJ still adds some cost even when exceptions
are not thrown, unfortunately, nothing is going to change this (except
switching to a completely different exception handling implementation). But
I'm pretty sure this cost is completely negligible in the PDF generation
code and, again, I try to force myself to do profiling and compare the
results with at() and with operator[] and see if I can see any difference
before replacing the former with the latter.
Regards,
VZ