How to handle with warning in C++ inline + template context?

Question

I'm facing an interesting problem: I had an MFC application project in Visual C++ 6.0. Since there are many changes either in MFC or in C++ standard, I wanted to port my application to Visual Studio 2010. It was fine, but I am facing a warning now, which I can't handle.

The header file has the following class definition:

template <class T>
class foo : public CObject
{
// ...
// other stuff
// ...
private:
    CTypedPtrMap<CMapWordToPtr, const long, T*> oElementMap;
    void some_stuff();
}

In the source file there is:

template <class T>
void foo::some_stuff()
{
// ...
// other stuff
// ...
    int nIndex = 0;
// ...
// other stuff
// ...
    oElementMap.RemoveKey(nIndex);
}

When I try to compile this, I get the following warnings:

Warning 1 warning C4244: 'argument' : conversion from 'const long' to 'WORD', possible loss of data c:\programme\microsoft visual studio 10.0\vc\atlmfc\include\afxtempl.h 2066

It comes definetly from the above mentioned "RemoveKey" line: if I just simply comment out that line, I won't get this warning.

I know, the main problem is, that CTypedPtrMap object uses const long as key type, but CMapWordToPtr would have WORD (unsigned short) instead of it. But the fact is: I need const long as key type, since I am processing regulary about 1 million data entries in this map, so with unsigned short the class would not be capable to do it's job furthermore.

I tried to nest either the "RemoveKey" line or the include of stdafx.h into the following expressions, but neither worked:

#pragma warning (disable: 4244)
// expression
#pragma warning (default: 4244)

Please share me any ideas about this issue, how could I resolve this warning WITHOUT changing the container's oElementMap definition and behaviour, and WITHOUT supress/disable this warning globally in the project settings as well as WITHOUT changing the afxtempl.h file supplied by VS2010.

Thanks for help:

Andrew

Answer 1

I've replaced it's definition to: CMap<long, long&, T*, T*&> oElementMap;. I was not sure it is the "long-counterpart" of the old map definition, therefore I did several test to compare them.

The solution was finally this.