<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-AF2CE612-F12E-5A18-81A5-C303992D2D46" xml:lang="en"><title>Possible

Problems</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>This section describes the possible problems that you may encounter when

<ul>

<li id="GUID-A3F0DCD7-CA38-5405-B01D-1E3B3F75B67D"><p><xref href="GUID-AF2CE612-F12E-5A18-81A5-C303992D2D46.dita#GUID-AF2CE612-F12E-5A18-81A5-C303992D2D46/GUID-39350E32-26C2-5440-B221-10EE693CCF18">Use of operator new</xref>  </p> </li>

<li id="GUID-9B185254-36B9-58F7-888D-8198EAD77769"><p><xref href="GUID-AF2CE612-F12E-5A18-81A5-C303992D2D46.dita#GUID-AF2CE612-F12E-5A18-81A5-C303992D2D46/GUID-A85386B3-3E37-5303-8FBF-211551D5CB71">Use of one definition rule</xref>  </p> </li>

<li id="GUID-01A440D6-7E35-5F4E-8E1E-F5877F3967F2"><p><xref href="GUID-AF2CE612-F12E-5A18-81A5-C303992D2D46.dita#GUID-AF2CE612-F12E-5A18-81A5-C303992D2D46/GUID-6CE49D59-46BB-5145-B346-6FD3EA8BC011"> Standard C++ calling Symbian C++ functions </xref>  </p> </li>

</ul>

<section id="GUID-39350E32-26C2-5440-B221-10EE693CCF18"><title> Use of operator

new()</title> <p>The function signatures of the global <codeph>operator new</codeph> on

Symbian C++ and Standard C++ differ only in the exception specification. As

per Standard C++, global <codeph>operator new</codeph> has the following signature: </p> <codeblock id="GUID-4369105F-C969-54E1-BBE5-C14ECA239F83" xml:space="preserve">void* operator new(std::size_t size) throw(std::bad_alloc);</codeblock> <p>While

in Symbian C++, it is: </p> <codeblock id="GUID-9FCCB90D-3E2D-505B-8FC9-6E0FACAC09F3" xml:space="preserve">void* operator new(unsigned int aSize) throw();</codeblock> <p>Since the compiler name-mangles references to both these symbols as the same,

it is possible (for the linker) to resolve a reference to one with the definition

to the other. If such a combination is not identified at build time, the memory

allocation may fail in the following cases: </p> <ol id="GUID-C6D4BDDD-B981-519C-9F2C-35DA294A23D9">

<li id="GUID-FFD5DB62-462F-5A4A-BC51-DBE213B9BD0F"><p>If a reference to Symbian

C++ <codeph>operator new</codeph> is resolved against the definition of Standard

C++ <codeph>operator new</codeph>, then it throws an exception which may leave

the <codeph>CleanupStack</codeph> in an unstable state. </p> </li>

<li id="GUID-19A3119A-E882-5C17-9674-9B45D6307FFE"><p>If a reference to Standard

C++ <codeph>operator new</codeph> is resolved against the definition of Symbian

C++ <codeph>operator new</codeph>, then the <codeph>operator new</codeph> returns <b>NULL</b> (while

an exception was expected). Since the return is not checked by the compiler,

it may cause a bus error. </p> </li>

</ol> <p>So, the declarations must be kept separate in the translation unit.

In this case only one of them can appear in a translation unit. Also, since

they have the same mangled names, they cannot appear in the same link unit. </p> </section>

<section id="GUID-A85386B3-3E37-5303-8FBF-211551D5CB71"><title>Use of one

definition rule</title> <p>As per Standard C++, one definition rule (ODR)

says that there must be only one definition of a symbol in a program. But

to be able to maintain a single definition in a program, symbol pre-emption

must be possible. This functionality is not supported on the DLL model of

template <class T>

class MySingleton

    {

    public:

    static T& GetInstance()

        {

        static T * aT = NULL;

        if (!aT) aT = new T;

        return *aT;

        }

    };

class X: public MySingleton<X>

    {

    public:

    X(): iX(0) {};

    int Prod()

        {

        return ++iX;

        }

    private:

    int iX;

    };</codeblock> <p> <b>Foo.cpp</b>  </p> <codeblock id="GUID-3AFCAE2C-8028-5813-BED1-889AD2909302" xml:space="preserve">#include &lt;MySingleton.h&gt;

EXPORT_C int Foo()

    {

    return X::GetInstance().Prod();

    }</codeblock> <p> <b>Bar.cpp</b>  </p> <codeblock id="GUID-6C00938A-2CD5-58D8-B937-6EE73C5BF483" xml:space="preserve">#include &lt;MySingleton.h&gt;

EXPORT_C int Bar()

    {

    return X::GetInstance().Prod();

    }</codeblock> <p>In a scenario where <filepath>Foo.cpp</filepath> is in <filepath>Foo.dll</filepath> and <filepath>Bar.cpp</filepath> is

in <filepath>Bar.dll.</filepath> To call <codeph>Foo</codeph> and <codeph>Bar</codeph> from

an application: </p> <codeblock id="GUID-E4A0FA6F-9792-5052-80B5-2372EB53FBFA" xml:space="preserve">int Baz()

    {

    return Foo() + Bar();

    }

int E32Main()

    {

    printf("%d\n", Baz());

    }</codeblock> <p>This example must have displayed the output as <b>1,

in distinct DLLs to a single unique location as required by the ODR. </p> </section>

<section id="GUID-6CE49D59-46BB-5145-B346-6FD3EA8BC011"><title>Standard C++

calling Symbian C++ functions</title> <p>The following example illustrates

the nature of one of the problems associated with achieving <i>seamless</i> integration

of Standard C++ with Symbian C++. Here <i>seamless</i> means: without the

manual introduction of additional harness or barrier code to effect the integration. </p> <p> <codeph>SymbianCallerLC</codeph> calls

two different functions: </p> <ul>

<li id="GUID-CC89E765-AF86-5300-BB76-F84DCF9E3910"><p>one which expects standard

C++ semantics (<codeph>CppCallee</codeph>), and </p> </li>

<li id="GUID-2E9D21A4-8FD3-5DC9-A264-7E7FEA05F4A9"><p>another which expects

</ul> <p> <codeph>SymbianCallerLC</codeph> itself belongs to the Symbian C++

world since it participates in the LC convention (it imposes a contract on

its caller with respect to the object that it returns). </p> <codeblock id="GUID-D88FA0A6-1107-570D-B79A-30EA10E4AB0C" xml:space="preserve">K1 * SymbianCallerLC()

    {

    K1 * aK1 = GetAK1LC();

    CppCallee(aK1);

    return aK1;

    }</codeblock> <p>The sole point of this function is to demonstrate that <i>stack

depth</i> cannot be used as an implicit means to synchronize the cleanup stack

with the control stack. It might be thought that recording <i>stack depth</i> at

the point at which an object is pushed onto the cleanup stack can be used

by the runtime to determine if the object should be <i>popped and destroyed</i> during

a standard C++ <i>throw</i>. Such a belief would be erroneous. For example,

a stack allocated object of sufficient size (<codeph>aArray</codeph> in this

case). The <i>stack depth</i> when the object allocated by <codeph>K1::NewLC</codeph> is

pushed on the cleanup stack is bound to be greater than the <i>stack depth</i> when

the <codeph>try</codeph> statement is executed in <codeph>CppCallee</codeph>.

From this example, therefore, that the <i>stack depth</i> at which an object

was allocated (or rather pushed onto the cleanup stack) gives no indication

of the ordering of various operations and can therefore not be used to determine

the inclusion of one extent within another. </p> <codeblock id="GUID-4FD53631-1369-5833-B0C0-1FD4F3C28BFB" xml:space="preserve">K1 * GetAK1LC()

    {

    int aArray[100]; 

    // stack frame for GetAK1LC has space for 100 ints - i.e. sp in this call to K1::NewLC 

    // will be less than at the 'try' in CppCallee

    return K1::NewLC(aArray);

    }</codeblock> <p>In the current context the object returned by <codeph>GetAnotherK1LC</codeph> will

be pushed on the cleanup stack when stack depth is less than it was in the

earlier call to <codeph>GetAK1LC</codeph>, more evidence that stack depth

cannot be used to determine ordering or extent inclusion. </p> <codeblock id="GUID-798CD3AA-0E08-5641-9FDA-DCE5224C7457" xml:space="preserve">K1 * GetAnotherK1LC()

    {

    return K1::NewLC();

    }</codeblock> <p> <codeph> CppCallee(K1 * aK1)</codeph> is a <i>catcher</i> which

calls <codeph>CppCallee(K1 * aK1, K1 aK2)</codeph> which can throw. It also

calls <codeph>GetAnotherK1LC()</codeph> in the extent of the <codeph>try</codeph> statement.

If <codeph>CppCallee(K1 * aK1, K1 aK2)</codeph> throws it might seem desirable

that <codeph>anotherK1</codeph> must be cleaned up by the runtime as part

of the throw. </p> <codeblock id="GUID-EAB8D25C-F8C4-5CF1-8AE4-5BEE7A877567" xml:space="preserve">void CppCallee(K1 * aK1)

    {

    try 

        {

        K1 * anotherK1 = NULL;

        anotherK1 = GetAnotherK1LC();

        CppCallee(aK1, anotherK1);

        }

    catch (...)

        {

        }

    }</codeblock> </section>

</conbody><related-links>

<link href="GUID-D6BEAF0D-844D-51F4-8DB7-FB1D60E17FE3.dita"><linktext>Copyright

Acknowledgments for Standard C++ (STLport)</linktext></link>

<link href="GUID-F7FEB759-E64D-5B6D-9017-C5E982E4FC16.dita"><linktext>Standard

C++ Library Overview</linktext></link>

<link href="GUID-2CCD1748-9EDE-5383-9941-A3051E06F3E2.dita"><linktext>Standard

<link href="GUID-1ACD01D1-2055-581A-9478-2C0D7D1CF9E6.dita"><linktext>Use Cases

for Writing Standard C++ Code</linktext></link>

<link href="GUID-E331B72B-84AF-558A-9B8F-73E5E50B58C7.dita"><linktext>Building

a Standard C++ Application or Library</linktext></link>

<link href="GUID-D32E52C9-F05C-5F1E-8B49-243D555C353C.dita"><linktext>Known Issues</linktext>

</link>

<link href="GUID-5B3F5296-D6D0-5D25-8362-141DF5927E52.dita"><linktext>Troubleshooting</linktext>

</link>

</related-links></concept>