Odd map::find behavior on 64-bit windows

[Benny the Guard]

Been working on a project that compiles, links, and runs fine on 32-bit windows. Now trying to migrate to 64-bit windows. On debug build it works fine. However, on release build the std::map::find operation starts acting odd.

My code simply does a lookup, if it fails it inserts the proper element (creating the data element is expensive so I only want to do it if needed and many times its not). In the lookup I see the size is 0 (since release build relying on printf of .size ()). So I would expect to have .find return .end () that is nothing. Now my map is a map of ptrs so it uses its own comparator function, and the thing is I see the comparator called for the data i am looking for as well as a NIL ptr. This only happens in release build not debug, so strikes me as odd.

My map is defined as:

typedef std::map<MyDataKey*, MyInfo*, MyLessThanFunctor> My_Map; 

and my find code:

My_Map::iterator find_itr = m_my_map.find (key_ptr);

I verified the key_ptr address is one of the items in my comparator, but when the map size is 0 why is the comparator even called? Where is this NIL coming from and why only in release builds? Thanks for the help.

[weaknessforcats]

Obviously ,there is a difference between the 32-bit and the 64-bit templates.

Do you have the latest set of templates?? Dinkumware always seems to have fixes beyond the Visual Studio release.

[Benny the Guard]

This was first recorded using .NET 2003 compiler and includes. However to make sure I went with .NET 2005 compiler for this latest version and is breaking. I have been using google to try and track down the issue (can't be the only one seeing this if its a MS problem), but no luck. Can't use any custom versions here as this is for work and we must work with the standard .NET framework. I am also going o try as a test is creating another map and seeing what happens. A collegue also mentioned allocating large arrays on either side of my map allocation and then checking the contents of them to see if somebody is overwriting the memory and messing things up. Might be worth a try.

Also for further background this code works on Linux both 32 and 64 bit both debug and non-debug builds. So the evidence is mounting that there is something wacky on Windows 64-bit release builds.

[Benny the Guard]

Followup after a long day of debugging. The map in question was a class member of my object. I had some map::insert and map::find calls in methods defined in the header file. Once I moved these and all constructor/destructor code to the cpp files it compiled and ran fine. So it seems .NET 2003/.NET 2005 have problems when compiling in release mode with code in the header files. Works on every other build platform, so I'll chalk this up to an MS bug in the compiler.

[weaknessforcats]

So it seems .NET 2003/.NET 2005 have problems when compiling in release mode with code in the header files.

There should never be code in a header file. Header files are for declarations and .cpp files for definitions. Code in a header file will get you redefinition errors unless it has internal linkage, which means you need to use static, which is deprecated in C++, etc, etc... and it makes your footprint bigger.

By declaration I mean that no memory is allocated. No variables and no functions.

[Benny the Guard]

We do this all of the time for inline functions. Otherwise the compiler complains that the code is unavailable. We also only do it in methods of a class, which is supported by C++. If I tried this with actual functions outside the context of a class, you would be right there would be compile errors (same as if I declared globals in a header, multiple copies). But putting code in the methods is perfectly fine. Just not on Windows 64-bit Release builds apparently.

[weaknessforcats]

We do this all of the time for inline functions. Otherwise the compiler complains that the code is unavailable. We also only do it in methods of a class, which is supported by C++.

Inline functions are not function definitions. They are used by the compiler to copy inline where you call them, Functions inside classes are also inline functions. They, too, are copied as needed.

A function definition requires memory be allocated. An inline function allocates no memory so it is really more like a macro and, therefor, suitable, for a header file.

As to your problem, I did try your code on 32-bit Windows and there were no calls to the comparator. I tend to agree with you that it is an MS 64-bit compiler bug. You should report it.