Re: Unexpected compiler behavior relating to size_t and boost - VisualStudio 2005.

[Juha Nieminen]

Unknownmat wrote:

I am using Visual Studio 2005 (msvc 8.0, I believe). I am experience
some unexpected compiler warnings that have to do with how integer
types, size_t, and boost interact.

VS2005 has a bug related to this. When you use size_t, it internally
converts it to 'unsigned int'. In some situations it forgets that the
type was actually size_t and only sees it's an 'unsigned int', so when
you eg. assign a size_t value to such a "unsigned int which was a size_t
but VS2005 has forgotten about it", it will give you a warning about
possible data loss (because it only sees that a size_t is being assigned
to an unsigned int, and this triggers its warning about possible loss of
data, as size_t may be bigger than unsigned int in another system).

I don't know if anything can be done about that, except turning the
warning off. (You can turn it off on a per-file basis using a #pragma.)

[James Kanze]

On Jul 14, 4:51 pm, Juha Nieminen <[e-mail]:

Unknownmat wrote:

I am using Visual Studio 2005 (msvc 8.0, I believe). I am experience
some unexpected compiler warnings that have to do with how integer
types, size_t, and boost interact.

VS2005 has a bug related to this. When you use size_t, it internally
converts it to 'unsigned int'. In some situations it forgets that the
type was actually size_t and only sees it's an 'unsigned int',

How is that a bug? size_t is required to be a typedef, not a
real type, and on a lot of 32 bit machines, it is an unsigned
int. Not "gets converted to", but "is".

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Unknownmat]

Juha Nieminen wrote:

Unknownmat wrote:

I am using Visual Studio 2005 (msvc 8.0, I believe). I am experience
some unexpected compiler warnings that have to do with how integer
types, size_t, and boost interact.

VS2005 has a bug related to this. When you use size_t, it internally
converts it to 'unsigned int'. In some situations it forgets that the
type was actually size_t and only sees it's an 'unsigned int', so when
you eg. assign a size_t value to such a "unsigned int which was a size_t
but VS2005 has forgotten about it", it will give you a warning about
possible data loss (because it only sees that a size_t is being assigned
to an unsigned int, and this triggers its warning about possible loss of
data, as size_t may be bigger than unsigned int in another system).

I don't know if anything can be done about that, except turning the
warning off. (You can turn it off on a per-file basis using a #pragma.)

Thanks for the response that helps immensley. Do you happen to have a
Microsoft KB link?

I will do some more digging now that I know that this is VS2005
related. What's interesting to me is that I am very careful about
using size_t - I never need to typecast between unsigned and size_t
(unless I'm forced to by a library API or something). In the example
I posted above, in fact, I'm not even USING the vector< size_tobject
- there's simply no way this object could cause a conversion error.

Thanks,
Matt

[Juha Nieminen]

Unknownmat wrote:

What's interesting to me is that I am very careful about
using size_t - I never need to typecast between unsigned and size_t
(unless I'm forced to by a library API or something). In the example
I posted above, in fact, I'm not even USING the vector< size_tobject
- there's simply no way this object could cause a conversion error.

That's the funny side-effect of that bug: Even if there isn't even a
single "int" or "unsigned int" in the entire program, only size_t (and
some template, which is what usually causes the problem), the compiler
will still trigger a warning about an inexistent "unsigned int".

(The problem is understandable because when compiling a 32-bit program
size_t *is* an unsigned int, but other compilers are able to retain the
info that it was, actually, a size_t all the way and they don't give any
warnings.)

[James Kanze]

On Jul 14, 7:42 pm, Juha Nieminen <[e-mail]:

Unknownmat wrote:

What's interesting to me is that I am very careful about
using size_t - I never need to typecast between unsigned and size_t
(unless I'm forced to by a library API or something). In the example
I posted above, in fact, I'm not even USING the vector< size_tobject
- there's simply no way this object could cause a conversion error.

That's the funny side-effect of that bug: Even if there isn't
even a single "int" or "unsigned int" in the entire program,
only size_t (and some template, which is what usually causes
the problem), the compiler will still trigger a warning about
an inexistent "unsigned int".

(The problem is understandable because when compiling a 32-bit
program size_t *is* an unsigned int, but other compilers are
able to retain the info that it was, actually, a size_t all
the way and they don't give any warnings.)

I think you have it backwards. Other compilers simply consider
it an unsigned int (or whatever), and get on with it; they don't
try to treat size_t differently from whatever it is typedef'ed
to.

Which is, of course, what the standard says the compiler should
do.

Of course, there's nothing wrong with keeping the fact that this
unsigned int was originally a size_t, for things like error
messages, e.g. displaying std::vector< size_t ... instead of
std::vector< unsigned int ... >. But in practice, most don't
seem to: if I write:
std::vector< std::size_t v ;
v.push_back( 1, 2 ) ;
both g++ and Sun CC complain about an error using a member
function of "std::vector<unsigned int, std::allocator<unsigned
int" (g++) or "std::vector<unsigned>" (Sun CC). Only VC++
retains this information, displaying an error in
"std::vector<_Ty>", but later indicating that _Ty=size_t (which
is actually pretty nice---it's nice, too, that both Sun CC and
VC++ omit mentionning the allocator).

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]