problem with vector<unsigned int> ???

Hi... I'm far from a master of STL, but I seem to be having some odd behavior with a vector<unsigned int> that I'm using. Basically, if I do this:

Code:

---

std::vector<unsigned int> vec;
unsigned int b = *(vec.begin());

---

I get a warning at the assignment of b of type:
warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned int', possible loss of data

I'm using VS.NET 2003 with its regular STL (not STLPort). I guess when creating a vector of unsigned int's, it's somehow getting confused and thinking that it's a vector of size_t's? Is this normal behavior? Should I be concerned? Will this warning disappear if I start using STLPort (I'd rather not)? And if it's unfixable, is a size_t the same size as an unsigned int on Win32, Mac, and Linux? I'm trying to make sure my app stays cross-platform.

-tom

Strangely, it compiles on VC++6 with SP5.

Odd.... it must be some kind of bug in the compiler. Using any other type (like an int or char) works fine, but unsigned int throws that warning. For now I've just used a pragma to disable it. I searched around on MSDN, and the warning number itself isn't documented in the compiler warning list for VS, but in some of the MSDN samples using STL, they disable it at the beginning with the comment "This isn't important"... so someone at MS must know about it, and just not care. :/

-tom

Hi Tom,

I have just tested out your code on VC++ .Net (v7.1) and it compiles correctly. I am not sure if this is really a bug in earlier version of VC++ .Net or there is some problem with your installation.

Hi, thanks for the responses everyone. I have looked into it a little more, and your are right, alone it does compile ok. The error seemed to be coming, oddly enough, from an unrelated multimap using size_t declared in one of the headers. This file, for exmaple, should generate the warning in a standard Win32 project setup:

#include <vector>
#include <map>
#include <windows.h>

INT WINAPI WinMain( HINSTANCE hInst, HINSTANCE, LPSTR strCmdLine, INT )
{
std::multimap<size_t, int> somemap;
std::vector<unsigned int> vec;
unsigned int b = vec.front();

return 0;
}

If one of you could check and see if you get the warning compiling this one, I would really appreciate it. And if anyone has any insight into why that would cause an error, it would be even more appreciated ;).

For your original code, there is no warning when compiled using the on-line Comeau compiler, which is one of, if not the most, ANSI C++ compliant compiler.

That's why it's a plus if you two (or more) compilers from different vendors when you suspect that the VC++ compiler may be doing something wrong. For VC++ 6.0, it's a must (at least for me) to have that second C++ compiler for those times when VC++ tells me that something is an error or warning, when I believe the code is perfectly fine.

Regards,

Paul McKenzie

Quote:

---

Originally posted by makeshiftwings
The error seemed to be coming, oddly enough, from an unrelated multimap using size_t declared in one of the headers. This file, for exmaple, should generate the warning in a standard Win32 project setup:

---

The most likely problem is that the windows.h header file screwed up one of the definitions that was used in the <vector> and <map> classes.

Either move the windows.h header first before all the headers, or get rid of it and make your code use int main() instead of WinMain:

Code:

---

#include <vector>
#include <map>

int main()
{
  std::multimap<size_t, int> somemap;
  std::vector<unsigned int> vec;
  unsigned int b = vec.front();
  return 0;
}

---

If this code doesn't give you a warning, it is the windows.h file that is causing the problem.

Regards,

Paul McKenzie

Nope, using a Win32 Console with just this file:

Code:

---

#include <map>
#include <vector>

void main(void)
{
        std::multimap<size_t, int> somemap;
        std::vector<unsigned int> vec;
        unsigned int b = vec.front();       
}

---

still gave the warning. It must be some kind of weird redefinition happening in the instantiation of the multimap. Just including <map> or even putting a typedef for a multimap<size_t, whatever> doesn't cause the error, only instantiating one does.

No warning:

Code:

---

#include <map>
#include <vector>

void main(void)
{
        typedef std::multimap<size_t, char> cmap;
        //cmap somemap;
        std::vector<unsigned int> vec;
        unsigned int b = vec.front();       
}

---

warning:

Code:

---

#include <map>
#include <vector>

void main(void)
{
        typedef std::multimap<size_t, char> cmap;
        cmap somemap;
        std::vector<unsigned int> vec;
        unsigned int b = vec.front();       
}

---

I dont know about your OP's warning. But the code snippet you posted right above me still contains void for main function which must get an interger in return.

Regards,

Crazily, I was just getting these same warnings last week on VC++ 7.0 using the boost.date_time library (which internally uses a bunch of STL components). I also had similar warnings when I first transferred some code over to 7.0. It always seems to occur where an assumption is made about size_t being the size of a pointer type (even though I was under the impression that that was one of the points of size_t). It seems like size_t doesn't follow these assumptions in 7.0 or later (perhaps it was enlarged to be able to hold 64 bit pointers or to use on differences as well, as you would ptrdiff_t -- I really don't know, but it is weird about when the warning disappears for smaller types). I don't know really what to do about. For my own code, I just fixed things up to actually use size_t where needed (which was good for my portability), but for library code, the assumption seems to crop up in certain places and I don't really know what to do. You could get brave and try to fix up the library, but I think just disabling the warning with a pragma is easy enough and takes care of the annoyance.

I have try your code on both VC6 and VC7 but I only receive the warning in VC7. It does seem like a bug to me.

Yes makeshiftwings,

main() returns an int, not void. Regardless of what VC++ lets you get away with, it is an error if main() returns a void (try it on an ANSI standard C++ compiler -- it will spit back an error at you that main() is not declared correctly).

Regards,

Paul McKenzie

hometown/paul:
aargh... i know, i know, about the int from main. This isn't actual code from my library, I was just trying to make the snippet small to show where the error is coming from. It's not from windows.h or the form of the main function... it is caused by instantiating a multimap using size_t and then trying to access a vector of unisgned int's. Just to make sure, I tried it with both an int main(void) and an int main(argc, argv); no difference.

I don't particularly have the option of switching compilers (this is the Visual C++ forum)... I was wondering if other people were getting the same bug and if there was a workaround.

galathaea:
I was thinking the same thing... maybe they've started updating the VS.NET2003 compiler to make way for longhorn, where the size of a pointer is going to go up to 64 bits. Still, it doesn't make any sense that instantiation of a totally unrelated map would have an affect on the return type of a totally unrelated vector. I'm mostly concerned about whether or not my vector actually does contain size_t's after the instantiation of the map, or if it's still containing unsigned int's and the compiler is just confused. The debugger/output window shows that it actually contains unsigned int's, which is good and bad at the same time I guess. If the warning is thrown from a similar thing (like calling std::copy on the vector), the output window will say something like "conversion from size_t... see instance with Ty= unsigned int T = unsigned int"... so I can't actually find the size_t anywhere that it's talking about... hmmph. Maybe it will be fixed in a patch.

edited to add:
I've noticed it's not just with multimap, I think it's with any STL container. The following code also give the warning:

Code:

---

std::vector<size_t> othervec;
std::vector<unsigned int> vec;
unsigned int b = vec.front();

---

Quote:

---

Originally posted by makeshiftwings
I don't particularly have the option of switching compilers (this is the Visual C++ forum)...

---

No, I wasn't talking about switching compilers, just to have another compiler around to verify that the code you entered is valid. Most professionals have a second (or even third) compiler for situations such as this -- the second compiler is only used as a verification tool.

Regards,

Paul McKenzie