Sure.
Both VC and GCC will warn about conversions (e.g. from long to int);
*hundreds* of warning in a compilation could lead to miss the important
ones.
So I've been asked to remove as much warnings as I can: I ofter turn the
relevant options off (e.g. -Wconversions in GCC), since most of these
are harmless, but I've been asked not to do this.
Well, that implies you work with a concrete set of compilers as the
environment. Not just shoot in the dark (like aim to release a general
library component claimed to be portable to the extremes).
For that case I see not enough reason to go paranoid and mess up the
code with excess noise. As you are pretty much able to verify that
size_t is good for your purposes. And have a plenty of ways to ensure it
too in form of a test, a static_assert, whatever.
Sure.
From what I found: "size_t corresponds to the integral data type
returned by the language operator sizeof".
It's also required to be unsigned in the C standard (7.17p2). And to
serve for sizeof it must be big enough to count bytes in the system. So
it must be good to count elements in a vector, maybe except for
vector<bool> that is a known troublemaker and better be avoided.
As size_type of std collections is also an unsigned integral, that is to
count the elements, I really don't see the problem place, and if one
actually shows up, I'd welcome the warning.
I'd be glad to be proven wrong, but this has in principle nothing to do
with vectors (altough most implementation will use this type).
I'd be very interested in a counter-example from the general world.
So the use of size_t *could* lead to a conversion warning (which is my
given goal to avoid).
I'd classify that is a mistaken goal -- the point is write good code,
that is easy to make right, and also easy to read and review. That is
obvious rather than cryptic.
Warinigs are our friend, that help the work. We make them go away by
writing *better* code. And in the few corner cases we encounter an
overzealous one, it's better be suppressed on the spot.
In most cases, int will cover the purpose of letting the program run
flawlessly:
int is not fit for purposes of size_t, and hardly fits this discussion.
when our vectors will be larger than 4G elements, we'll have
much more severe problems than some compiler warning.
However, as I said before, one of my tasks is to avoid them anyway.
And you stand with claim, that using the fixed size_t left you with
warnings?
I don't follow... what do you mean?
The wise saying goes "watch the baton not the runners". You look like
being after the wrong goal.