Known Issues

This topic describes the known issues associated with developing Standard C++ applications or libraries on the Symbian platform.

The following functionalities of Standard C++ have certain limitations on the Symbian platform:

dynamic_cast: The dynamic_cast operator is not fully supported on the Symbian platform.
unexpected_handler: The CodeWarrior runtime does not support the invocation of unexpected_handler upon an exception specification violation.
IOStreams: The cin and cout objects are instances of istream and ostream classes and are exported by the STL library. As the emulator tool-chain does not support exporting of data, these are defined as function calls on the emulator.

These functions return references to the cin and cout objects that the STL library maintains. Since they are defined as functions, an attempt to import namespace by saying using std::cout may fail to compile. To resolve this issue, include the entire std namespace in such scenarios.

ARM RVCT compiler issues with STLport

Due to a defect in the ARM RVCT compiler versions 2.2, 3.1 and 4.0, building STLport v5 or STLport-based applications, creates some invalid export entries in DEF files. To workaround this issue, perform the following steps:

Use the GCCE compiler to generate the DEF file, if it is not available.
Ignore the warnings generated by the ARM RVCT compiler.
Note: When you ignore the warnings, do not freeze the invalid export entries in the DEF file using the ARM RVCT compiler.

Using the id member variable of facet classes

The Symbian platform does not support exporting static data. Hence, the id member variable of facet classes (static locale::id id) cannot be used directly on the Symbian platform. When you use these classes you must use the GetFacetLocaleId() function to access the data member id instead.

Examples

Using the id member of standard facets: For example, you can change locale::id Id1 = numpunct<char>::id; to locale::id Id1 = numpunct<char>::GetFacetLocaleId();.
Deriving a class from a standard facet: Declare a GetFacetLocaleId() static method, in addition to the member variable ID, when you define a class that is inherited from the locale::facet class, as illustrated in the following code:
```
class myfacet : public locale::facet
    {
    public:
    static locale::id id;
    static locale::id& GetFacetLocaleId() 
        {
        return id;
        } 
    };
```

Using a class that is part of a DLL: Ensure that you also handle the Writable Static Data (WSD) issues for emulator (WINSCW) builds along with the issues described in examples 1 and 2 as illustrated in the following code:

//myfacet.h
class myfacet : public locale::facet
    {
    public:
#ifndef __WINSCW__  
    static locale::id id;
#endif
    static locale::id& GetFacetLocaleId();
    };

//myfacet.cpp
std::locale::id& myfacet::GetFacetLocaleId()
    {
#ifndef __WINSCW__  
    return id;
#else
    // get the WSD struct – uses EWSD solution
    // get_wsd_struct() is a function defined by
                // the user to get a pointer to his WSD struct.
    return get_wsd_struct()->myfacet_id;
#endif
    }

Using memory leak detection macros

On an emulator, there are some dynamic memory allocations made for supporting WSD, when the Standard C++ library is initialised. In this scenario, if you add a memory leak detection macro, such as __UHEAP_MARK and __UHEAP_MARKEND, then you get a panic at __UHEAP_MARKEND.

To avoid this panic, you must call the CleanupWSD() function, provided only for use on emulator. For more information about how to achieve this, see the following example code:

#include <iostream>
using namespace std;
#ifdef __WINSCW__
#include <libstdcppwsd.h>
#endif
int main()
    {
    __UHEAP_MARK;
    cout << "Hello, World!" << endl;
#ifdef __WINSCW__
    CleanupWSD();// Cleanup all WSD related allocations
#endif
    __UHEAP_MARKEND;
    return 0;
    }

Known Issues

ARM RVCT compiler issues with STLport

Using the id member variable of facet classes

Using memory leak detection macros

Related concepts