const std::string::size_type cols = greeting.size() + pad * 2 + 2;
Why string::size_type
? int
is supposed to work! it holds numbers!!!
const std::string::size_type cols = greeting.size() + pad * 2 + 2;
Why string::size_type
? int
is supposed to work! it holds numbers!!!
A short holds numbers too. As does a signed char.
But none of those types are guaranteed to be large enough to represent the sizes of any strings.
string::size_type
guarantees just that. It is a type that is big enough to represent the size of a string, no matter how big that string is.
For a simple example of why this is necessary, consider 64-bit platforms. An int is typically still 32 bit on those, but you have far more than 2^32 bytes of memory.
So if a (signed) int was used, you'd be unable to create strings larger than 2^31 characters. size_type will be a 64-bit value on those platforms however, so it can represent larger strings without a problem.
The example that you've given,
const std::string::size_type cols = greeting.size() + pad * 2 + 2;
is from Accelerated C++ by Koenig. He also states the reason for his choice right after this, namely:
The std::string type defines size_type to be the name of the appropriate type for holding the number of characters in a string. Whenever we need a local variable to contain the size of a string, we should use std::string::size_type as the type of that variable.
The reason that we have given cols a type of std::string::size_type is to ensure that cols is capable of containing the number of characters in greeting, no matter how large that number might be. We could simply have said that cols has type int, and indeed, doing so would probably work. However, the value of cols depends on the size of the input to our program, and we have no control over how long that input might be. It is conceivable that someone might give our program a string so long that an int is insufficient to contain its length.
A nested size_type
typedef is a requirement for STL-compatible containers (which std::string
happens to be), so generic code can choose the correct integer type to represent sizes.
There's no point in using it in application code, a size_t
is completely ok (int
is not, because it's signed, and you'll get signed/unsigned comparison warnings).
size_t
. Or for most practical situations today you can get away with size_t
. But if there was no point to it, size_type
wouldn't exist, now would it? –
Mattah size_t
is guaranteed to be large enough, so at most you "waste" some space (in a register or on the stack) for using a larger-than-necessary value. These typedefs are for use in generic code, not when using std::string
, which is a concrete model. That is, if you're in a template function taking an arbitrary basic_string
, esp. with an arbitrary allocator, you should use the nested typedef. But yes, there's no point for std::string
, because size_t
is perfectly ok. –
Jen size_t
is unsigned. As long as you compare with std::string::npos
(as opposed to pos >= 0
), you should be okay. –
Bulgarian size_t
and std::string::size_type
are the same types except for one important difference: Were they both will represent a value of any size, std::string::size_type
(A member of std::string
) uses a static constant value of -1
to represent npos
. one past the end of the string. It tells the program that you have reached the end of the string. If you are using search
, find
, erase
, replace
, or any other modifying operations on strings, or writing your own then you may want to prefer std::string::size_type
. If you are just iterating over the string size_t
is probably fine.
© 2022 - 2024 — McMap. All rights reserved.