<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=US-ASCII">
<title>C++ Dynamic Library Support</title>
</head>
<body>
<h1>DRAFT C++ Dynamic Library Support</h1>

<p>
ISO/IEC JTC1 SC22 WG21 N2425 = 07-0295 - 2007-10-21
</p>

<p>
Lawrence Crowl, crowl@google.com, Lawrence@Crowl.org
</p>

<p>
This paper is a revision of N2407 = 07-0267 - 2007-09-10.
</p>

<p>
<strong>NOTE:
The committee has decided to defer work on dynamic libraries
until after the C++0x standard.
This paper represents a snapshot of that work,
and hence is generally incomplete.
</strong>
</p>

<ul>

<li><a href="#Introduction">Introduction</a>
<ul>
<li><a href="#Features">Features</a></li>
<li><a href="#Terminology">Terminology</a></li>
</ul>
</li>

<li><a href="#Practice">Practice</a>
<ul>
<li><a href="#PracticeIsolation">Isolation</a></li>
<li><a href="#PracticeResolution">Resolution</a></li>
</ul>
</li>

<li><a href="#Proposal">Proposal</a>
<ul>
<li><a href="#ProposalBinding">Late Binding</a></li>
<li><a href="#ProposalIsolation">Isolation</a></li>
<li><a href="#ProposalResolution">Resolution</a>
    <ul>
    <li><a href="#ProposalSingle">Single Definition</a></li>
    <li><a href="#ProposalMultiple">Multiple Definitions</a></li>
    </ul>
<li><a href="#ProposalLoading">Conditional Loading</a></li>
<li><a href="#ProposalRemoval">Removal</a></li>
</ul>
</li>

<li><a href="#Changes">Changes</a>
<ul>
<li><a href="#intro.compliance">1.4 Implementation compliance
[intro.compliance]</a></li>
<li><a href="#intro.program">1.9(new) The C++ program model
[intro.program]</a></li>
<li><a href="#lex">Chapter 2 Lexical conventions [lex]</a></li>
<li><a href="#basic.def.odr">3.2 One definition rule [basic.def.odr]</a></li>
<li><a href="#basic.link">3.5 Program and linkage [basic.link]</a></li>
<li><a href="#dcl.dcl">Chapter 7 Declarations [dcl.dcl]</a></li>
<li><a href="#class.derived">Chapter 10 Derived classes
[class.derived]</a></li>
</ul>
</li>

</ul>

<h2><a name="Introduction">Introduction</a></h2>

<p>
The construction and use of dynamic libraries
has become a significant requirement on modern software development.
Unfortunately, their interaction with C++
varies between implementations
and is often underspecified on any given implementation.
</p>

<p>
The problem with dynamic libraries in C++ is that
the benefits they provide introduce another layer of visibility.
This additional layer of visibility
is intended to provide for additional isolation,
but is in direct contradiction to the one-definition rule.
</p>

<p>
See the following papers for more complete discussion of the issues.
The latter paper has an extensive set of references.
</p>

<ul>

<li>
<cite>Matt Austern,
<a href="../../papers/2002/n1400.html">N1400</a>
Toward standardization of dynamic libraries</cite>
</li>

<li>
<cite>Pete Becker,
<a href="../../2002/n1418.html">N1418</a>
Dynamic Libraries in C++,
Notes from the Technical Session in Santa Cruz, Oct. 21, 2002</cite>
</li>

<li>
<cite>Benjamin Kosnik,
<a href="../../papers/2006/n1976.html">N1976</a>
Dynamic Shared Objects: Survey and Issues</cite>
</li>

</ul>

<p>
In practice,
programmers are able to work around the contradition
and produce reliable programs.
Changing the standard to recognize and guide existing practice
will markedly improve program construction.
Unfortunately, a coherent change to the standard
may well require changes to some of the C++ ABIs,
and hence should be done as part of the standard
rather than as a Technical Report.
</p>


<h3><a name="Features">Features</a></h3>

<p>
The primary feature of dynamic libraries
is the means to defer the binding of a library interface
to an implementation of that interface
until program execution.
This defered binding provides a number of benefits to a program.
</p>

<ul>

<li>
The program may bind to an implementation of a library
tuned to a particular hardware platform.
For example, a numeric library vendor
may provide different implementations of a library
tuned to specific cache sizes.
</li>

<li>
The program may be updated in parts.
Newer versions of components
may be distributed independently of each other.
This independent update
may be both within a vendor's components
and between components of different vendors.
For example,
a database vendor may update its query interpreter library
independently of the application using the interpreter
and independently of the C run-time library used by the interpreter.
</li>

<li>
The program may gain functionality after distribution
by binding to libraries with functionality not originally anticipated.
The libraries are often called "plug-in" libraries.
One example is the a PDF display plug-in for a web browser.
</li>

</ul>

<p>
The second feature of dynamic libraries is isolation.
Isolation means that
accidents of implementation are not exposed to the users of the library.
That is, the set of bindable symbols provided by the library
is exactly the set of symbols in its interface;
none of the implementation-specific symbols are bindable.
</p>

<p>
The third feature of dynamic libraries is resolution.
Resolution means that
the system can resolve multiple definitions of a symbol.
There are two general strategies for resolution,
dependence and interposition.
More colloquially, these are "the Windows way" and "the Unix way",
respectively.
</p>

<p>
The fourth feature of dynamic libraries is conditional loading.
Conditional loading means that
the name of a dynamic library can be computed at run-time
and then brought into the program.
This feature is also known as "plug-in".
</p>

<p>
The fifth feature of dynamic libraries is removal.
Removal means that
a dynamic library can be taken out of the program.
This process is also known as "closing" a dynamic library.
</p>


<h3><a name="Terminology">Terminology</a></h3>

<p>
We adopt the terminology of
<cite>Matt Austern,
<a href="../../papers/2002/n1400.html">N1400</a>
Toward standardization of dynamic libraries</cite>:
</p>

<dl>

<dt>load unit</dt>
<dd>
A set of translation units linked together by a static linker.
</dd>

<dt>executable</dt>
<dd>
A load unit containing a definition for <code>main</code>.
It is the load unit that the user runs.
</dd>

<dt>dynamic library</dt>
<dd>
A load unit that is not an executable.
</dd>

<dt>program</dt>
<dd>
The executable together with all dynamic libraries
loaded at any one time during execution.
</dd>

<dt>dependences</dt>
<dd>
The load units available to the static linker
to satisfy symbols undefined by load unit being linked.
</dd>

</dl>

<p>
In addition,
we introduce additional terminology
that is necessary to clarify the constraints of dynamic libraries.
</p>

<dl>

<dt>linker symbol</dt>
<dd>
A named function, type, or variable
with external linkage.
(Typedefs are not symbols.)
</dd>

<dt>linker visibility</dt>
<dd>
The visibility of a linker symbol is whether or not it is isolated.
</dd>

<dt>exclusive definition</dt>
<dd>
An object definition that may appear in only one translation unit.
Regular functions have these definitions.
Regular initialized variables have these definitions.
</dd>

<dt>replicable definition</dt>
<dd>
An object definition that may appear in multiple translation units,
provided the definitions are the same.
Inline functions and template functions have these definitions.
Uninitialized variables sometimes have these definitions,
which are also known as tentative definitions.
Class definitions also have these definitions.
</dd>

</dl>


<h2><a name="Practice">Practice</a></h2>

<p>
This section describes some existing practice.
It is not a complete description;
<cite>Benjamin Kosnik,
<a href="../../papers/2006/n1976.html">N1976</a>
Dynamic Shared Objects: Survey and Issues</cite>
provides more details.

<h3><a name="PracticeIsolation">Isolation</a></h3>

<p>
There are several approaches
to the syntax for specifying or retracting isolation for a symbol.
</p>

<dl>

<dt>Microsoft</dt>
<dd>
Symbols are isolated by default.
The declaration specifier
<code>__declspec(dllexport)</code>
specifies that a symbol definition is not isolated.
The declaration specifier
<code>__declspec(dllimport)</code>
specifies that a symbol declaration is satisfied by an non-isolated symbol.
</dd>

<dt>GNU on Unix</dt>
<dd>
Symbols are not isolated by default.
A declaration attribute specifies that a symbol is isolated,
e.g. <code>__attribute__((visibility("hidden")))</code>.
</dd>

<dt>Sun</dt>
<dd>
Default symbol isolation is defined by a command-line option,
with the default of the option being that symbols are not isolated by default.
For a given symbol,
the visibility is specified with a storage class,
e.g. <code>__global</code> or <code>__hidden</code>.
</dd>

<dt>
<cite>Pete Becker,
<a href="../../papers/2003/n1428.html">N1428</a>
/<a href="../../papers/2003/n1496.html">N1496</a>
Draft Proposal for Dynamic Libraries in C++</cite>
</dt>
<dd>
The syntax is only notional, not a formal proposal.
Symbols are isolated by default.
For a given symbol,
the visibility is specified with a storage class,
e.g. <code>shared</code>.
</dd>

<dt>
<cite>Lawrence Crowl,
<a href="../../papers/2006/n2117.html">N2117</a>
Minimal Dynamic Library Support</cite>
</dt>
<dd>
The syntax is hinted as a storage class.
</dd>

</dl>

<p>
In addition to specifying (non-)isolation for a single symbol,
it is convenient to have a syntax for specifying (non-)isolation
for a region of code,
particularly in header files.
There are fewer examples of such syntax.
</p>
<dl>

<dt>GNU on Unix</dt>
<dd>
A pragma can push and pop default visibility.<br>
<code>#pragma GCC visibility push(hidden)<br>
#pragma GCC visibility pop</code><br>
A visibility attribute
may be applied to a block <code>extern</code> declaration.<br>
<code>extern "C++" __attribute__((visibility("hidden"))) { .... }</code>
</dd>

<dt>
<cite>Pete Becker,
<a href="../../papers/2003/n1428.html">N1428</a>
/<a href="../../papers/2003/n1496.html">N1496</a>
Draft Proposal for Dynamic Libraries in C++</cite>
</dt>
<dd>
The syntax is only notional, but the <code>shared</code> storage class
can be placed before a brace-enclosed region,
much like <code>extern&nbsp;"C"</code>.
</dd>

</dl>

<h3><a name="PracticeResolution">Resolution</a></h3>

<p>
There are two primary approaches to resolution of multiple symbol definitions.
</p>

<dl>

<dt>Windows</dt>
<dd>
A reference is bound to the
definition of a symbol in a statically dependent library.
Thus a library may have not have a function replaced by the application.
A consequence is that
a library may not offer replaceable functions without substantial work.
This work is necessary to meet the
application-replaceable semantics of the global allocation operators.
</dd>

<dt>Unix</dt>
<dd>
The first definition of a symbol in the ordered list of load units
is chosen for all references.
That is, the first definition interposes on other definitions.
A consequence is that
a library may have any function replaced by the application.
</dd>
</dl>

<p>
As always, there are complications.
Modern Unix systems provide for "protected" resolution,
in which a reference to a protected symbol
defined within the same load unit
will bind to that definition
irrespective of any prior definitions in the ordered list of load units.
</p>

<p>
Furthermore,
some Unix systems, e.g. Sun and GNU/Linux,
provide the ability to resolve a symbol to a dependent library
in preference to normal interposition resolution.


<h2><a name="Proposal">Proposal</a></h2>

<p>
We propose C++ dynamic library support
that exploits existing operating system facilities
for dynamic libraries.
Furthermore,
we structure that support
so that complexity rises with benefits.
The Committee can choose the features that it needs.
Finally, we specifically avoid trying to solve the whole problem,
concentrating instead on those portions of the problem
that affect large amounts of code.
If an aspect of the program generally only affects a few lines of code,
we leave it to programmers to write platform-specific code.
</p>


<h3><a name="ProposalBinding">Late Binding</a></h3>

<p>
The first feature of dynamic library support is late binding.
Late binding is entirely consistent with the current standard,
and no change is necessary for this feature.
</p>


<h3><a name="ProposalIsolation">Isolation</a></h3>

<p>
The second feature of dynamic library support is isolation.
To enable isolation,
the standard must recognize the load unit
as an intermediate layer of visibility
between a translation unit and the program.
</p>

<p>
Once load units are present,
the standard must provide a mechanism
that specifies whether a symbol is isolated to a load unit
or visible to all load units.
</p>

<p>
The primary mechanism for isolation is and should remain namespaces.
Namespaces provide the best foundation for preventing symbol clashes.
However, namespaces are insufficient for three reasons.
First, they are transparent to functions with C linkage.
Second, they are not sufficient to enable alternate implementations.
Third, they are not robust to an adversarial use of implementation details.
As a consequence, an additional mechanism is necessary.
</p>

<p>
Given a mechanism for isolation,
the standard must admit multiple definitions for the same symbol,
provided that those definitions are isolated from each other.
</p>

<p>
For the isolation syntax,
we propose to avoid introducing a new keyword
and extend the <code>public</code>, <code>protected</code>,
and <code>private</code> labels
to linker visibility for namespace-scoped symbols.
Symbols with <code>public</code> or <code>protected</code> labels
are <em>not</em> isolated.
(The distinction between <code>public</code> and <code>protected</code>
appears later.)
Symbols with a <code>private</code> label
<em>are</em> isolated to a load unit
and are distinct from symbols declared in another load unit.
Specifically, functions and variables have distict addresses
while types have distinct typeids.
</p>

<p>
For class definitions, any meta-data must be isolated as well.
Achieving distinct typeids for isolated types
is most likely to require an implementation
to change the ABI of the language.
</p>

<p>
The member function and static member variable symbols
associated with a class
have the linker visibility of their containing class.
That is, within class definitions,
the labels have their existing <dfn>access-specifier</dfn> meaning.
Furthermore, class member definitions outside of a class definition
ignore the prevailing linker visibility,
and instead use the linker visibility of the class definition.
</p>

<p>
A label within a declarative region
extends to the next label or to the end of the region,
whichever comes first.
Any label in effect immediately before a declarative region
will be in effect immediately after that region.
There are two applicable kinds of declarative regions,
namespace and language linkage.
Programmers can limit the scope of such labels at global scope,
or within a namespace region,
by enclosing them
in language linkage (<code>extern&nbsp;"C++"&nbsp;{&nbsp;}</code>) regions.
For example:
</p>

<blockquote><pre><code>
extern "C++" {
private:
    int my_helper( int a ) { return a+1; }
public:
    int give_me_more( int a ) { return my_helper( a+1 ); }
}
</code></pre></blockquote>

<p>
To assist in migration of existing code,
the linker visibility in effect at the beginning of a translation unit
is implementation-defined.
Within headers,
programmers should place all labels
within a declarative region
so as to preserve the implementation default.
</p>

<p>
We considered using the proposed annotation facility,
<cite>Jens Maurer, Michael Wong,
<a href="../../papers/2007/n2379.pdf">N2379</a>
Towards support for attributes in C++</cite>,
but decided against using it
because the isolation specification
does not meet the "ignorable" criteria for attributes.
That is, removing the isolation indication
would produce ill-formed programs.
</p>


<h3><a name="ProposalResolution">Resolution</a></h3>

<p>
The third feature of dynamic library support is
resolution of symbol references to multiple definitions.
This topic is somewhat complicated,
and we approach it via relaxing restrictions.
</p>


<h4><a name="ProposalSingle">Single Definition</a></h4>

<p>
The simplest proposal is the most restrictive;
define multiple definitions of non-isolated symbols as an error.
</p>

<p>
Because existing dynamic linker technology
has only one category of definition,
any replicable definition appears as though
there were multiple exclusive definitions.
Therefore, the simplest standard
would simply prohibit non-isolated replicable definitions.
A consequence is that the standard library 
would need careful thought
as to which parts were applicable to a shared dynamic library
and which parts were applicable to a replicated static library.
</p>

<p>
A more usable standard would support non-isolated replicable definitions
provided that the definitions are identical.
Doing so is not conceptially difficult;
the primary problem is choosing a unique address or typeid.
The dynamic linker can simply choose one of the definition artifacts.
The existing Unix interposition resolution approach
meets these semantics exactly.
The existing Windows dependence resolution approach poses a problem,
normally yielding different addresses within different load units.
Potential solutions to this require
each library obtain addresses from a shared table
or to simply live with different addresses
for what are conceptually the same function.
Programmers rarely rely on inline functions having identical addresses;
more problematic is identical typeids for exception handling.
</p>


<h4><a name="ProposalMultiple">Multiple Definitions</a></h4>

<p>
When multiple definitions are available for exclusive definitions,
the implementation must resolve references to definitions.
Unfortunately,
neither the Unix approach nor the Windows approach
appears to fully solve the problem.
The Unix interposition approach
leaves programs vunerable to inconsistent definitions
when functions are both inlined and interposed.
The Windows dependence approach prevents the interposition
needed for the global allocation operators
and other similar behavior.
To resolve this issue,
we propose to "do both".
</p>

<p>
Syntactically, we refine the label syntax introduced above for isolation.
Semantically, we leave much implementation-defined
because detailed specification of compile and link commands
is beyond the scope of the standard.
</p>

<ul>

<li>
A symbol declared with the label <code>public</code>
has interposition semantics.
All references to a <code>public</code> symbol
will resolve to a single definition within the program.
The selection of definition is otherwise implementation-defined.
</li>

<li>
A symbol declared with the label <code>protected</code>
has dependence semantics.
A load unit's reference to a <code>protected</code> symbol
will resolve to a definition
either in the current load unit
or, failing that,
in one of its dependences.
The selection of definition is otherwise implementation-defined.
</li>

</ul>

<p>
For example, and by way of illustration,
the standard library would have the following declarations.
</p>

<blockquote><pre><code>
namespace std {
    typedef void (*new_handler)();
protected:
    new_handler set_new_handler( new_handler ) throw();
}
extern "C++" {
public:
    void * operator new( std::size_t ) throw( std::bad_alloc );
}
</code></pre></blockquote>

<p>
The primary problem with different replicable definitions
is that current linker technology
is unable to determine that two definitions are replicants of each other.
Furthermore, replicants are often involved in inlining,
and a non-inline call with different semantics from an inline expansion
is bound to cause inconsistency and potentially failure.
Therefore, we propose to prohibit <code>public</code> replicable definitions.
</p>

<p>
Furthermore, because replicable definitions are "baked in" to the object code,
we propose to require that any use of a protected extern replicable definition
have "the same" definition in all dependent libraries.
</p>


<h3><a name="ProposalLoading">Conditional Loading</a></h3>

<p>
The fourth feature of dynamic library support is conditional loading.
In terms of isolation and resolution,
conditional loading introduces no new issues.
The two new issues are initialization and destruction order
for static-duration variables
and finding a root symbol for the library.
</p>

<p>
We believe that the order of initialization and destruction
as defined in
<cite>Lawrence Crowl,
<a href="../../papers/2007/n2382.html">
N2382</a> Dynamic Initialization and Destruction with Concurrency</cite>
provides for sufficiently late execution of initializers
to admit conditional loading.
</p>

<p>
Finding the root symbol on a library
generally involves converting a string
containing some form of the symbol name
into an address.
As this code has low static frequency,
we choose to not standardize it.
Programmers will need to specialize their code
for each supported platform.
</p>


<h3><a name="ProposalRemoval">Removal</a></h3>

<p>
The fifth feature of dynamic library support is library removal.
This feature is also known as closing a dynamic library.
The implications on order of destruction
of static-duration and thread-duration variables
could be severe.
So, rather than try to define a precise meaning,
we intend to provide advice to programmers
on how to avoid the problems.
In particular,
</p>

<ul>

<li>
Programmers shall terminate all threads
that reference a thread-duration variable defined within a load unit
before removing that load unit from the program.
In practice, this means that a library
intended to be conditionally loadable
should only use thread-duration variables
in threads that it creates
and then terminates before removal.
</li>

<li>
Programmers shall ensure that no static-duration variable
is referenced from outside the removable load unit.
In practice, this means that
all variables in removable libraries
have <code>private</code> visibility
and that the library does not pass their addresses
outside of the library.
</li>

</ul>

<p>
As code to remove a dynamic library also has low static frequency,
so we chose to not standardize it.
Programmers will need to specialize their code
for each supported platform.
</p>


<h2><a name="Changes">Changes</a></h2>

<p>
The base document for these changes is
<cite>Pete Becker,
<a href="../../papers/2007/n2369.pdf">N2369</a>
Working Draft, Standard for Programming Language C++</cite>.

<p>
The extent of those changes depends on
which features the committee chooses to support.
The paper covers core language changes only,
leaving standard library changes to a separate paper.
</p>

<h3><a name="intro.compliance">1.4 Implementation compliance
[intro.compliance]</a></h3>

<p>
Edit paragraph 6 as follows:
</p>

<blockquote>
<p>
The templates, classes, functions, and objects in the library
have external linkage (3.5).
The implementation provides definitions
for standard library entities, as necessary,
while combining translation units to form a complete C++ program
<del>(2.1)</del> <ins>(1.9)</ins>.
</p>
</blockquote>

<h3><a name="intro.program">1.9(new) The C++ program model
[intro.program]</a></h3>

<p>
Add a new section
between "1.8 The C++ object model [intro.object]"
and the existing "1.9 Program execution [intro.execution]"
with the following paragraphs.
</p>

<blockquote>

<p>
<ins>
The text of the program is kept in units
called <dfn>source files</dfn> in this International Standard.
A source file together with all the headers (17.4.1.2) and source files
included (16.2) via the preprocessing directive <code>#include</code>,
less any source lines skipped
by any of the conditional inclusion (16.1) preprocessing directives,
is called a <dfn>translation unit</dfn>.
</ins>
</p>

<p>
<ins>
A <dfn>load unit</dfn> is a set of translation units.
A load unit may be either an <dfn>executable</dfn>,
which contains a definition for <code>main</code>,
or a <dfn>dynamic library</dfn>,
which does not contain a definition for <code>main</code>.
[ <i>Note:</i>
The separate translation units of a load unit communicate (3.5)
by (for example) calls to functions
whose identifiers have external linkage,
manipulation of objects whose identifiers have external linkage,
or manipulation of data files.
Translation units can be separately translated
and then later linked to produce an load unit (3.5).
A load unit is typically bound at program development time.
<i>&mdash; end note</i> ]
</ins>
</p>

<p>
<ins>
A <dfn>program</dfn> is a set of load units.
Each program may consist of one executable and zero or more dynamic libraries.
[ <i>Note:</i>
The separate load units of a program communicate (3.5)
by (for example)
calls to functions
whose identifiers have external linkage and are not isolated,
manipulation of objects
whose identifiers have external linkage and are not isolated,
or manipulation of data files.
Load units can be separately statically linked,
and then later dynamically linked together in an executing program (3.5).
That is, programs may not be bound until execution.
<i>&mdash; end note</i> ]
</ins>
</p>

</blockquote>

<h3><a name="lex">Chapter 2 Lexical conventions [lex]</a></h3>

<p>
Delete paragraph 1:
</p>

<blockquote>
<p>
<del>The text of the program is kept in units
called <dfn>source files</dfn> in this International Standard.
A source file together with all the headers (17.4.1.2) and source files
included (16.2) via the preprocessing directive <code>#include</code>,
less any source lines skipped
by any of the conditional inclusion (16.1) preprocessing directives,
is called a <dfn>translation unit</dfn>.
[ <i>Note:</i>
a C++ program need not all be translated at the same time.
<i>&mdash; end note</i> ]</del>
</p>
</blockquote>

<p>
Delete paragraph 2:
</p>

<blockquote>
<p>
<del>[ <i>Note:</i>
previously translated translation units and instantiation units
can be preserved individually or in libraries.
The separate translation units of a program communicate (3.5)
by (for example) calls to functions
whose identifiers have external linkage,
manipulation of objects whose identifiers have external linkage,
or manipulation of data files.
Translation units can be separately translated
and then later linked to produce an executable program (3.5).
<i>&mdash; end note</i> ]</del>
</p>
</blockquote>

<p>
Insert a new paragraph 1:
</p>

<blockquote>
<p>
<ins>[ <i>Note:</i>
this clause presents the lexical interpretation of C++ source files.
It describes the <dfn>phases of translation</dfn>,
the <dfn>character sets</dfn>,
and the resulting <dfn>tokens</dfn>.
<i>&mdash; end note</i> ]</ins>
</p>
</blockquote>

<h3><a name="basic.def.odr">3.2 One definition rule [basic.def.odr]</a></h3>

<p>
Edit paragraph 3:
</p>

<blockquote>
<p>
Every <del>program</del> <ins>load unit</ins>
shall contain exactly one definition
of every <ins>isolated</ins> non-inline function
or <ins>isolated</ins> object
that is used in that <del>program</del> <ins>load unit</ins>;
no diagnostic required.
The definition can appear explicitly in the program,
<del>it can be found in the standard or a user-defined dynamic library,</del>
or (when appropriate) it is implicitly defined (see 12.1, 12.4 and 12.8).
An inline function shall be defined
in every translation unit in which it is used.
</p>
</blockquote>

<p>
Split and edit paragraph 5 as follows:
</p>

<blockquote>
<p>
<del>There can be more than one</del> <ins>A</ins> definition of a
class type (clause 9),
enumeration type (7.2),
inline function with external linkage (7.1.2),
class template (clause 14),
non-static function template (14.5.6),
static data member of a class template (14.5.1.3),
member function of a class template (14.5.1.1),
or template specialization
for which some template parameters are not specified (14.7, 14.5.5)
<ins>is a <dfn>replicable definition</dfn>.
Other functions and objects have <dfn>exclusive definitions</dfn>.</ins>
</p>

<p>
<ins>
There may be more than one replicable definition for an entity</ins>
in a <del>program</del> <ins>load unit</ins>
provided that each definition appears in a different translation unit,
and provided the definitions satisfy the following requirements.
Given such an entity named <code>D</code>
defined in more than one translation unit,
then
<ul>
<li>
each definition of <code>D</code>
shall consist of the same sequence of tokens; and
</li>
<li>
in each definition of <code>D</code>,
corresponding names, looked up according to 3.4,
shall refer to an entity defined within the definition of <code>D</code>,
or shall refer to the same entity,
after overload resolution (13.3)
and after matching of partial template specialization (14.8.3),
except that a name can refer to a const object with internal or no linkage
if the object has the same literal type
in all definitions of <code>D</code>,
and the object is initialized with a constant expression (5.19),
and the value (but not the address) of the object is used,
and the object has the same value in all definitions of <code>D</code>; and
</li>
<li>
in each definition of <code>D</code>,
the overloaded operators referred to,
the implicit calls to
conversion functions, constructors,
operator new functions and operator delete functions,
shall refer to the same function,
or to a function defined within the definition of <code>D</code>; and
</li>
<li>
in each definition of <code>D</code>,
a default argument used by an (implicit or explicit) function call
is treated as if its token sequence were present
in the definition of <code>D</code>;
that is,
the default argument is subject to the three requirements described above
(and, if the default argument has sub-expressions with default arguments,
this requirement applies recursively).25)
</li>
<li>
if <code>D</code> is a class with an implicitly-declared constructor (12.1),
it is as if the constructor was implicitly defined
in every translation unit where it is used,
and the implicit definition in every translation unit
shall call the same constructor
for a base class or a class member of <code>D</code>.
[ <i>Example:</i>
<blockquote>
<pre><code>
// translation unit 1:
struct X {
X(int);
X(int, int);
};
X::X(int = 0) { }
class D: public X { };
D d2; // X(int) called by D()

// translation unit 2:
struct X {
X(int);
X(int, int);
};
X::X(int = 0, int = 0) { }
class D: public X { }; // X(int, int) called by D();
// D()'s implicit definition
// violates the ODR
</code></pre>
</blockquote>
<i>&mdash; end example</i> ]
If <code>D</code> is a template,
and is defined in more than one translation unit,
then the last four requirements from the list above
shall apply to names from the template's enclosing scope
used in the template definition (14.6.3),
and also to dependent names at the point of instantiation (14.6.2).
If the definitions of <code>D</code> satisfy all these requirements,
then the program shall behave as if
there were a single definition of <code>D</code>.
If the definitions of <code>D</code> do not satisfy these requirements,
then the behavior is undefined.
</ul>
</blockquote>

<h3><a name="basic.link">3.5 Program and linkage [basic.link]</a></h3>

<p>
Edit paragraph 1:
</p>

<blockquote>
<p>
A program consists of one or more <ins>load units;
a load unit consists of one or more</ins> translation units
<del>(clause 2)</del> <ins>(1.9)</ins> <del>linked together</del>.
A translation unit consists of a sequence of declarations.
</p>
<blockquote>
<dl>
<dt><var>translation-unit:</var></dt>
<dd><var>declaration-seq<sub>opt</sub></var></dd>

<dt><ins><var>declaration-seq:</var></ins></dt>
<dd><ins><var>declaration</var>
<var>declaration-seq<sub>opt</sub></var></ins></dd>
<dd><ins><var>visibility-specifier</var> <code>:</code>
<var>declaration-seq<sub>opt</sub></var></ins></dd>

<dt><ins><var>visibility-specifier:</var></ins></dt>
<dd><ins><var>ppp-label</var></ins></dd>
</dl>
</blockquote>
</blockquote>

<p>
Add a new paragraph.
</p>

<blockquote>
<ins>A name with external linkage can be</ins>
<dl>

<dt><ins><code>private</code></ins></dt>
<dd><ins>that is,
its name can be used only by definitions
within the load unit in which the name declared;</ins>
</dd>

<dt><ins><code>protected</code></ins></dt>
<dd><ins>that is,
its name can be used by definitions
within load units that depend on the load unit with the name's definition;
and</ins>
</dd>

<dt><ins><code>public</code></ins></dt>
<dd><ins>that is,
its name can be used anywhere without access restriction.</ins>
</dd>
</dl>
</blockquote>

<p>
Add a new paragraph:
</p>

<blockquote>
<p>
<ins>Declarations can be labeled by an <var>visibility-specifier</var>:</ins>
</p>
<blockquote>
<p>
<ins><var>visibity-specifier</var>
<code>:</code>
<var>declaration-seq<sub>opt</sub></var></ins>
</p>
</blockquote>
<p>
<ins>An <var>visibility-specifier</var> specifies the
linker visibility
for declarations following it until the end of the
scope region
<var>namespace-body</var>
or until another <var>visibility-specifier</var>
is encountered.</ins>
</p>

<p>
<ins>Any number of access specifiers is allowed and no particular order is required.</ins>
</p>

<p>
<ins>When a name is redeclared,
the linkage visiblity remains that of its its initial declaration.</ins>
</p>

</blockquote>


<h3><a name="dcl.dcl">Chapter 7 Declarations [dcl.dcl]</a></h3>

<p>
Edit paragraph 1:
</p>

<blockquote>
<p>
Declarations specify how names are to be interpreted.
Declarations have the form
</p>
<blockquote>
<dl>

<dt><del><var>declaration-seq:</var></del></dt>
<dd><del><var>declaration</var></del></dd>
<dd><del><var>declaration-seq declaration</var></del></dd>

<dt><var>declaration:</var></dt>
<dd><var>block-declaration</var></dd>
<dd><var>function-definition</var></dd>
<dd><var>template-declaration</var></dd>
<dd><var>explicit-instantiation</var></dd>
<dd><var>explicit-specialization</var></dd>
<dd><var>linkage-specification</var></dd>
<dd><var>namespace-definition</var></dd>

<dt><var>block-declaration:</var></dt>
<dd><var>simple-declaration</var></dd>
<dd><var>asm-definition</var></dd>
<dd><var>namespace-alias-definition</var></dd>
<dd><var>using-declaration</var></dd>
<dd><var>using-directive</var></dd>
<dd><var>static_assert-declaration</var></dd>
<dd><var>alias-declaration</var></dd>

<dt><var>alias-declaration:</var></dt>
<dd><code>using</code> <var>identifier</var>
<code>=</code> <var>type-id</var></dd>

<dt><var>simple-declaration:</var></dt>
<dd><var>decl-specifier-seq<sub>opt</sub>
init-declarator-list<sub>opt</sub></var> <code>;</code></dd>

<dt><var>static_assert-declaration:</var></dt>
<dd><code>static_assert (</code>
<var>constant-expression</var> <code>,</code>
<var>string-literal</var> <code>) ;</code></dd>
</dl>
</blockquote>

<p>
[ <i>Note:</i>
<var>asm-definition</var>s are described in 7.4,
and <var>linkage-specification</var>s are described in 7.5.
<var>Function-definition</var>s are described in 8.4
and <var>template-declaration</var>s are described in clause 14.
<var>Namespace-definition</var>s are described in 7.3.1,
<var>using-declaration</var>s are described in 7.3.3
and <var>using-directive</var>s are described in 7.3.4.
&mdash; <i>end note</i> ]
The <var>simple-declaration</var>
</p>
<blockquote>
<p>
<var>decl-specifier-seq<sub>opt</sub>
init-declarator-list<sub>opt</sub></var>  <code>;</code>
</p>
</blockquote>
<p>
is divided into two parts:
<var>decl-specifier</var>s,
the components of a <var>decl-specifier-seq</var>, are described in 7.1
and <var>declarator</var>s,
the components of an <var>init-declarator-list</var>, are described in clause 8.
</p>
</blockquote>

<h3><a name="class.derived">Chapter 10 Derived classes [class.derived]</a></h3>

<p>
Within paragraph 1, edit the grammar as follows:
</p>

<blockquote>
<dl>
<dt><var>access-specifier:</var></dt>
<dd><var>ppp-label</var></dd>

<dt><var>ppp-label:</var></dt>
<dd><code>private</code></dd>
<dd><code>protected</code></dd>
<dd><code>public</code></dd>
</dl>
</blockquote>

</body>
</html>
