<html xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:w="urn:schemas-microsoft-com:office:word"
xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
<meta name=ProgId content=Word.Document>
<meta name=Generator content="Microsoft Word 9">
<meta name=Originator content="Microsoft Word 9">
<link rel=File-List href="./FGW1rev_files/filelist.xml">
<title>Doc No: SC22/WG21/N</title>
<style>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0mm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	tab-stops:36.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-ansi-language:EN-US;}
h3
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0mm;
	margin-bottom:3.0pt;
	margin-left:0mm;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:3;
	tab-stops:36.0pt;
	font-size:13.0pt;
	font-family:Arial;
	mso-ansi-language:EN-US;
	font-weight:bold;}
p
	{margin:0mm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	tab-stops:36.0pt 72.0pt 116.25pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-ansi-language:EN-GB;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:36.0pt;
	mso-footer-margin:36.0pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
@list l0
	{mso-list-id:342905160;
	mso-list-type:hybrid;
	mso-list-template-ids:309084188 -113051988 -1018382236 1443274682 556440052 -1653423772 -815625006 -11213888 -1174402890 -1622128926;}
@list l1
	{mso-list-id:858391172;
	mso-list-type:hybrid;
	mso-list-template-ids:2000316844 -1987383148 166856036 973269680 -453229756 355871520 -1188669002 545567672 832198838 -1129919658;}
ol
	{margin-bottom:0mm;}
ul
	{margin-bottom:0mm;}
-->
</style>
</head>

<body lang=EN-US style='tab-interval:36.0pt'>

<div class=Section1>

<p><span lang=EN-GB style='font-size:10.0pt'>Doc No: SC22/WG21/N1445=03-0027<o:p></o:p></span></p>

<p><span lang=EN-GB style='font-size:10.0pt'>Project: JTC1.22.32<o:p></o:p></span></p>

<p><span lang=EN-GB style='font-size:10.0pt'>Date: Tuesday, January 21, 2003;
revised February 25, 2003<o:p></o:p></span></p>

<p style='tab-stops:36.0pt 72.0pt 116.25pt 137.25pt'><span lang=EN-GB
style='font-size:10.0pt'>Author: Francis Glassborow<span style='mso-tab-count:
1'> </span><o:p></o:p></span></p>

<p><span lang=EN-GB style='font-size:10.0pt'>email:
francis@robinton.demon.co.uk<o:p></o:p></span></p>

<p><b><span lang=EN-GB style='font-size:18.0pt;font-family:Arial'>Class
defaults<o:p></o:p></span></b></p>

<h3>1 The Problems</h3>

<p><span lang=EN-GB>This is a set of proposals aimed at making several aspects
of class definitions easier to teach and use, and more explicit. They also
reduce the amount of (often redundant) code which must be written by the
programmer, and therefore reduce the chance of introducing errors. </span></p>

<p><span lang=EN-GB>Currently we have no mechanism for forwarding from one
constructor to another in the same class -- all initialisation code must be
repeated in each constructor (or factored into a subsidiary function). Similarly,
a derived class has no mechanism for reusing base class constructors other than
by explicitly defining analogous constructors and forwarding their arguments to
the base class in an initialiser list. </span></p>

<p><span lang=EN-GB>In addition the current compiler generated default
destructor for classes with virtual members is non-virtual. It is generally
advised that any class intended to be used as a base for inheritance -- a
reasonable assumption if it contains a virtual function -- should have a
virtual destructor to prevent memory leaks and other errors that might result
from incomplete destruction of classes derived from it. So why shouldn't the
compiler default to &quot;doing the right thing&quot;?</span></p>

<p><span lang=EN-GB>Itemised list:</span></p>

<ol start=1 type=1>
 <ol start=1 type=1>
  <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l1 level2 lfo3;tab-stops:list 72.0pt'><span lang=EN-GB
      style='mso-ansi-language:EN-GB'>The declaration of a copy constructor in
      order to inhibit copy semantics also inhibits automatic generation of a
      default constructor. If one is required, it must be explicitly defined.<o:p></o:p></span></li>
  <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l1 level2 lfo3;tab-stops:list 72.0pt'><span lang=EN-GB
      style='mso-ansi-language:EN-GB'>Changing the compiler generated
      destructor to virtual for classes with virtual members affects binary
      compatibility of existing code. If such classes require a non-virtual
      destructor (especially for backward compatibility in code for COM and
      CORBA) then an easy way to overrule the new default is necessary.<o:p></o:p></span></li>
  <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l1 level2 lfo3;tab-stops:list 72.0pt'><span lang=EN-GB
      style='mso-ansi-language:EN-GB'>A class derived from a base with several
      constructors has to re-declare and define new constructors, which adds to
      maintenance where the base class constructors are essentially
      satisfactory.<o:p></o:p></span></li>
  <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l1 level2 lfo3;tab-stops:list 72.0pt'><span lang=EN-GB
      style='mso-ansi-language:EN-GB'>There is no way currently to forward from
      one constructor of a class to another. Sometimes the intent can be
      achieved via default parameters but this can force an unnatural parameter
      ordering.<o:p></o:p></span></li>
 </ol>
</ol>

<h3>2. Discussion</h3>

<p><span lang=EN-GB>2.1 Compiler generation of special member functions.</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>class base
{<span style='mso-tab-count:1'> </span></span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>public:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>base(int
i, double d);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>base(int
i);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>base(double
d);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>virtual
foo();</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>private:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>double
d_;</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>int
i_;</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>};</span></p>

<p><span lang=EN-GB>Purely in the context of the above definition the compiler
will generate perfectly useable definitions of the copy ctor, copy assignment
operator and [non-virtual] dtor. However the programmer will have to write
explicit definitions for each of the three provided ctors. Using default
parameters could absorb the third ctor into the first but still does not
provide a mechanism for the second. That is an inconsistency because it makes
the order of declaration of parameters significant. In addition the newcomer
from Java will almost certainly try to use the Java technique for forwarding
between ctors. That will compile but silently do something quite different from
the programmer's expectations.</span></p>

<p><span lang=EN-GB>In addition we do not have a way of making explicit that
the compiler will generate three functions (copy ctor, copy assignment and
dtor). Good coding practice is to make all behaviour explicit and 'by code' is
to be preferred to 'by comment'.</span></p>

<p><span lang=EN-GB>Good implementation tools might warn the programmer that
s/he needs a virtual dtor. Good, but newcomers will just be confused by such a
statement. Having got them to realise they need to write:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>virtual
~base();</span></p>

<p><span lang=EN-GB>They will be further irritated by the requirement to
provide a definition. Now we find ourselves either placing a trivial definition
out of line or entering into debate as to the desirability of in class
definitions.</span></p>

<p><span lang=EN-GB>The proposals that follow remove all those problems and
allow all programmers to explicitly state their intention in code. We will be
able to write:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>class base
{</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>public:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>base(int
i, double d);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>base(int
i);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>base(double
d);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>virtual
foo();</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>default
~base();</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>default
base(base const &amp;);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>default
operator= (base const &amp;);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>private:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>double
d_;</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>int
i_;</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>};</span></p>

<p><span lang=EN-GB>And define two of the ctors in terms of the first:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>base::base(int
i): base(i, 0.0){};</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>base::base(double
d): base(0, d){};</span></p>

<p><i><span lang=EN-GB><span style="mso-spacerun: yes"></span></span></i><span
lang=EN-GB>Being able to declare that the default compiler-generated dtor is
explicitly wanted opens the way to changing the rule on what the compiler will
generate. If the class definition includes any virtual functions, the
compiler-generated default dtor will be virtual. For cases where the programmer
explicitly wants a non-virtual compiler-generated dtor, the syntax above
expresses that. Access specifiers can be applied to default declarators in the
usual way.</span></p>

<p><span lang=EN-GB>In addition we can consider adding syntax to allow an
explicit statement that the compiler is NOT to generate a default copy ctor or
copy assignment operator. That will plug the hole where the current idiom fails
(the compiler allows a call to a copy ctor in a class scope definition, but
then optimises it away so the linker never gets to detect the lack of a
definition) That would support a class definition such as:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>class
objectbase {</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>public:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>objectbase(int
i, double d);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>explicit
objectbase(int i);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>explicit
objectbase(double d);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>virtual
foo();</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>default
virtual ~objectbase(); <i><o:p></o:p></i></span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>not
default objectbase(objectbase const &amp;);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>not
default operator= (objectbase const &amp;);</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>private:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>double
d_;</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>int
i_;</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>};</span></p>

<p><span lang=EN-GB>Note that we no longer have to worry about placing
declarations in the private interface  which is conceptually wrong because
they define the public behaviour of the class. The above syntax should make
class design easier to teach, as well, since the novice no longer would have to
learn the non-intuitive rule that one prevents copying and assignment by
declaring the existence of functions for copying and assignment (and then not
defining them). The statement of intent becomes part of the code instead of a
comment. Errors of unintentionally calling the supposed-to-be-suppressed
functions could be diagnosed by the compiler instead of waiting until link time
(and receiving a hard-to-interpret error).</span></p>

<p><span lang=EN-GB>2.2 Inheriting base class constructors</span></p>

<p><span lang=EN-GB>Consider:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>class
derived : public base {</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>};</span></p>

<p><span lang=EN-GB>Currently the programmer has to duplicate all the base
class ctors even if there is no extra data and inheritance is merely being used
to provide an overrider for the virtual function or to provide extra functionality.
Worse is that it provides a maintenance problem because the writer of derived
has to track the ctors provided by the base even though the implementation of
the base is of no interest to him/her.</span></p>

<p><span lang=EN-GB>Very curiously the class has an implicit copy ctor, copy
assignment operator and a non-virtual dtor.</span></p>

<p><span lang=EN-GB>Derived classes that only add functionality are quite
common in the field (though perhaps not so common in the code of expert C++
programmers). I believe we need to provide syntax to support automatic forwarding
from derived class ctors to base class ones. The apparently obvious extension
of</span><span lang=EN-GB style='font-family:"Courier New"'> using </span><span
lang=EN-GB>unfortunately has been compromised by the existing rules about
access (a public using declaration makes protected base class functions public
in the derived class). Protected functions inherited from a base class are
implicitly protected in the derived class; the same principle should apply to
constructors.</span></p>

<p><span lang=EN-GB>Therefore my proposal is for a syntax that will allow the
programmer to write:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>class
derived : public base {</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>public:</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:2'> </span>default
derived = base;</span></p>

<p><span lang=EN-GB><span style='mso-tab-count:1'> </span>};</span></p>

<p><span lang=EN-GB>If the derived class ctor needs to initialise members of
the derived class, or to perform some other processing in its ctor, it can
declare a ctor in the usual way and pass appropriate arguments to the base
class in an initialiser list before entering the body of the derived ctor. If
the declaration of the derived ctor exactly matches one inherited from the base
class, the declared function supersedes the inherited one.</span></p>

<h3>3 The Proposals</h3>

<ol start=1 type=1>
 <ol start=1 type=1>
  <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l0 level2 lfo6;tab-stops:list 72.0pt'><span lang=EN-GB
      style='mso-ansi-language:EN-GB'>The </span><span lang=EN-GB
      style='font-family:"Courier New";mso-ansi-language:EN-GB'>default</span><span
      lang=EN-GB style='mso-ansi-language:EN-GB'> keyword be used to support
      explicit declaration of a member function as one whose definition is to
      be compiler generated. In the first instance this should apply to the
      four members that can currently be compiler generated. Others might see
      this as an opportunity to extend explicit compiler generation to other
      common functions but that is not a direct part of this proposal.<o:p></o:p></span></li>
 </ol>
</ol>

<p style='margin-left:72.0pt'><span lang=EN-GB>A member declared as default
will be compiler generated even if implicit generation would have been
suppressed by the existence of another potentially overloading declaration:</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>class example {</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>example(example
const &amp;);</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>public:</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>default
example(); //compiler will generate default ctor</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>default
operator =; //compiler will generate default assignment</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>default
~example(); // compiler will generate destructor</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>};</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>Code generation takes place at
the point of explicit declaration. If the function is never used in the
program, it can be optimised out under the as-if rule. If compiler generation
is not possible (because of a reference or const data member, for example), a
diagnostic results (currently you only get a diagnostic on the implicit
function if you actually use it.) The code generated by the compiler is the
same as at present.</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>Otherwise the rules for when and
how the explicit default functions are generated should be exactly as they are
now for the implicit generation (only at need and inline).</span></p>

<ol start=1 type=1>
 <ol start=2 type=1>
  <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l0 level2 lfo6;tab-stops:list 72.0pt'><span lang=EN-GB
      style='mso-ansi-language:EN-GB'>A class without a base that contains at
      least one virtual member shall generate a virtual destructor unless a
      destructor be explicitly declared. Optionally this destructor may be
      declared as default with or without virtual qualification and will then
      be generated as specified.<o:p></o:p></span></li>
 </ol>
</ol>

<p style='margin-left:72.0pt'><span lang=EN-GB>Note that this proposal does
introduce silent change and needs to be closely examined. However I (as the
proposer) believe that we should not just ignore the issue even if we
eventually come down on the side of the status quo. Quite a number of
experienced C++ programmers have been bitten by the problem that a polymorphic
base needs an explicitly declared virtual dtor.</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>A default pure virtual
destructor shall be both generated and require overriding in any derived
concrete class. Thus, default ~example() = 0;</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>would not require the programmer
to define an empty destructor body out of line simply to enable objects to be
deleted through a pointer to their base class. A new syntax of the form:</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>default derived = base;</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>be introduced that imports all
the base class constructors to the derived class. The access in the derived
class is the same as that of the access in the base class. Such a declaration
shall be ill formed if the base class has a private constructor, or if the
derived class has more than one direct base, or if the inheritance graph
contains any virtual bases.</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>Where this declaration is made,
additional constructors may also be provided. Where such an additional constructor
matches an imported constructor the additional one shall supersede the imported
one.</span></p>

<p style='margin-left:72.0pt'><span lang=EN-GB>This feature should be useful in
generic programming, as a template could use its template parameter as a base
class and automatically inherit all of its constructors.</span></p>

<ol start=1 type=1>
 <ol start=3 type=1>
  <li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:
      auto;mso-list:l0 level2 lfo6;tab-stops:list 72.0pt'><span lang=EN-GB
      style='mso-ansi-language:EN-GB'>A new syntax shall be provided for
      constructor definitions wherein the constructor initialiser list is
      permitted to consist of a single constructor call to a constructor of the
      same type. Where the forwarding ctor has a non-empty body the body of the
      called ctor shall be first executed followed by the body of the
      forwarding ctor.<o:p></o:p></span></li>
 </ol>
</ol>

<p style='margin-left:36.0pt'><span lang=EN-GB>For example:</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB>class mytype {</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>int
i;</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>double
d;</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>std::string
s;</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB>public:</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>mytype(int
ival, double dval): i(ival), d(dval) {s = &quot;ctor 1&quot;;}</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>explicit
mytype(int ival): mytype(ival, 0.0){ s = &quot;ctor 2&quot;;}</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>explicit
mytype(double dval): mytype(0, dval){ s = &quot;ctor 3&quot;;}</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>mytype():
mytype(0, 0.0){ s = &quot;ctor 4&quot;;}</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>default
mytype(mytype const &amp;);</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>default
operator =;</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>default
~mytype();</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB>}; </span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB>Therefore, </span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>mytype
m;</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB>results in the following
sequence of events:</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>i(0);</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>d(0.0);</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>s(&quot;&quot;);
// default string ctor</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>//
enter forwarded body</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>s
= &quot;ctor1&quot;;</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>//
enter forwarding body</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB><span style='mso-tab-count:1'> </span>s
= &quot;ctor4&quot;;</span></p>

<p style='margin-left:36.0pt'><span lang=EN-GB>&nbsp;</span></p>

<p><b><span lang=EN-GB style='font-size:13.5pt;font-family:Arial'>Changes to
the Working Paper<o:p></o:p></span></b></p>

<p><span lang=EN-GB>These are not provided at this point. It seems more important
to agree to the general principles. <i><o:p></o:p></i></span></p>

</div>

</body>

</html>
