473,326 Members | 2,048 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

size_t and size_type

What is the difference between size_t and vector<T>::size_type?

Are they ever a different type or a different size?

Why should one type the latter when the former is shorter?

What about the size_type type in other STL classes?

--
Regards, Grumble

Jul 22 '05 #1
10 8565
On Thu, 01 Apr 2004 16:17:54 +0200, Grumble <in*****@kma.eu.org> wrote:
What is the difference between size_t and vector<T>::size_type?
This should really be in the FAQ.

Bottom line: /probably/ none. The Standard explicitly allows container
implementors to assume that the allocators they're handed (from which the
size_type typedef may be propagated to the clients of the container,
although I have library implementations that just hard-wire size_t for the
container typedefs) define size_type as size_t. Extensions are also
permitted (see 20.1.5/4).

Are they ever a different type or a different size?
If there are any such implementations, I don't know about them yet.

Why should one type the latter when the former is shorter?
Either they were thinking ahead to some scenario when containers' memory
would come from some heap with totally different rules of memory management
that needed its own unique size_type, or else this is just an artifact of
the Intel segmented architecture memory-model that influenced the creation
of allocators in the first place. Who knows...

What about the size_type type in other STL classes?


Same deal, AFAIK.
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Jul 22 '05 #2
Grumble wrote:

What is the difference between size_t and vector<T>::size_type?

Are they ever a different type or a different size?

Why should one type the latter when the former is shorter?

What about the size_type type in other STL classes?

--
Regards, Grumble

vector<T>::size_type is implementation-defined. The same holds for the
other standard containers. Generally, you cannot rely on it being size_t.
I've seen it defined (most commonly) as
typedef size_t size_type;

as well as
typedef _Allocator::size_type size_type;

where _Allocator was the container's allocator template parameter.
In the latter case you could actually end up getting it defined differently from
size_t (though the standard allocator defines size_type as size_t, there is no such
requirement for custom allocators).

I think you are better off using generic definitions (such as Container::size_type)
in generic code anyway, it makes it more generic (sorry for the wording).

Denis
Jul 22 '05 #3

"Denis Remezov" <de*********************@yahoo.ca.removethis> wrote in
message news:40***************@yahoo.ca.removethis...
Grumble wrote:

What is the difference between size_t and vector<T>::size_type?

Are they ever a different type or a different size?

Why should one type the latter when the former is shorter?

What about the size_type type in other STL classes?

--
Regards, Grumble

vector<T>::size_type is implementation-defined. The same holds for the
other standard containers. Generally, you cannot rely on it being size_t.


Actually no, vector<T>::size_type uses the standard allocator, so its
size_type must be size_t.

But things get interesting when we consider custom allocators. Then you are
right that you cannot assume that vector<T, some_allocator>::size_type is
size_t. However the C++ standard explicitly gives permission of
implementations of the standard library to assume that vector<T,
some_allocator>::size_type is size_t (same goes for all the other
containers).

In other words you cannot pass an allocator to a standard library container
type that uses a size_type different from size_t and expect it to work.

I imagine that this strange get out clause for the standard library
implementors was so that existing implementations were not invalidated (but
that's only a guess).

john
Jul 22 '05 #4
John Harrison wrote:

"Denis Remezov" <de*********************@yahoo.ca.removethis> wrote in
message news:40***************@yahoo.ca.removethis...
Grumble wrote:

What is the difference between size_t and vector<T>::size_type?

Are they ever a different type or a different size?

Why should one type the latter when the former is shorter?

What about the size_type type in other STL classes?

--
Regards, Grumble

vector<T>::size_type is implementation-defined. The same holds for the
other standard containers. Generally, you cannot rely on it being size_t.


Actually no, vector<T>::size_type uses the standard allocator, so its
size_type must be size_t.


You are right, I wasn't pying attention to the notation (vector<T> assumes
the standard allocator).
But things get interesting when we consider custom allocators. Then you are
right that you cannot assume that vector<T, some_allocator>::size_type is
size_t. However the C++ standard explicitly gives permission of
implementations of the standard library to assume that vector<T,
some_allocator>::size_type is size_t (same goes for all the other
containers).

In other words you cannot pass an allocator to a standard library container
type that uses a size_type different from size_t and expect it to work.


Now that you've pointed that out I went back to the Standard and found clause
20.1.5.4. Amongst other things, it says that allocators for the _standard_
containers are required to define size_type as size_t. So I was wrong,
and you can assume size_type is size_t.
Denis
Jul 22 '05 #5
>
Now that you've pointed that out I went back to the Standard and found clause 20.1.5.4. Amongst other things, it says that allocators for the _standard_ containers are required to define size_type as size_t. So I was wrong,
and you can assume size_type is size_t.


Perhaps the language isn't the best but that's not how I read it.

To me 20.1.5.4 says

Implementers of containers ... are permitted to assume ... that the typedef
member ... size_type is required to be size_t.

In other words implementers of the standard library are permitted to make
the requirement, but the standard itself is not making that requirement.

At least that's how I read it.

john
Jul 22 '05 #6
* "John Harrison" <jo*************@hotmail.com> schriebt:

Now that you've pointed that out I went back to the Standard and found

clause
20.1.5.4. Amongst other things, it says that allocators for the

_standard_
containers are required to define size_type as size_t. So I was wrong,
and you can assume size_type is size_t.


Perhaps the language isn't the best but that's not how I read it.

To me 20.1.5.4 says

Implementers of containers ... are permitted to assume ... that the typedef
member ... size_type is required to be size_t.

In other words implementers of the standard library are permitted to make
the requirement, but the standard itself is not making that requirement.

At least that's how I read it.

Statically assert that the type is size_t and be done with it -- simply
adding the requirement that the *¤/&#&! standard lacks.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #7
Denis Remezov wrote:

John Harrison wrote:

"Denis Remezov" <de*********************@yahoo.ca.removethis> wrote in
message news:40***************@yahoo.ca.removethis...
Grumble wrote:
>
> What is the difference between size_t and vector<T>::size_type?
>
> Are they ever a different type or a different size?
>
> Why should one type the latter when the former is shorter?
>
> What about the size_type type in other STL classes?
>
> --
> Regards, Grumble
vector<T>::size_type is implementation-defined. The same holds for the
other standard containers. Generally, you cannot rely on it being size_t.


Actually no, vector<T>::size_type uses the standard allocator, so its
size_type must be size_t.


You are right, I wasn't pying attention to the notation (vector<T> assumes
the standard allocator).
But things get interesting when we consider custom allocators. Then you are
right that you cannot assume that vector<T, some_allocator>::size_type is
size_t. However the C++ standard explicitly gives permission of
implementations of the standard library to assume that vector<T,
some_allocator>::size_type is size_t (same goes for all the other
containers).

In other words you cannot pass an allocator to a standard library container
type that uses a size_type different from size_t and expect it to work.


Now that you've pointed that out I went back to the Standard and found clause
20.1.5.4. Amongst other things, it says that allocators for the _standard_
containers are required to define size_type as size_t. So I was wrong,
and you can assume size_type is size_t.

Denis


However, on yet another thought, are the standard containers required to
define size_type as any specific type, either directly or through their
allocators? If not (I couldn't find anything to that effect) then
StdContainer::size_type is still implementation-defined (at least in theory).

Denis
Jul 22 '05 #8
Grumble wrote:
What is the difference between size_t and vector<T>::size_type?

Are they ever a different type or a different size?

Why should one type the latter when the former is shorter?

What about the size_type type in other STL classes?

Use typename Container::size_type in generic code, even when Container
happens to be an instantiation of the vector class template. This will
help you can switch container types without too much pain. I speak from
experience.
Jul 22 '05 #9
Leor Zolman wrote:

Either they were thinking ahead to some scenario when containers' memory
would come from some heap with totally different rules of memory management
that needed its own unique size_type, or else this is just an artifact of
the Intel segmented architecture memory-model that influenced the creation
of allocators in the first place. Who knows...


I do. <g> If you have ancient copies of the STL documentation from HP,
you'll see my name listed as one of the contributors. That's because I
"fixed" a problem that Alex Stepanov and Meng Lee had in specifying
allocators. They were dealing specifically with the Intel architecture,
but that was just a particular instance of a more general problem. So
the true answer is that both of your alternatives are correct: size_type
is there for the Intel segmented architecture in particular, and for
alternative memory managers in general.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 22 '05 #10
Leor Zolman wrote:

Either they were thinking ahead to some scenario when containers' memory
would come from some heap with totally different rules of memory management
that needed its own unique size_type, or else this is just an artifact of
the Intel segmented architecture memory-model that influenced the creation
of allocators in the first place. Who knows...


I do. <g> If you have ancient copies of the STL documentation from HP,
you'll see my name listed as one of the contributors. That's because I
"fixed" a problem that Alex Stepanov and Meng Lee had in specifying
allocators. They were dealing specifically with the Intel architecture,
but that was just a particular instance of a more general problem. So
the true answer is that both of your alternatives are correct: size_type
is there for the Intel segmented architecture in particular, and for
alternative memory managers in general.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 22 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Christopher | last post by:
can someone refresh my meory on what std::size_t is used for? I am wondering if my template container class should have it's capacity as a size_t or an int? , Christopher
10
by: Grumble | last post by:
What is the difference between size_t and vector<T>::size_type? Are they ever a different type or a different size? Why should one type the latter when the former is shorter? What about the...
14
by: tings | last post by:
for (int i=0;i < strlen(pathcmd);i++){//this line cause a warning warning C4018: '<' : signed/unsigned mismatch strlen returns a number of type 'size_t'. size_t is an unsigned type and you are...
5
by: hanzhou.zhang | last post by:
Hi, vector<int> v; //... int size = v.size(); Since the vector's size() function returns a "size_t" number, the compilation with /Wp64 reports some warning. My question is: If I can...
7
by: William Xuuu | last post by:
Hi, This's a way of defining size_t and ssize_t in Linux: //"linux/types.h" typedef __kernel_size_t size_t; typedef __kernel_ssize_t ssize_t; //"asm/posix_types.h" typedef unsigned...
2
by: asdf | last post by:
Who can tell the difference in detail?
4
by: wenjie | last post by:
there are many examples write the loop like this: vector<intcoll; for(int i = 0; i < coll.size(); ++i){ ... } the function size() return type is size_t (unsigned int) ; I think if the size...
3
by: Jess | last post by:
Hello, I think any specialized size_type, such as string::size_type and vector<T>::size_type, is defined in terms of size_t, which is much more low level. Since they are more or less...
27
by: mike3 | last post by:
Hi. I can't believe I may have to use an array here. I've got this bignum package I was making in C++ for a fractal generator, and tried an approach that was suggested to me here a while...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.