When you compile code for the WINSCW target, you may get errors and warnings that were not present when building for WINS or ARM targets. This page explains some possible causes of this.

Issue: CodeWarrior compiler ignores the #pragma warning(...) statements that are used to disable specific Microsoft VC++ warnings.

Resolution: consult the CodeWarrior manuals for equivalent CodeWarrior #pragma controls over specific warnings.

The C++ Standard explicitly states that the order of evaluation of expressions is undefined. For example, for the line,

x = fn1(param1) + fn2(param2);

some compilers may evaluate fn1(param1) first, while others may evaluate fn2(param2) first. Symbian have in fact found cases where CodeWarrior, and Microsoft VC++ and GCC, differ in this behaviour. You should therefore never assume a particular order of evaluation. Note that this error may be hard to find, as program behaviour can be altered, but no compiler warnings are given.

Issue: illegal 'friend' declaration compiler errors for statements of the form friend MyClass;.

Resolution: use the syntax friend class MyClass;.

Issue: compiler errors when using identifiers with the names not, or, and, bitor, xor, compl, bitand, and_eq, xor_eq, or_eq, or not_eq.

This is because these are C++ keywords (alternative token representations for some operators and punctuators).

Resolution: modify the identifier name.

Issue: warnings caused by unneeded semi-colons, for example,

class CMyClass
    {
public:;

Resolution: remove unneeded semi-colons.

Issue: compiler errors for inline assembler hex constants specified with a trailing h, for example, 0001ah.

Resolution: specify such constants using the C++ 0xnnnn notation.

Issue: compiler errors for assembler labels of the form _asm label:.

Resolution: use C++ labels.

Issue: illegal access/using declaration compiler errors for class member functions whose declarations include the class name, for example:

class CMyClass
    {
    void CMyClass::MyFunction();
    };

Resolution: remove the class name from the function declaration.

Issue: illegal implicit conversion from 'unsigned char*' to 'const char*' compiler errors when attempting to pass an unsigned char* where a const char* is required.

CodeWarrior marks this as an error for both .c files and .cpp files; MS Visual C++ only marks it as an error for .cpp files.

Resolution: change the declaration or call to use matching types. Alternatively, to tell CodeWarrior not to warn on this issue, use the directive:

#pragma mpwc_relax on

Issue: this warns you that a loop has no body, for example, as in the following:

for (TInt i=0; i<10; i++); // loop ends here
        f(i);

Resolution: if a loop has no body intentionally, the warning can be removed by adding an empty body, for example,

while (f) {};

Issue: undefined identifier compiler errors for usage such as

class CMyClass
    {
    void MyFunction(TInt a=EMyVal1); // EMyVal1 not yet defined
    enum
        {
        EMyVal1
        };
    };

Resolution: move the enumerator's declaration to before its first usage.

Issue: non-const '&' reference initialized to temporary compiler errors for use of a reference to a pointer to a non-const object, where a reference to a pointer to a const object is required, for example:

void f(const TInt64*& aNum);

void f1()
    {
    TInt64* ptr;
    f(ptr);
    }

Resolution: the compiler correctly cannot add const-ness at this level of indirection, as the aNum value could then be modified through the ptr pointer. Modify the code to conform with the const-ness rules.

Issue: CodeWarrior follows the C++ standard in limiting the lifetime of a variable declared in a for statement to the loop block. The following code thus gives an undefined identifier error for the use of i in the second for statement.

for (TInt i=0; i<10; i++)
    {
    ...
    }
for (i=0; i<20; i++)
    {
    ...

Resolution: as Microsoft Visual C++ gives an error if, in the above case, i were to be redeclared in the second for statement. To be compatible with both compilers, declare the loop variable outside the for loop.

Issue: illegal use of non-static member warning for such code as:

class CMyClass
    {
public:
    int iNonStaticMember;
    };

int main()
    {
    printf("%d\n", sizeof(CMyClass::iNonStaticMember));
    }

The error is produced because CMyClass::iNonStaticMember is not the name of a type, nor an expression.

Resolution: a possible resolution is to provide a dummy object to produce a valid expression: for example,

sizeof(((CMyClass*)0)->iStaticMember)

Issue: extra warnings of the form variable 'myvariable' is not initialized before being used.

Resolution: the warnings are correct, and the code should be corrected.

Issue: the program panics with USER 42 when allocating and deleting arrays.

Resolution: see Cleanup for heap arrays for details of code techniques to prevent such panics.

The S in WINS and WINSCW stands for "single process". WINS/WINSCW supports multiple threads, but only a single process. This causes slight differences between WINS/WINSCW and target machines.

As WINS/WINSCW only has a single process, each process has access to each other’s memory. This means that bad pointers may corrupt another process’s memory, resulting in bugs which would not occur on a multi-process Symbian OS implementation. Also, design bugs such as using pointers across processes do not show until code is first run on a multi-process platform.