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.
STLport 4.0 Release NotesSTLport 4.0 is a major release. Finally, it offers complete C++ standard library! Here is a list of major changes in 4.0 :
- Complete ANSI C++ standard library, including <complex> and SGI iostreams.
- Can be configured to use either SGI or native iostreams.
- 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 _STLD:: is being used, so no link-time clashes between debug and non-debug versions are possible.
- New platforms - gcc-2.95, Mingw32, Borland C++ Builder 5.5, SUN CC 6.0 Early Access, SUN CC in compatibility mode.
- 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::.
- C library headers wrapping changed to account for multiple inclusion tricks (needed by gcc-2.95 mostly)
- auto_ptr updated, now it passes polymorphic tests with VC++
- config changes - "configure" made obsolete and moved into "stlport/config/new_compiler"
- Lot of minor bugfixes.
STLport 3.2.1 Release Notes
STLport 3.2.1 is a minor release in terms of functionality, but it is a huge leap forward in terms of usability.
std::renaming
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 "Cooperation with native standard library" section for details. In 3.2.1, new, completely transparent scheme introduced to redefine "std::" in user sources to "stlport::" via macros. Before 3.2.1, it was not possible, because not all headers were provided with necessary wrappers. Now, when user writes "std::" in application code, it yields the same results as if he wrote "stlport::".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!
Windows improvements
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. For MT compilation, <windows.h> is not included anymore to get synchronization function prototypes. That significally reduces compilation time.Quality improvements
3.2.1 provides further code bloat reduction - hashtable uses vector <void*> internally.
New platforms
Configuration files provided for DEC C++ 6.x/5.x , Borland C++ 5.02, KAI C++. Windows CE configuration provided.STLport 3.2 Release Notes
STLport 3.2 is a major change from 3.12. It provides new components, new wrappers and fixes many portability issues.
New Components
New standard header files are provided : <limits;> and <valarray>. 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.Headers reorganization
Main STLport include directory renamed to stlport. Old HP-style STL headers moved to stlport/hp directory.Quality improvements
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.
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.
Debug 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.
New platforms
Configuration files provided for Apogee C++, Borland C++ Builder 4.Smoother portability
New workarounds are used for compilers with limited capabilities. Standard forms of distance() and operator -> 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<>, set<>. 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.
Configuration engine changes
Configuration 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.
STLport 3.12 Release Notes
Configuration changes
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 <config/stlcomp.h>, 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..
Cooperation with compiler's C++ library
STLport 3.12 is capable of using separate namespace stlport:: to avoid conflicts with standard C++ library that comes with the compiler. If your compiler provides new-style <iostream>, please be sure to read the document describing this technique.
New-style iostreams:
In STLport 3.12, _STLP_USE_NEW_IOSTREAMS macro controls whether you are using templatized iostreams or not. This setting is important - STLport's <iostream> imports appropriate version of native iostreams (<iostream> vs. <iostream.h> depending on it. This also affects the choice of own namespace mode.
Use of other new-style header names like <vector> with STLport is highly recommended.
allocator<>
In STLport 3.12, the default _Alloc parameter to standard container is always allocator<> (unlike in SGI STL, where it is only so when the compiler supports partial specialization and other new features).
Underscored names
All inernal names in STLport 3.12 starts with undercsore ("_"), as specified by C++ standard.
New-style C library headers
In this release, _STLP_USE_NEW_STYLE_HEADERS only controls STLport choice of using new-style C library headers : <cstdio> vs. <stdio.h>, etc.Bitset - additional parameter
SGI STL introduced extra template parameter BufSize for bitset : _WordT, 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.
Deque - additional parameter
SGI STL introduced extra template parameter BufSize for deque : deque<class
T, class Alloc, size_t BufSize=0>.
That allows you to specify deque buffer size on per-instance basis.
Some compilers (Borland, Visual, SunPro, ...) 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 __deque__<T,Alloc,BufSize>.
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 ( deque<class T, class Alloc=allocator<T>, size_t BufSize=0> ) by disabling _STLP_NON_TYPE_TMPL_PARAM_BUG switch. Note that you may have problems instantiating template functions taking deque as its argument then.
Table of Contents
Copyright 2001 by STLport