1.1 --- a/epoc32/include/tools/stlport/stl/config/user_config.h Tue Mar 16 16:12:26 2010 +0000
1.2 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000
1.3 @@ -1,312 +0,0 @@
1.4 -/*
1.5 - * Copyright (c) 1999
1.6 - * Boris Fomitchev
1.7 - *
1.8 - * This material is provided "as is", with absolutely no warranty expressed
1.9 - * or implied. Any use is at your own risk.
1.10 - *
1.11 - * Permission to use or copy this software for any purpose is hereby granted
1.12 - * without fee, provided the above notices are retained on all copies.
1.13 - * Permission to modify the code and to distribute modified code is granted,
1.14 - * provided the above notices are retained, and a notice that the code was
1.15 - * modified is included with the above copyright notice.
1.16 - */
1.17 -
1.18 -/*
1.19 - * Purpose of this file :
1.20 - *
1.21 - * To hold user-definable portion of STLport settings which may be overridden
1.22 - * on per-project basis.
1.23 - * Please note that if you use STLport iostreams (compiled library) then you have
1.24 - * to use consistent settings when you compile STLport library and your project.
1.25 - * Those settings are defined in host.h and have to be the same for a given
1.26 - * STLport installation.
1.27 - */
1.28 -
1.29 -
1.30 -/*==========================================================
1.31 - * User-settable macros that control compilation:
1.32 - * Features selection
1.33 - *==========================================================*/
1.34 -
1.35 -/*
1.36 - * Use this switch for embedded systems where no iostreams are available
1.37 - * at all. STLport own iostreams will also get disabled automatically then.
1.38 - * You can either use STLport iostreams, or no iostreams.
1.39 - * If you want iostreams, you have to compile library in ../build/lib
1.40 - * and supply resulting library at link time.
1.41 - */
1.42 -/*
1.43 -#define _STLP_NO_IOSTREAMS 1
1.44 -*/
1.45 -
1.46 -/*
1.47 - * Set _STLP_DEBUG to turn the "Debug Mode" on.
1.48 - * That gets you checked iterators/ranges in the manner
1.49 - * of "Safe STL". Very useful for debugging. Thread-safe.
1.50 - * Please do not forget to link proper STLport library flavor
1.51 - * (e.g libstlportstlg.so or libstlportstlg.a) when you set this flag
1.52 - * in STLport iostreams mode, namespace customization guaranty that you
1.53 - * link to the right library.
1.54 - */
1.55 -/*
1.56 -#define _STLP_DEBUG 1
1.57 -*/
1.58 -/*
1.59 - * You can also choose the debug level:
1.60 - * STLport debug level: Default value
1.61 - * Check only what the STLport implementation consider as invalid.
1.62 - * It also change the iterator invalidation schema.
1.63 - * Standard debug level: Check for all operations the standard consider as "undefined behavior"
1.64 - * even if STlport implement it correctly. It also invalidates iterators
1.65 - * more often.
1.66 - */
1.67 -/*
1.68 -#define _STLP_DEBUG_LEVEL _STLP_STLPORT_DBG_LEVEL
1.69 -#define _STLP_DEBUG_LEVEL _STLP_STANDARD_DBG_LEVEL
1.70 -*/
1.71 -/* When an inconsistency is detected by the 'safe STL' the program will abort.
1.72 - * If you prefer an exception define the following macro. The thrown exception
1.73 - * will be the Standard runtime_error exception.
1.74 - */
1.75 -/*
1.76 -#define _STLP_DEBUG_MODE_THROWS
1.77 - */
1.78 -
1.79 -/*
1.80 - * _STLP_NO_CUSTOM_IO : define this if you do not instantiate basic_xxx iostream
1.81 - * classes with custom types (which is most likely the case). Custom means types
1.82 - * other than char, wchar_t, char_traits<> and allocator<> like
1.83 - * basic_ostream<my_char_type, my_traits<my_char_type> > or
1.84 - * basic_string<char, char_traits<char>, my_allocator >
1.85 - * When this option is on, most non-inline template functions definitions for iostreams
1.86 - * are not seen by the client which saves a lot of compile time for most compilers,
1.87 - * also object and executable size for some.
1.88 - * Default is off, just not to break compilation for those who do use those types.
1.89 - * That also guarantees that you still use optimized standard i/o when you compile
1.90 - * your program without optimization. Option does not affect STLport library build; you
1.91 - * may use the same binary library with and without this option, on per-project basis.
1.92 - */
1.93 -/*
1.94 -#define _STLP_NO_CUSTOM_IO
1.95 -*/
1.96 -
1.97 -/*
1.98 - * _STLP_NO_RELOPS_NAMESPACE: if defined, don't put the relational
1.99 - * operator templates (>, <=. >=, !=) in namespace std::rel_ops, even
1.100 - * if the compiler supports namespaces.
1.101 - * Note : if the compiler do not support namespaces, those operators are not be provided by default,
1.102 - * to simulate hiding them into rel_ops. This was proved to resolve many compiler bugs with ambiguity.
1.103 - */
1.104 -/*
1.105 -#define _STLP_NO_RELOPS_NAMESPACE 1
1.106 -*/
1.107 -
1.108 -/*
1.109 - * If _STLP_USE_OWN_NAMESPACE is in effect, STLport by default will try
1.110 - * to rename std:: for the user to stlport::. If you do not want this feature,
1.111 - * please define the following switch and then use stlport::
1.112 - */
1.113 -/*
1.114 -#define _STLP_DONT_REDEFINE_STD 1
1.115 -*/
1.116 -
1.117 -/*
1.118 - * _STLP_WHOLE_NATIVE_STD : only meaningful in _STLP_USE_OWN_NAMESPACE mode.
1.119 - * Normally, STLport only imports necessary components from native std:: namespace -
1.120 - * those not yet provided by STLport (<iostream>, <complex>, etc.)
1.121 - * and their dependencies (<string>, <stdexcept>).
1.122 - * You might want everything from std:: being available in std:: namespace when you
1.123 - * include corresponding STLport header (like STLport <map> provides std::map as well, etc.),
1.124 - * if you are going to use both stlport:: and std:: components in your code.
1.125 - * Otherwise this option is not recommended as it increases the size of your object files
1.126 - * and slows down compilation.
1.127 - */
1.128 -/*
1.129 -#define _STLP_WHOLE_NATIVE_STD
1.130 -*/
1.131 -
1.132 -/*
1.133 - * Use this option to catch uninitialized members in your classes.
1.134 - * When it is set, construct() and destroy() fill the class storage
1.135 - * with _STLP_SHRED_BYTE (see below).
1.136 - * Note : _STLP_DEBUG and _STLP_DEBUG_ALLOC don't set this option automatically.
1.137 - */
1.138 -/*
1.139 -#define _STLP_DEBUG_UNINITIALIZED 1
1.140 -#define _STLP_DEBUG_ALLOC 1
1.141 -*/
1.142 -
1.143 -/*
1.144 - * Uncomment and provide a definition for the byte with which raw memory
1.145 - * will be filled if _STLP_DEBUG_ALLOC or _STLP_DEBUG_UNINITIALIZED is defined.
1.146 - * Choose a value which is likely to cause a noticeable problem if dereferenced
1.147 - * or otherwise abused. A good value may already be defined for your platform; see
1.148 - * stl/_config.h
1.149 - */
1.150 -/*
1.151 -#define _STLP_SHRED_BYTE 0xA3
1.152 -*/
1.153 -
1.154 -/*
1.155 - * This option is for gcc users only and only affects systems where native linker
1.156 - * does not let gcc to implement automatic instantiation of static template data members/
1.157 - * It is being put in this file as there is no way to check if we are using GNU ld automatically,
1.158 - * so it becomes user's responsibility.
1.159 - */
1.160 -/*
1.161 -#define _STLP_GCC_USES_GNU_LD
1.162 -*/
1.163 -
1.164 -/*==========================================================
1.165 - * Compatibility section
1.166 - *==========================================================*/
1.167 -
1.168 -/*
1.169 - * Define this macro to disable anachronistic constructs (like the ones used in HP STL and
1.170 - * not included in final standard, etc.
1.171 - */
1.172 -/*
1.173 -#define _STLP_NO_ANACHRONISMS 1
1.174 -*/
1.175 -
1.176 -/*
1.177 - * Define this macro to disable STLport extensions (for example, to make sure your code will
1.178 - * compile with some other implementation )
1.179 - */
1.180 -/*
1.181 -#define _STLP_NO_EXTENSIONS 1
1.182 -*/
1.183 -
1.184 -/*
1.185 - * You should define this macro if compiling with MFC - STLport <stl/_config.h>
1.186 - * then include <afx.h> instead of <windows.h> to get synchronisation primitives
1.187 - */
1.188 -/*
1.189 -#define _STLP_USE_MFC 1
1.190 -*/
1.191 -
1.192 -/*
1.193 - * boris : this setting is here as we cannot detect precense of new Platform SDK automatically
1.194 - * If you are using new PSDK with VC++ 6.0 or lower,
1.195 - * please define this to get correct prototypes for InterlockedXXX functions
1.196 - */
1.197 -/*
1.198 -#define _STLP_NEW_PLATFORM_SDK 1
1.199 -*/
1.200 -
1.201 -/*
1.202 - * For the same reason as the one above we are not able to detect easily use
1.203 - * of the compiler coming with the Platform SDK instead of the one coming with
1.204 - * a Microsoft Visual Studio release. This change native C/C++ library location
1.205 - * and implementation, please define this to get correct STLport configuration.
1.206 - */
1.207 -/*
1.208 -#define _STLP_USING_PLATFORM_SDK_COMPILER 1
1.209 -*/
1.210 -
1.211 -/*
1.212 - * Some compilers support the automatic linking feature.
1.213 - * Uncomment the following if you prefer to specify the STLport library
1.214 - * to link with yourself.
1.215 - * For the moment, this feature is only supported and implemented within STLport
1.216 - * by the Microsoft compilers.
1.217 - */
1.218 -/*
1.219 -#define _STLP_DONT_USE_AUTO_LINK 1
1.220 -*/
1.221 -
1.222 -/*
1.223 - * If you customize the STLport generated library names don't forget to give
1.224 - * the motif you used during configuration here if you still want the auto link
1.225 - * to work. (Do not remove double quotes in the macro value)
1.226 - */
1.227 -/*
1.228 -#define _STLP_LIB_NAME_MOTIF "???"
1.229 - */
1.230 -
1.231 -/*
1.232 - * When using automatic linking (see above), output a message that tells the
1.233 - * user which lib is getting linked via 'pragma message(..)'.
1.234 - * This setting has no effect if automatic linking is not active.
1.235 - */
1.236 -/*
1.237 -#define _STLP_VERBOSE_AUTO_LINK 1
1.238 -*/
1.239 -
1.240 -/*
1.241 - * Use minimum set of default arguments on template classes that have more
1.242 - * than one - for example map<>, set<>.
1.243 - * This has effect only if _STLP_LIMITED_DEFAULT_TEMPLATES is on.
1.244 - * If _STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS is set, you'll be able to compile
1.245 - * set<T> with those compilers, but you'll have to use __set__<T, less<T>>
1.246 - *
1.247 - * Affects : map<>, multimap<>, set<>, multiset<>, hash_*<>,
1.248 - * queue<>, priority_queue<>, stack<>, istream_iterator<>
1.249 - */
1.250 -/*
1.251 -#define _STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS 1
1.252 -*/
1.253 -
1.254 -/*
1.255 - * The agregation of strings using the + operator is an expensive operation
1.256 - * as it requires construction of temporary objects that need memory allocation
1.257 - * and deallocation. The problem can be even more important if you are adding
1.258 - * several strings together in a single expression. To avoid this problem STLport
1.259 - * implement expression template. With this technique addition of 2 strings is not
1.260 - * a string anymore but a temporary object having a reference to each of the
1.261 - * original strings involved in the expression. This object carry information
1.262 - * directly to the destination string to set its size correctly and only make
1.263 - * a single call to the allocator. This technique also works for the addition of
1.264 - * N elements where elements are basic_string, C string or a single character.
1.265 - * The drawback can be longer compilation time and bigger executable size.
1.266 - * STLport rebuild: Yes
1.267 - */
1.268 -/*
1.269 -#define _STLP_USE_TEMPLATE_EXPRESSION 1
1.270 -*/
1.271 -
1.272 -/*
1.273 - * By default the STLport basic_string implementation use a little static buffer
1.274 - * (of 16 chars when writing this doc) to avoid systematically memory allocation
1.275 - * in case of little basic_string. The drawback of such a method is bigger
1.276 - * basic_string size and some performance penalty for method like swap. If you
1.277 - * prefer systematical dynamic allocation turn on this macro.
1.278 - * STLport rebuild: Yes
1.279 - */
1.280 -/*
1.281 -#define _STLP_DONT_USE_SHORT_STRING_OPTIM 1
1.282 -*/
1.283 -
1.284 -/*
1.285 - * To reduce the famous code bloat trouble due to the use of templates STLport grant
1.286 - * a specialization of some containers for pointer types. So all instanciations
1.287 - * of those containers with a pointer type will use the same implementation based on
1.288 - * a container of void*. This feature has show very good result on object files size
1.289 - * but after link phase and optimization you will only experiment benefit if you use
1.290 - * many container with pointer types.
1.291 - */
1.292 -/*
1.293 -#define _STLP_USE_PTR_SPECIALIZATIONS 1
1.294 -*/
1.295 -
1.296 -/*
1.297 - * To achieve many different optimizations within the template implementations STLport
1.298 - * uses some type traits technique. With this macro you can ask STLport to use the famous
1.299 - * boost type traits rather than the internal one. The advantages are more compiler
1.300 - * integration and a better support. If you only define this macro once the STLport has been
1.301 - * built you just have to add the boost install path within your include path. If you want
1.302 - * to use this feature at STLport built time you will have to define the
1.303 - * STLP_BUILD_BOOST_PATH enrironment variable with the value of the boost library path.
1.304 - */
1.305 -/*
1.306 -#define _STLP_USE_BOOST_SUPPORT 1
1.307 -*/
1.308 -
1.309 -/*==========================================================*/
1.310 -
1.311 -/*
1.312 - Local Variables:
1.313 - mode: C++
1.314 - End:
1.315 -*/