Size_t & mutable

P

Pelle Beckman

Hi,

Honestly, what is this 'size_t'?

And while I'm at it - what is a 'mutable' var.?
I've understood it somehow makes a const a non-const,
but what's the point of that?

Short explanations? Links? FAQ?

Thanks
-- Pelle
 
J

Jonathan Mcdougall

Pelle said:
Hi,

Honestly, what is this 'size_t'?

An unsigned integer type used by the standard library to represent
sizes or indices. Many functions in the standard library take or return
size_t's and you should always use the same type. For example,

void f(std::vector<string> &v)
{
std::size_t size = v.size();

std::size_t index = 10;
std::cout << v[index];
}

Personnaly, I use std::size_t very often in my programs, not only in
conjuction with the standard library.
And while I'm at it - what is a 'mutable' var.?
I've understood it somehow makes a const a non-const,
but what's the point of that?

Allows an object to be logically const. An object is logically const
when its visible state does not change. For example, you may cache some
data for faster access. Accessing this data may modify the cache, and
this is ok even for const objects, since the cache does not modify the
object's visible state. Making the cache mutable allows a const member
function to modify it.

See
http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.13
for some more infos. IIRC, Scott Meyer's [More] Effective C++ has an
item on that, but I cannot give specific references.


Jonathan
 
J

Jacek Dziedzic

Jonathan said:
void f(std::vector<string> &v)
{
std::size_t size = v.size();

std::size_t index = 10;
std::cout << v[index];
}

Personnaly, I use std::size_t very often in my programs, not only in
conjuction with the standard library.

Would you go as far as

for(std::size_t i=0; i<max; ++i) array*=2;

rather than

for(int i=0; i<max; ++i) array*=2;
or
for(unsigned int i=0; i<max; ++i) array*=2;

cheers,
- J.
 
B

benben

Jacek Dziedzic said:
Jonathan said:
void f(std::vector<string> &v)
{
std::size_t size = v.size();

std::size_t index = 10;
std::cout << v[index];
}

Personnaly, I use std::size_t very often in my programs, not only in
conjuction with the standard library.

Would you go as far as

for(std::size_t i=0; i<max; ++i) array*=2;

rather than

for(int i=0; i<max; ++i) array*=2;
or
for(unsigned int i=0; i<max; ++i) array*=2;

cheers,
- J.


I would go as far to use size_t for indexing a vector. This way the compiler
wouldn't give a warning (as it will do if you use a signed int.)

Regards,
Ben
 
M

ma740988

| Personnaly, I use std::size_t very often in my programs, not only in
| conjuction with the standard library

Jonathan, I realize the word 'very often', nonetheless, I too try to
follow the same approach but what do you do for the case where you're
faced with vendor API's that expects unsigned. One obvious answer is
to use an unsigned. This way it rids the compiler warnings related to
potential conversions from unsigned long (size_t may be unsigned long
on said platform) to unsinged int - 'loss of data'. I'd like to belive
vendors should just use size_t in this case but ....
 
J

Jonathan Mcdougall

| Personnaly, I use std::size_t very often in my programs, not only in
| conjuction with the standard library

Jonathan, I realize the word 'very often', nonetheless, I too try to
follow the same approach but what do you do for the case where you're
faced with vendor API's that expects unsigned.

std::size_t is unsigned. Do you mean unsigned int?
One obvious answer is
to use an unsigned. This way it rids the compiler warnings related to
potential conversions from unsigned long (size_t may be unsigned long
on said platform) to unsinged int - 'loss of data'. I'd like to belive
vendors should just use size_t in this case but ....

Use the type which suits the circumstances. Try to use a type with
which you won't need any casts. If a function expects a signed integral
and you are using an unsigned integral, it may mean that the origin is
not compatible with the destination. In most cases though, converting
an unsigned (say, an index) to a signed integral is not too much
trouble. Every case is different.

If a function expects an unsigned int and you have a std::size_t which
is a typedef for an unsigned long, just make sure you never overflow
the unsigned int. Using 3rd party libraries usually means adaptation
and tradeoffs.


Jonathan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,774
Messages
2,569,596
Members
45,135
Latest member
VeronaShap
Top