epoc32/include/tools/stlport/stl/config/user_config.h
branchSymbian3
changeset 4 837f303aceeb
     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 +*/