Thread: size_t help

I'm using the .find() function to search through a string like so

Code:

int i;

i = string.find("whatever");

but i'm getting warnings that possible loss of data could occur due to a conversion from
size_t to int.

I was told that I could just ignore it, because it still works because the string isn't that big, but I'd like to see what I could do to fix this.

When i change it to size_t, the warnings go away, but I get a runtime error when I run the program.

Originally Posted by Salem

Change the type to a size_t, what is so tricky?

> because it still works because the string isn't that big
Sooner or later, the casual attitude to types will bite you.

On the other hand, it's kind of dumb for code to force the user to use specific types when all he really wanted is to figure out where something occurs in a string. You call one damn thing that uses size_t and now a bunch of size_t spreads through your code.

This is one error I commit on purpose regularly, of course only after having thought about the consequences.

Java completely did away with unsigned integer types for this among other reasons.

Originally Posted by Salem

> On the other hand, it's kind of dumb for code to force the user to use specific types
> when all he really wanted is to figure out where something occurs in a string.
Either you have a type system or you don't.

Well, yes. But the problem is not the type system, but the presence of so many signed and unsigned integer types of varying widths.

But if you use the correct type from the outset, it might just warn you when you're trying to add oranges to cabbage for example.

This is what I'm getting at:

Code:

int i;
size_t n = strlen(something);

for(i = 0; i < n; i++) /* Warns "Comparison between signed and unsigned" */

Yes, "all" I have to do is make the loop iterator a size_t. But what if my loop had been like this:

Code:

for(i = -2; i < n; i++)

Now there's just no way, unless I do this:

Code:

size_t i_plus_2;

for(i_plus_2 = 0; i_plus_2 < n + 2; i_plus_2++)
{
    /* Now all I have to do is subtract 2... Except when it would be negative. D'oh. */
}

Ultimately I end up doing this:

Code:

int size_t_to_int(size_t n)
{
    if(n > INT_MAX)
    {
        blow_up();
    }
    return int(n);
}

It's all just silly, given that the length of the string is not going to be anywhere near the limit of an integer.

Originally Posted by CornedBee

Why on earth would you have such a loop when iterating through something that has 0-based indices?

Iterating through an array might not be what is going on. Yeah, contrived example, but I have real ones too.

Originally Posted by Salem

There's always another way:
char *magicPtr = normalptr - 2;

But that creates a pointer value which is undefined, according to the standard.