1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/epoc32/include/tools/stlport/stl/config/user_config.h Wed Mar 31 12:33:34 2010 +0100
1.3 @@ -0,0 +1,312 @@
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 +*/