NS/main/source/stlport/doc/release_notes.html
Karl 8552ac617c Import from old repository
git-svn-id: https://unknownworlds.svn.cloudforge.com/ns1@1 67975925-1194-0748-b3d5-c16f83f1a3a1
2005-03-09 01:31:56 +00:00

176 lines
No EOL
12 KiB
HTML

<html><head><META http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>STLport: Release Notes</title><link href="doc.css" type="text/css" rel="stylesheet"></head><body marginwidth="0" marginheight="0" leftmargin="0" topmargin="0" vlink="#314A30" link="#314A30" text="black" bgcolor="white"><table border="0" cellspacing="0" cellpadding="0"><tr valign="top" align="left"><td width="24"><img src="images/trans.gif" border="0" height="1" width="24"></td><td width="776"><img border="0" height="14" width="1" src="images/trans.gif"><br><a href="../index.html"><img src="images/stl_logo_doc.gif" border="0" height="80" width="80"></a><a href="http://www.stlport.com"><img border="0" height="80" width="461" src="images/t_doc2.gif"></a><br><img src="images/trans.gif" border="0" height="24" width="1"><br><img src="images/black.gif" border="0" height="1" width="776"><br><img src="images/trans.gif" border="0" height="24" width="1"></td></tr><tr valign="top" align="left"><td width="24"><img src="images/trans.gif" border="0" height="1" width="24"></td><td width="776"><img src="images/trans.gif" border="0" height="10" width="776"></td></tr><tr valign="top" align="left"><td width="24"><img src="images/trans.gif" border="0" height="1" width="24"></td><td width="776">
<span class="heading">STLport 4.5 Release Notes</span>
<p>
Please see etc/ChangeLog for the list of changes since 4.0.
A number of new platforms are supported; STLport iostreams ported to many new platforms.
4.5 should provide for much greater reliability and efficiency, especially in iostreams part.
Code bloat should be significantly reduced. Versioning is introduced for dynamic libraries.
</p>
<span class="heading">STLport 4.0 Release Notes</span>
<p>
STLport 4.0 is a major release. Finally, it offers complete C++ standard library!
Here is a list of major changes in 4.0 :
<ul>
<li>Complete ANSI C++ standard library, including &lt;complex&gt; and SGI iostreams.</li>
<li>Can be configured to use either SGI or native iostreams.</li>
<li>Debug mode completely redesigned. Debug mode containers are
implemented in terms of wrappers around non-debug ones.
That provides for more clean and efficient implementation.
In Debug Mode, different namespace <b>_STLD::</b> is being used,
so no link-time clashes between debug and non-debug versions are possible.</li>
<li>New platforms - gcc-2.95, Mingw32, Borland C++ Builder 5.5, SUN CC 6.0 Early Access, SUN CC in compatibility mode.</li>
</ul>
Minor changes:
<ul>
<li> std:: is not used for STLport namespace even with SGI iostreams,
to avoid possible clashes and facilitate 3rd-party library use.
Same macro redefinition technique for _STL:: used to keep clients
code which uses literal std::.</li>
<li>C library headers wrapping changed to account for multiple inclusion tricks
(needed by gcc-2.95 mostly)</li>
<li>auto_ptr updated, now it passes polymorphic tests with VC++</li>
<li>config changes - "configure" made obsolete and moved into "stlport/config/new_compiler"</li>
<li>Lot of minor bugfixes.</li>
</ul>
</p>
<h2><font color="#000080">STLport 3.2.1 Release Notes</font></h2>
<p>STLport 3.2.1 is a minor release in terms of functionality, but it is a huge
leap forward in terms of usability. </p>
<h2>std::renaming</h2>
3.2.1 finally solved the conflict between STLport string and std::string, which
used to be worked around by using namespace stlport::, to avoid link- and run-time
clashes. Refer to <a href="vendor_interface.html">"Cooperation with native standard library"</a>
section for details.
In 3.2.1, new, completely transparent scheme introduced to redefine <b>"std::"</b> in user
sources to <b>"stlport::"</b> via macros. Before 3.2.1, it was not possible, because not all headers were provided
with necessary wrappers.
Now, when user writes <b>"std::"</b> in application code, it yields the same results as if he wrote <b>"stlport::"</b>.<br>
The biggest advantage is that now absolutely no modifications in client code are needed to use.
STLport instead of native STL lib, which turns STLport into seamless drop-in component!
<h2>Windows improvements</h2>
STLport 3.2.1 provides the mechanism to export static members of default node allocator
from a designated user's DLL, which solves the problem observed with default allocator
and passing objects across DLL boundaries. Currently, one of user's DLL is supposed to
be designated to export STLport symbols. That will change as soon as STLport will provide
iostreams library.<p></p>
For MT compilation, <b>&lt;windows.h&gt;</b> is not included anymore to get synchronization
function prototypes. That significally reduces compilation time.
<p></p>
<h2>Quality improvements</h2>
<p>3.2.1 provides further code bloat reduction - hashtable uses vector <b>&lt;void*&gt;</b> internally.</p>
<h2>New platforms</h2>
Configuration files provided for DEC C++ 6.x/5.x , Borland C++ 5.02, KAI C++.
Windows CE configuration provided.
<hr>
<h2><font color="#000080">STLport 3.2 Release Notes</font></h2>
<p>STLport 3.2 is a major change from 3.12. It provides new components, new wrappers
and fixes many portability issues.</p>
<h2>New Components</h2>
New standard header files are provided : &lt;limits;&gt; and &lt;valarray&gt;.
Also, STLport now provide complete set of C library headers which are currently
wrappers for either old-style or new-style native C library headers.
<h2>Headers reorganization</h2>
Main STLport include directory renamed to <b>stlport</b>.
Old HP-style STL headers moved to <b>stlport/hp</b> directory.
<h2>Quality improvements</h2>
<p>3.2 provides new workarounds for standard allocators : EBO (empty-base optimization),
for automatic space optimization for instanceless allocators. Allocators with instances
now can be used with any compiler. Chunking problem is fixed - no memory overuse.
</p>
<p>Major restructuring - non-inline code moved to .c implementation files.
That makes huge code bloat reduction for compilers that support separate compilation model,
like IBM xlC. If this model is not supported, .c file is being included in corresponding .h file.
</p>
<p><a href="debug_mode.html">Debug</a> mode redesigned for less code bloat and memory footprint.
Now it use single-linked lists for iterators lists and tables for error reporting. Also it provides more flexible control on error reporting for user - now you can control whether debug aasertion throws an exception or not, or to supply your own termination routine in addition to reporting one.
</p>
<h2>New platforms</h2>
Configuration files provided for Apogee C++, Borland C++ Builder 4.
<h2>Smoother portability</h2>
<p>New workarounds are used for compilers with limited capabilities. Standard forms of distance()
and operator -&gt; for iterators is supported for them in 3.2. Additional user-level switch
_STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS is added to use minimum set of default arguments on
template classes that have more than one - for example map&lt;&gt;, set&lt;&gt;. This is supposed to help compiling existing standard code which use shortest notation.
Many other portability issues reported for 3.12 are fixed, including workaround for famous Sun CC 4.2 bug. _STLP_USE_MFC switch added for MFC cooperation.
</p>
<h2>Configuration engine changes</h2>
<p><a href="configure.html">Configuration</a> switches changed - those describing compiler misfeatures changed so that
the compiler that implements complete ANSI C++ Standard and has no bugs would have empty
configuration file.
</p>
<br>
<hr>
<h2><font color="#000080">STLport 3.12 Release Notes</font></h2>
<h2>Configuration changes</h2>
<p>In 3.12, the confuguration headers stlcomp.h and configure script reside in
config/ directory. stlcomp.h has been splitted to compiler-specific-headers. As now stl_config.h
includes &lt;config/stlcomp.h&gt;, your compiler must be able to understand UNIX-style paths.
Most compilers do that automatically, but some (MetroWerks CodeWarrior) require setting the option to do that..</p>
<h2>Cooperation with compiler's C++ library</h2>
<p>STLport 3.12 is capable of&nbsp; using separate namespace <b>stlport::</b>
to avoid conflicts with standard C++ library that comes with the
compiler. If your compiler provides new-style <b>&lt;iostream&gt;</b>,
please be sure to read the <a href="vendor_interface.html">document
describing this technique</a>.</p>
<h2>New-style iostreams:</h2>
<p>In STLport 3.12, <b>_STLP_USE_NEW_IOSTREAMS&nbsp; </b>macro controls
whether you are using templatized iostreams or not. This setting is
important - STLport's <b>&lt;iostream&gt;</b> imports appropriate
version of native iostreams (&lt;<b>iostream</b>&gt; vs. &lt;<b>iostream.h</b>&gt;
depending on it. This also affects the choice of <a href="vendor_interface.html#option_2">own
namespace mode</a>.</p>
<p>Use of other new-style header names like <tt>&lt;<b>vector</b>&gt;</tt>
with STLport is highly recommended. </p>
<h2>allocator&lt;&gt;</h2>
<p>In STLport 3.12, the default <b>_Alloc</b> parameter to standard
container is always <b>allocator&lt;&gt;</b> (unlike in SGI STL, where
it is only so when the compiler supports partial specialization and
other new features).</p>
<h2>Underscored&nbsp; names</h2>
<p>All inernal names in STLport 3.12 starts with undercsore
("_"), as specified by C++ standard.</p>
<h2><a name="new%20headers"></a>New-style C library headers</h2>
In this release, <b>_STLP_USE_NEW_STYLE_HEADERS</b> only controls
STLport choice of using new-style C library headers : &lt;cstdio&gt; vs.
&lt;stdio.h&gt;, etc.
<h2>Bitset - additional parameter</h2>
<p>SGI STL introduced extra template parameter BufSize for bitset : <b>_WordT,
</b>which defaults to unsigned long. For 64-bits architectures, you may
wish to change it to be long long. Note that explicit use of extra
parameter will lead to non-portability with other STL implementations.</p>
<h2>Deque - additional parameter</h2>
<p>SGI STL introduced extra template parameter BufSize for deque : <tt>deque&lt;class
T, class Alloc, size_t BufSize=0&gt;</tt>. <br>
That allows you to specify deque buffer size on per-instance basis. </p>
<p>Some compilers (<b>Borland, Visual, SunPro, ..</b>.) are unhappy
about non-type template parameters (particularly when deque is being
passed as parameter to functions). For these compilers, only default
buffer size option is available. You may still specify buffer size using
<tt>__deque__&lt;T,Alloc,BufSize&gt;</tt>. </p>
<p> Note that explicit use of extra parameter will lead to
non-portability with other STL implementations. You may force full
version to be the default ( <tt>deque&lt;class T, class Alloc=allocator&lt;T&gt;,
size_t BufSize=0&gt;</tt> ) by disabling <tt>_STLP_NON_TYPE_TMPL_PARAM_BUG</tt>
switch. Note that you may have problems instantiating template functions
taking deque as its argument then.</p>
</td></tr><tr valign="top" align="left"><td width="24"><img src="images/trans.gif" border="0" height="1" width="24"></td><td width="776"><img src="images/trans.gif" border="0" height="20" width="50"><br><a href="index.html">Table of Contents</a><br></td></tr><tr valign="top" align="left"><td width="24"><img src="images/trans.gif" border="0" height="1" width="24"></td><td width="776"><img src="images/trans.gif" border="0" height="40" width="80"><br><img src="images/black.gif" border="0" height="1" width="776"></td></tr><tr valign="top" align="left"><td width="24"><img src="images/trans.gif" border="0" height="1" width="24"></td><td width="776"><img src="images/black.gif" border="0" height="1" width="776"></td></tr><tr valign="top" align="left"><td width="24"><img src="images/trans.gif" border="0" height="1" width="24"></td><td width="776"><img src="images/trans.gif" border="0" height="5" width="50"><br><span class="copyright">Copyright 2001 by STLport</span><br><img src="images/trans.gif" border="0" height="50" width="80"></td></tr></table></body></html>