On Monday, 22 July 2013 at 04:31:12 UTC, H. S. Teoh wrote:
On Mon, Jul 22, 2013 at 05:47:34AM +0200, JS wrote:
Doing simple stuff like
for(int i = 0; i < s.length - 1; i++) fails catastrophically
if s is
empty. To make right one has to reduce performance by writing
extra
checks.
I'm not sure if it's your intention, but your code above has an
off-by-1
error (unless you were planning on iterating over one less
element than
there are).
yeah, I know...
There seems to be no real good reason why size_t is unsigned...
[...]
The reason is because it must span the range of CPU-addressable
memory
addresses. Note that due to way virtual memory works, that may
have
nothing to do with the actual size of your data (e.g. on Linux,
it's
possible to allocate more memory than you actually have, as
long as you
don't actually use it all -- the kernel simply maps the
addresses in
your page tables into a single zeroed-out page, and marks it as
copy-on-write, so you can actually have an array bigger than
available
memory as long as most of the elements are binary zeroes
(though I don't
know if druntime currently actually supports such a thing)).
T
but a size has nothing to do with an address. Sure in x86 we may
need to allocate 3GB of data and this would require size_t > 2^31
==> it must be unsigned. But strings really don't need to have an
unsigned length. If you really need a string of length > size_t/2
then have the string type implement a different length property.
string s;
s.length <== a signed size_t
s.size <= an unsigned size_t
this way, for 99.99999999% of the cases where strings are
actually < 1/2 size_t, one doesn't have to waste cycles doing
extra comparing or typing extra code... or better, spending hours
looking for some obscure bug because one compared an int to a
uint and no warning was thrown.
Alternatively,
for(int i = 0; i < s.length - 1; i++) could at lease check for
underflow on the cmp and break the loop.
