Visual Studio 2010 c++ compiler issue

Question

I have the following very strange situation... my Visual Studio compiler 2010 does not like the following piece of code:

    QStringList lst2 = instantiatedTableInstances.split(strComma, skipper);

    for(int i=0; i<lst2.size(); i++)
    {
        TableInstance* tabInst= v->getTableInstance(lst2.at(i));
        result->addInstantiatedTableInstance(tabInst);
    }

it gives me:

..\src\DeserializationFactory.cpp(1196) : error C2143: syntax error : missing ';' before 'constant'
..\src\DeserializationFactory.cpp(1196) : error C2440: '=' : cannot convert from 'QStringList' to 'int'
    No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
..\src\DeserializationFactory.cpp(1198) : error C2228: left of '.size' must have class/struct/union
   type is 'int'
..\src\DeserializationFactory.cpp(1200) : error C2228: left of '.at' must have class/struct/union
    type is 'int'

and a screenshot:

BUT if I rename the variable to lst instead of lst2 everything compiles...

Is this a funny bug in Visual Studio 2010 (because GCC does not care about it) or there is a more hidden reason for this?

Answer 1

These kind of errors are usually the result of an unexpected macro with the same name of your variable. A bit of google will find you this line in the Windows SDK header Dlgs.h :

#define lst2        0x0461

That's what I call name pollution !

My guess is that MS people thought that using a different ID for the controls of each dialog what hard to maintain, and so they though of giving the lists of any dialog the same IDs: lst1 , lst2 , lst3 ... lst16 . And the same with any other type of control. But for some reason the idea didn't catch and the Dlgs.h header was forgotten.

Now, the weird thing is that this header is included by default in your VC++ project and not in your GCC compilation. Maybe the environment is not the same.

Answer 2

looks like you have already had a variable called lst, which has a type of int. yes, i agree it looks like a bug of the compiler, since you are in a new variable space with if(secondStep){} wrapped.