S60 3rd edition linker problem

[ddskani]

Hi,

Time for another newbie question.

All of a sudden our project has started to get linker problems, in both the emulator and the GCCE build.

The linker error we get is

int operator==(int, enum TTrue)

And an example of code that creates the "error"

void MyClass::MyMethod( void )
{
    TBool myBool = ETrue;

    if( myBool == ETrue ) //Linker problem line of code
    {
        //Do something
    }
}

Do get it through the linker, it's just to cast the ETrue to a TBool before comparing, like below

void MyClass::MyMethod( void )
{
    TBool myBool = ETrue;

    if( myBool == (TBool)ETrue )
    {
        //Do something
    }
}

But should it really be necessary?

Regards,
ddskani

[hotcheese]

Its not good 'style' to do comparison on a boolean.

You could simply rewrite your code as

...
if( myBool )
....

[regan_coleman]

excellent-and-concise post as usual hotcheese.

i would add that this is caused by, in your case, ddskani, the TBool being typedef'd to an int, (usually the case depending on compiler) while ETrue is an enum which means you're comparing 2 different things. Mixing these 2 is not great but permitted in certain cases -- I'd have to re-read the latest C++ specs about that case in particular but I'm guessing that the latest specs are causing the compiler writers to handle the case differently than before.

If you can change the code, go for it.

If you can't change the code now, because 1) practically it's in zillions of places and you need to compile today to get the product out the door until you have time to rewrite it everywhere per hotcheese or 2) it's in 3rd-party code (aside: i've seen variants of this in 'system' code provided by 'company name withheld ' ) here's some possible interim solutions off the top of my head -- they have pros and cons so you weigh the decision based on your needs: some compilers have options allowing you to control this behavior; alternatively you can provide a quick implementation of the == method yourself.....

Good luck!

[hotcheese]

That linker error is actually a useful thing.

If you had some code such as

myBool = ETrue;

But mistyped it as
myBool == ETrue;

Then without the linker error you'll have a bug that could take a while to track down.

[billbonney]

more info can be found here http://www.symbian.com/developer/tec...uide%2eboleean

I remember being told way back in 1998 on a EPOCWorld Training course that the reason EFalse and ETrue are declared as such is to create the linker problem and stop people misunderstanding which value is true/false for boolean.

more discussion about pros and cons of bool can be found here http://www.glenmccl.com/bool_cmp.htm

[regan_coleman]

>>That linker error is actually a useful thing.
...
>>I remember being told way back in 1998 on a EPOCWorld Training course that the reason EFalse and ETrue are declared as such is to create the linker problem and stop people misunderstanding which value is true/false for boolean.

Yep. See : http://www3.symbian.com/faq.nsf/0/FF...4?OpenDocument