Re: [Boost-users] size_type doubts / integer library..

From: Lang Stefan (SLang_at_[hidden])
Date: 2008-08-18 12:55:53

-----Ursprüngliche Nachricht-----

On Mon, Aug 18, 2008 at 12:06:08PM +0200, Lang Stefan wrote:
> 
> > A) you intend to use your ID to later reference some address or offset 
> > (which is the same) in memory. If that is your intention, then you 
> > should stick to the size type (i. e. std:size_t). Problem solved.
> >
> Yes, it is used as an index into a vector.  And that's what I did (typedef vector<..>::size_type pin_id).

Well, then why don't you simply use std::size_t ? Yes, it's unsigned, and I agree with you it's not perfect (see below). But it will immediately rid you of all those nasty conversion warnings!

> Hm, do they?  Correct me if I'm wrong, but I don't think that C++ mandates flat address space -- it just
> requires that each individual object has a contiguous memory representation.  And there can be discrepancy
> between the two, e.g. 80286 protected mode: largest segment size is 64k, yet the largest amount of
> addressable memory is 16MB (or even in the range of TB if one allocates all LDTs and plays with swapping).  

Bugger, you're right, didn't think of that.

> So, size_type should be able to represent the size of a *single* largest representable object.  Why use it
> for e.g. number of elements in a vector?

That is something I did give some thought about in the past, to the point where I considered implementing my own set of container classes! However, I realized that in a sense, 'size_type' is indeed the correct type for an index. The reason behind it is this: an index type needs to be able to address a range of values that spans the minimum (0) and maximum (?) possible index for a container of some arbitrary type. For the STL, the smallest entity you can put inside a container is a single byte (disregarding bit-arrays). And the maximum number of such entities a container could legally contain would be limited by the amount of memory available divided by the size of the contained elements.

While, as you pointed out, there doesn't need to be a direct relation from index to memory address, the range an index type needs to cover is equal to the range a 'size_type' needs to cover. Moreover, at least on a small scope, every architecture I am aware of groups values of container elements into one or more chunks of memory, which in turn store adjacent values into adjacent memory slots. So at least on a local scale, index values do correspond to memory addresses or memory offsets.

> The "problem" could be solved by using largest _signed_ type both for size_type and difference_type.
[snip]
> So I'd advocate signed representation for size_type and difference_type.

I agree.

Stefan