Symbian3/PDK/Source/GUID-38CF8A8E-4778-5374-8AC6-5F9486A2B7FB.dita
author Dominic Pinkman <Dominic.Pinkman@Nokia.com>
Tue, 30 Mar 2010 11:56:28 +0100
changeset 5 f345bda72bc4
parent 3 46218c8b8afa
child 14 578be2adaf3e
permissions -rw-r--r--
Week 12 contribution of PDK documentation_content. See release notes for details. Fixes Bug 2054, Bug 1583, Bug 381, Bug 390, Bug 463, Bug 1897, Bug 344, Bug 1319, Bug 394, Bug 1520, Bug 1522, Bug 1892"

<?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-38CF8A8E-4778-5374-8AC6-5F9486A2B7FB" xml:lang="en"><title>The polymorphic
interface DLL</title><shortdesc>A polymorphic interface DLL is one which is written to implement
a programming interface defined elsewhere; for example, a device driver, an
application or an OPL extension.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>The API is defined in terms of a single abstract class whose functions
are declared as pure virtual. The DLL <i>implements</i> the API by defining
and implementing a concrete class derived from that abstract class. The DLL
exports a single function whose sole purpose is to create an object of the
derived class type; this is always the function at ordinal 1 within the DLL.
All other functions in the DLL are called through the virtual table mechanism
(the pointer to the vtable is set up by the constructor in the normal C++
way).</p>
<p>At compilation time, application code includes the header file(s) which
define(s) the API. At link time, the application includes the DLL's module
definition file, which allows the address of the DLL function to be accessed
by specifying its ordinal.</p>
<p>When the application's executable runs, it loads the DLL at the time it
is required. The address of the single function exported by the DLL is accessed
indirectly by specifying its ordinal.</p>
<p>For a given interface, there may be many DLLs which obey the protocol imposed
by that interface each of which provides a different implementation.</p>
<p>A DLL of this type is often referred to as a dynamically loaded DLL.</p>
<p>The user of a dynamically loaded DLL uses an <codeph>RLibrary</codeph> type
object to load the DLL. The <codeph>RLibrary</codeph> object encapsulates
a handle to the DLL and must remain in existence while the DLL is in use;
typically this is for the life of the object provided by the DLL.</p>
</conbody></concept>