Is there a way of making a std::vector, or indeed any other std
container that is indexed by something larger than a 'size_t' i.e. an
unsigned long.

Thanks,
Jon Rea

Jon Rea schreef:

Is there a way of making a std::vector, or indeed any other std
container that is indexed by something larger than a 'size_t' i.e. an
unsigned long.

Probably not. A vector<Tmust hold a T[]. That T[] is an object, with
a size,
and that size must be represented as a size_t. std::deque might work,
though.
But really, who cares? 64 bit systems typically have 64 bits size_t's

HTH,
Michiel Salters

Jon Rea wrote:

Is there a way of making a std::vector, or indeed any other std
container that is indexed by something larger than a 'size_t' i.e. an
unsigned long.

As a matter of interest - if we have a vector<char>, that would mean it
would contain (2^32) - 1 bytes, right. On a 32 bit system (like WIN32),
is it at all possible to reference memory at that kind of address? For
instance, what if I have more RAM than addressable. Does it go to
waste?

Regards,

Werner

Jon Rea wrote:

Is there a way of making a std::vector, or indeed any other std
container that is indexed by something larger than a 'size_t' i.e. an
unsigned long.
...

Firstly, 'size_t' is not necessarily 'unsigned long'. 'size_t' is
traditionally derived from addressing parameters of the underlying
hardware/OS platform and, sometimes, from compiler settings ("memory
model" and such).

Secondly, with other std containers there's absolutely no reason to
limit their capacity by 'size_t'. So the answer is - definitely yes.
However, it is rather strange to hear the term "indexed" applied to
those containers. They don't naturally support random access by index
(except, maybe, 'std::deque'), although it can always be [inefficiently]
emulated through sequential access ('std::advance').

With 'std::vector' it is possible (I don't see anything that would
explicitly prohibit that in the language specification). But, assuming
that 'size_t' is chosen in accordance with the "traditional" approach,
it is more difficult to implement and often bears certain performance
penalty.

--
Best regards,
Andrey Tarasevich