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.

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.

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

You might want to provide the smallest and simplest compilable code that demonstrates this runtime error.

Quote:

---

Originally Posted by Xanz1441

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

---

Then there's something else wrong with the code, you know how to use the debugger?

Quote:

---

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.

> of course only after having thought about the consequences.
Face it, thinking ahead is not the usual fare around here.

> 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.

> You call one damn thing that uses size_t and now a bunch of size_t spreads through your code.
Well if you ignored the problem to begin with, then sure the ripples will go a long way when you get around to fixing it.
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.

Quote:

---

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.

Quote:

---

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.

If you know about the use of your variable, you can of course get rid of the warning by a cast to int (or whatever makes most sense in the circumstances).

--
Mats

Quote:

---

Originally Posted by brewbuck

But what if my loop had been like this:

Code:

---

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

---

---

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

Quote:

---

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.

> But what if my loop had been like this:
The number of times I've written a loop which iterates over a string say, starting at zero - lots and lots.
The number of times I've needed to start at a negative index - zero (or something damn close to zero).

Seems like a straw-man argument to me.

> Now there's just no way, unless I do this:
There's always another way:
char *magicPtr = normalptr - 2;
There, now you can index magicPtr using your mysterious -2 hack, but using a regular zero-based subscript.
But the mere sight of such code would be flagging up all sorts of "what the hell..." warnings in my head.

Quote:

---

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.

It's just a warning. Use size_t unless you have a need for unsigned numbers. In that case, don't worry about comparing signed and unsigned types.

For example:

Code:

---

size_t max = something.size();
for(int i=max-1; i>=0; --i){
  //loop backwards
}

---

Here you can't use size_t for i, or you will get an infinite loop. But unless something has more than 3 million members, you won't run into trouble.

It should be possible to iterate in reverse like this:

Code:

---

for (std::size_t i = a.size(); i--; )

---

Sure, but that's not as clear.

I never had problems iterating in reverse ;)

Code:

---

template <typename BidiRange>
void foo(BidiRange &rr)
{
  for(typename range_reverse_iterator<BidiRange>::type ri = rbegin(rr), re = rend(rr); ri != re; ++ri) {
    // Whatever.
  }
}

---

Sure, but that requires the use of iterators. Sometimes subscripting is more convenient. Unless you're making the argument that subscripting should never be used to iterate through each value an array -- forwards or backwards.

My rule of thumb for unsigned values being reverse iterated is to use a do...while.

> But that creates a pointer value which is undefined, according to the standard.
Yes, just as "undefined" as your negative subscript - what's your point?