← Back to branch summary

~oif-team/ubuntu/natty/qt4-x11/xi2.1

« back to all changes in this revision

Viewing changes to doc/src/howtos/sharedlibrary.qdoc

  • Committer: Bazaar Package Importer
  • Author(s): Alessandro Ghersi
  • Date: 2009-11-02 18:30:08 UTC
  • mfrom: (1.2.2 upstream)
  • mto: (15.2.5 experimental)
  • mto: This revision was merged to the branch mainline in revision 88.
  • Revision ID: james.westby@ubuntu.com-20091102183008-b6a4gcs128mvfb3m
Tags: upstream-4.6.0~beta1
Import upstream version 4.6.0~beta1

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/src/howtos/sharedlibrary.qdoc
 
1
/****************************************************************************
 
2
**
 
3
** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
 
4
** All rights reserved.
 
5
** Contact: Nokia Corporation (qt-info@nokia.com)
 
6
**
 
7
** This file is part of the documentation of the Qt Toolkit.
 
8
**
 
9
** $QT_BEGIN_LICENSE:LGPL$
 
10
** No Commercial Usage
 
11
** This file contains pre-release code and may not be distributed.
 
12
** You may use this file in accordance with the terms and conditions
 
13
** contained in the Technology Preview License Agreement accompanying
 
14
** this package.
 
15
**
 
16
** GNU Lesser General Public License Usage
 
17
** Alternatively, this file may be used under the terms of the GNU Lesser
 
18
** General Public License version 2.1 as published by the Free Software
 
19
** Foundation and appearing in the file LICENSE.LGPL included in the
 
20
** packaging of this file.  Please review the following information to
 
21
** ensure the GNU Lesser General Public License version 2.1 requirements
 
22
** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
 
23
**
 
24
** In addition, as a special exception, Nokia gives you certain additional
 
25
** rights.  These rights are described in the Nokia Qt LGPL Exception
 
26
** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
 
27
**
 
28
** If you have questions regarding the use of this file, please contact
 
29
** Nokia at qt-info@nokia.com.
 
30
**
 
31
**
 
32
**
 
33
**
 
34
**
 
35
**
 
36
**
 
37
**
 
38
** $QT_END_LICENSE$
 
39
**
 
40
****************************************************************************/
 
41
 
 
42
/*!
 
43
    \page sharedlibrary.html
 
44
    \title Creating Shared Libraries
 
45
 
 
46
    \ingroup best-practices
 
47
 
 
48
    The following sections list certain things that should be taken into
 
49
    account when creating shared libraries.
 
50
 
 
51
    \section1 Using Symbols from Shared Libraries
 
52
 
 
53
    Symbols - functions, variables or classes - contained in shared libraries
 
54
    intended to be used by \e{clients}, such as applications or other
 
55
    libraries, must be marked in a special way. These symbols are called
 
56
    \e{public symbols} that are \e{exported} or made publicly visible.
 
57
 
 
58
    The remaining symbols should not be visible from the outside. On most
 
59
    platforms, compilers will hide them by default. On some platforms, a
 
60
    special compiler option is required to hide these symbols.
 
61
 
 
62
    When compiling a shared library, it must be marked for \e{export}. To use
 
63
    the shared library from a client, some platforms may require a special
 
64
    \e{import} declaration as well.
 
65
 
 
66
    Depending on your target platform, Qt provides special macros that contain
 
67
    the necessary definitions:
 
68
    \list
 
69
        \o  \c{Q_DECL_EXPORT} must be added to the declarations of symbols used
 
70
            when compiling a shared library.
 
71
        \o  \c{Q_DECL_IMPORT} must be added to the declarations of symbols used
 
72
            when compiling a client that uses the shared library.
 
73
    \endlist
 
74
 
 
75
    Now, we need to ensure that the right macro is invoked -- whether we
 
76
    compile a share library itself, or just the client using the shared
 
77
    library.
 
78
    Typically, this can be solved by adding a special header.
 
79
 
 
80
    Let us assume we want to create a shared library called \e{mysharedlib}.
 
81
    A special header for this library, \c{mysharedlib_global.h}, looks like
 
82
    this:
 
83
 
 
84
    \code
 
85
        #include <QtCore/QtGlobal>
 
86
 
 
87
        #if defined(MYSHAREDLIB_LIBRARY)
 
88
        #  define MYSHAREDLIB_EXPORT Q_DECL_EXPORT
 
89
        #else
 
90
        #  define MYSHAREDLIB_EXPORT Q_DECL_IMPORT
 
91
        #endif
 
92
    \endcode
 
93
 
 
94
    In the \c{.pro} file of the shared library, we add:
 
95
 
 
96
    \code
 
97
        DEFINES += MYSHAREDLIB_LIBRARY
 
98
    \endcode
 
99
 
 
100
    In each header of the library, we specify the following:
 
101
 
 
102
    \code
 
103
        #include "mysharedlib_global.h"
 
104
 
 
105
        MYSHAREDLIB_EXPORT void foo();
 
106
        class MYSHAREDLIB_EXPORT MyClass...
 
107
    \endcode
 
108
    This ensures that the right macro is seen by both library and clients. We
 
109
    also use this technique in Qt's sources.
 
110
 
 
111
 
 
112
    \section1 Header File Considerations
 
113
 
 
114
    Typically, clients will include only the public header files of shared
 
115
    libraries. These libraries might be installed in a different location, when
 
116
    deployed. Therefore, it is important to exclude other internal header files
 
117
    that were used when building the shared library.
 
118
 
 
119
    For example, the library might provide a class that wraps a hardware device
 
120
    and contains a handle to that device, provided by some 3rd-party library:
 
121
 
 
122
    \code
 
123
        #include <footronics/device.h>
 
124
 
 
125
        class MyDevice {
 
126
        private:
 
127
            FOOTRONICS_DEVICE_HANDLE handle;
 
128
        };
 
129
    \endcode  
 
130
 
 
131
    A similar situation arises with forms created by Qt Designer when using
 
132
    aggregation or multiple inheritance:
 
133
 
 
134
    \code
 
135
        #include "ui_widget.h"
 
136
 
 
137
        class MyWidget : public QWidget {
 
138
        private:
 
139
            Ui::MyWidget m_ui;
 
140
        };
 
141
    \endcode  
 
142
 
 
143
    When deploying the library, there should be no dependency to the internal
 
144
    headers \c{footronics/device.h} or \c{ui_widget.h}.
 
145
 
 
146
    This can be avoided by making use of the \e{Pointer to implementation}
 
147
    idiom described in various C++ programming books. For classes with
 
148
    \e{value semantics}, consider using QSharedDataPointer.
 
149
 
 
150
 
 
151
    \section1  Binary compatibility
 
152
 
 
153
    For clients loading a shared library, to work correctly, the memory
 
154
    layout of the classes being used must match exactly the memory layout of
 
155
    the library version that was used to compile the client. In other words,
 
156
    the library found by the client at runtime must be \e{binary compatible}
 
157
    with the version used at compile time.
 
158
 
 
159
    This is usually not a problem if the client is a self-contained software
 
160
    package that ships all the libraries it needs.
 
161
 
 
162
    However, if the client application relies on a shared library that belongs
 
163
    to a different installation package or to the operating system, then we
 
164
    need to think of a versioning scheme for shared libraries and decide at
 
165
    which level \e{Binary compatibility} is to be maintained. For example, Qt
 
166
    libraries of the same \e{major version number} are guaranteed to be binary
 
167
    compatible.
 
168
 
 
169
    Maintaining \e{Binary compatibility} places some restrictions on the changes
 
170
    you can make to the classes. A good explanation can be found at
 
171
    \l{http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++}
 
172
    {KDE - Policies/Binary Compatibility Issues With C++}. These issues should
 
173
    be considered right from the start of library design.
 
174
    We recommend that the principle of \e{Information hiding} and the
 
175
    \e{Pointer to implementation} technique be used wherever possible.
 
176
*/