epoc32/include/stdapis/stlportv5/stl/config/user_config.h
author William Roberts <williamr@symbian.org>
Wed, 31 Mar 2010 12:27:01 +0100
branchSymbian2
changeset 3 e1b950c65cb4
parent 2 epoc32/include/tools/stlport/stl/config/user_config.h@2fe1408b6811
child 4 837f303aceeb
permissions -rw-r--r--
Attempt to represent the S^2->S^3 header reorganisation as a series of "hg rename" operations
williamr@2
     1
/*
williamr@2
     2
 * Copyright (c) 1999
williamr@2
     3
 * Boris Fomitchev
williamr@2
     4
 *
williamr@2
     5
 * This material is provided "as is", with absolutely no warranty expressed
williamr@2
     6
 * or implied. Any use is at your own risk.
williamr@2
     7
 *
williamr@2
     8
 * Permission to use or copy this software for any purpose is hereby granted
williamr@2
     9
 * without fee, provided the above notices are retained on all copies.
williamr@2
    10
 * Permission to modify the code and to distribute modified code is granted,
williamr@2
    11
 * provided the above notices are retained, and a notice that the code was
williamr@2
    12
 * modified is included with the above copyright notice.
williamr@2
    13
 */
williamr@2
    14
williamr@2
    15
/*
williamr@2
    16
 * Purpose of this file :
williamr@2
    17
 *
williamr@2
    18
 * To hold user-definable portion of STLport settings which may be overridden
williamr@2
    19
 * on per-project basis.
williamr@2
    20
 * Please note that if you use STLport iostreams (compiled library) then you have
williamr@2
    21
 * to use consistent settings when you compile STLport library and your project.
williamr@2
    22
 * Those settings are defined in host.h and have to be the same for a given
williamr@2
    23
 * STLport installation.
williamr@2
    24
 */
williamr@2
    25
williamr@2
    26
williamr@2
    27
/*==========================================================
williamr@2
    28
 * User-settable macros that control compilation:
williamr@2
    29
 *              Features selection
williamr@2
    30
 *==========================================================*/
williamr@2
    31
williamr@2
    32
/*
williamr@2
    33
 * Use this switch for embedded systems where no iostreams are available
williamr@2
    34
 * at all. STLport own iostreams will also get disabled automatically then.
williamr@2
    35
 * You can either use STLport iostreams, or no iostreams.
williamr@2
    36
 * If you want iostreams, you have to compile library in ../build/lib
williamr@2
    37
 * and supply resulting library at link time.
williamr@2
    38
 */
williamr@2
    39
/*
williamr@2
    40
#define _STLP_NO_IOSTREAMS 1
williamr@2
    41
*/
williamr@2
    42
williamr@2
    43
/*
williamr@2
    44
 * Set _STLP_DEBUG to turn the "Debug Mode" on.
williamr@2
    45
 * That gets you checked iterators/ranges in the manner
williamr@2
    46
 * of "Safe STL". Very useful for debugging. Thread-safe.
williamr@2
    47
 * Please do not forget to link proper STLport library flavor
williamr@2
    48
 * (e.g libstlportstlg.so or libstlportstlg.a) when you set this flag
williamr@2
    49
 * in STLport iostreams mode, namespace customization guaranty that you
williamr@2
    50
 * link to the right library.
williamr@2
    51
 */
williamr@2
    52
/*
williamr@2
    53
#define _STLP_DEBUG 1
williamr@2
    54
*/
williamr@2
    55
/*
williamr@2
    56
 * You can also choose the debug level:
williamr@2
    57
 * STLport debug level: Default value
williamr@2
    58
 *                      Check only what the STLport implementation consider as invalid.
williamr@2
    59
 *                      It also change the iterator invalidation schema.
williamr@2
    60
 * Standard debug level: Check for all operations the standard consider as "undefined behavior"
williamr@2
    61
 *                       even if STlport implement it correctly. It also invalidates iterators
williamr@2
    62
 *                       more often.
williamr@2
    63
 */
williamr@2
    64
/*
williamr@2
    65
#define   _STLP_DEBUG_LEVEL _STLP_STLPORT_DBG_LEVEL
williamr@2
    66
#define   _STLP_DEBUG_LEVEL _STLP_STANDARD_DBG_LEVEL
williamr@2
    67
*/
williamr@2
    68
/* When an inconsistency is detected by the 'safe STL' the program will abort.
williamr@2
    69
 * If you prefer an exception define the following macro. The thrown exception
williamr@2
    70
 * will be the Standard runtime_error exception.
williamr@2
    71
 */
williamr@2
    72
/*
williamr@2
    73
#define _STLP_DEBUG_MODE_THROWS
williamr@2
    74
 */
williamr@2
    75
williamr@2
    76
/*
williamr@2
    77
 * _STLP_NO_CUSTOM_IO : define this if you do not instantiate basic_xxx iostream
williamr@2
    78
 * classes with custom types (which is most likely the case). Custom means types
williamr@2
    79
 * other than char, wchar_t, char_traits<> and allocator<> like
williamr@2
    80
 * basic_ostream<my_char_type, my_traits<my_char_type> > or
williamr@2
    81
 * basic_string<char, char_traits<char>, my_allocator >
williamr@2
    82
 * When this option is on, most non-inline template functions definitions for iostreams
williamr@2
    83
 * are not seen by the client which saves a lot of compile time for most compilers,
williamr@2
    84
 * also object and executable size for some.
williamr@2
    85
 * Default is off, just not to break compilation for those who do use those types.
williamr@2
    86
 * That also guarantees that you still use optimized standard i/o when you compile
williamr@2
    87
 * your program without optimization. Option does not affect STLport library build; you
williamr@2
    88
 * may use the same binary library with and without this option, on per-project basis.
williamr@2
    89
 */
williamr@2
    90
/*
williamr@2
    91
#define _STLP_NO_CUSTOM_IO
williamr@2
    92
*/
williamr@2
    93
williamr@2
    94
/*
williamr@2
    95
 * _STLP_NO_RELOPS_NAMESPACE: if defined, don't put the relational
williamr@2
    96
 * operator templates (>, <=. >=, !=) in namespace std::rel_ops, even
williamr@2
    97
 * if the compiler supports namespaces.
williamr@2
    98
 * Note : if the compiler do not support namespaces, those operators are not be provided by default,
williamr@2
    99
 * to simulate hiding them into rel_ops. This was proved to resolve many compiler bugs with ambiguity.
williamr@2
   100
 */
williamr@2
   101
/*
williamr@2
   102
#define _STLP_NO_RELOPS_NAMESPACE 1
williamr@2
   103
*/
williamr@2
   104
williamr@2
   105
/*
williamr@2
   106
 * If _STLP_USE_OWN_NAMESPACE is in effect, STLport by default will try
williamr@2
   107
 * to rename std:: for the user to stlport::. If you do not want this feature,
williamr@2
   108
 * please define the following switch and then use stlport::
williamr@2
   109
 */
williamr@2
   110
/*
williamr@2
   111
#define _STLP_DONT_REDEFINE_STD 1
williamr@2
   112
*/
williamr@2
   113
williamr@2
   114
/*
williamr@2
   115
 * _STLP_WHOLE_NATIVE_STD : only meaningful in _STLP_USE_OWN_NAMESPACE mode.
williamr@2
   116
 * Normally, STLport only imports necessary components from native std:: namespace -
williamr@2
   117
 * those not yet provided by STLport (<iostream>, <complex>, etc.)
williamr@2
   118
 * and their dependencies (<string>, <stdexcept>).
williamr@2
   119
 * You might want everything from std:: being available in std:: namespace when you
williamr@2
   120
 * include corresponding STLport header (like STLport <map> provides std::map as well, etc.),
williamr@2
   121
 * if you are going to use both stlport:: and std:: components in your code.
williamr@2
   122
 * Otherwise this option is not recommended as it increases the size of your object files
williamr@2
   123
 * and slows down compilation.
williamr@2
   124
 */
williamr@2
   125
/*
williamr@2
   126
#define _STLP_WHOLE_NATIVE_STD
williamr@2
   127
*/
williamr@2
   128
williamr@2
   129
/*
williamr@2
   130
 * Use this option to catch uninitialized members in your classes.
williamr@2
   131
 * When it is set, construct() and destroy() fill the class storage
williamr@2
   132
 * with _STLP_SHRED_BYTE (see below).
williamr@2
   133
 * Note : _STLP_DEBUG and _STLP_DEBUG_ALLOC don't set this option automatically.
williamr@2
   134
 */
williamr@2
   135
/*
williamr@2
   136
#define _STLP_DEBUG_UNINITIALIZED 1
williamr@2
   137
#define _STLP_DEBUG_ALLOC 1
williamr@2
   138
*/
williamr@2
   139
williamr@2
   140
/*
williamr@2
   141
 * Uncomment and provide a definition for the byte with which raw memory
williamr@2
   142
 * will be filled if _STLP_DEBUG_ALLOC or _STLP_DEBUG_UNINITIALIZED is defined.
williamr@2
   143
 * Choose a value which is likely to cause a noticeable problem if dereferenced
williamr@2
   144
 * or otherwise abused. A good value may already be defined for your platform; see
williamr@2
   145
 * stl/_config.h
williamr@2
   146
 */
williamr@2
   147
/*
williamr@2
   148
#define _STLP_SHRED_BYTE 0xA3
williamr@2
   149
*/
williamr@2
   150
williamr@2
   151
/*
williamr@2
   152
 *  This option is for gcc users only and only affects systems where native linker
williamr@2
   153
 *  does not let gcc to implement automatic instantiation of static template data members/
williamr@2
   154
 *  It is being put in this file as there is no way to check if we are using GNU ld automatically,
williamr@2
   155
 *  so it becomes user's responsibility.
williamr@2
   156
 */
williamr@2
   157
/*
williamr@2
   158
#define _STLP_GCC_USES_GNU_LD
williamr@2
   159
*/
williamr@2
   160
williamr@2
   161
/*==========================================================
williamr@2
   162
 * Compatibility section
williamr@2
   163
 *==========================================================*/
williamr@2
   164
williamr@2
   165
/*
williamr@2
   166
 *  Define this macro to disable anachronistic constructs (like the ones used in HP STL and
williamr@2
   167
 *  not included in final standard, etc.
williamr@2
   168
 */
williamr@2
   169
/*
williamr@2
   170
#define _STLP_NO_ANACHRONISMS 1
williamr@2
   171
*/
williamr@2
   172
williamr@2
   173
/*
williamr@2
   174
 *  Define this macro to disable STLport extensions (for example, to make sure your code will
williamr@2
   175
 *  compile with some other implementation )
williamr@2
   176
 */
williamr@2
   177
/*
williamr@2
   178
#define _STLP_NO_EXTENSIONS 1
williamr@2
   179
*/
williamr@2
   180
williamr@2
   181
/*
williamr@2
   182
 * You should define this macro if compiling with MFC - STLport <stl/_config.h>
williamr@2
   183
 * then include <afx.h> instead of <windows.h> to get synchronisation primitives
williamr@2
   184
 */
williamr@2
   185
/*
williamr@2
   186
#define _STLP_USE_MFC 1
williamr@2
   187
*/
williamr@2
   188
williamr@2
   189
/*
williamr@2
   190
 * boris : this setting is here as we cannot detect precense of new Platform SDK automatically
williamr@2
   191
 * If you are using new PSDK with VC++ 6.0 or lower,
williamr@2
   192
 * please define this to get correct prototypes for InterlockedXXX functions
williamr@2
   193
 */
williamr@2
   194
/*
williamr@2
   195
#define _STLP_NEW_PLATFORM_SDK 1
williamr@2
   196
*/
williamr@2
   197
williamr@2
   198
/*
williamr@2
   199
 * For the same reason as the one above we are not able to detect easily use
williamr@2
   200
 * of the compiler coming with the Platform SDK instead of the one coming with
williamr@2
   201
 * a Microsoft Visual Studio release. This change native C/C++ library location
williamr@2
   202
 * and implementation, please define this to get correct STLport configuration.
williamr@2
   203
 */
williamr@2
   204
/*
williamr@2
   205
#define _STLP_USING_PLATFORM_SDK_COMPILER 1
williamr@2
   206
*/
williamr@2
   207
williamr@2
   208
/*
williamr@2
   209
 * Some compilers support the automatic linking feature.
williamr@2
   210
 * Uncomment the following if you prefer to specify the STLport library
williamr@2
   211
 * to link with yourself.
williamr@2
   212
 * For the moment, this feature is only supported and implemented within STLport
williamr@2
   213
 * by the Microsoft compilers.
williamr@2
   214
 */
williamr@2
   215
/*
williamr@2
   216
#define _STLP_DONT_USE_AUTO_LINK 1
williamr@2
   217
*/
williamr@2
   218
williamr@2
   219
/*
williamr@2
   220
 * If you customize the STLport generated library names don't forget to give
williamr@2
   221
 * the motif you used during configuration here if you still want the auto link
williamr@2
   222
 * to work. (Do not remove double quotes in the macro value)
williamr@2
   223
 */
williamr@2
   224
/*
williamr@2
   225
#define _STLP_LIB_NAME_MOTIF "???"
williamr@2
   226
 */
williamr@2
   227
williamr@2
   228
/*
williamr@2
   229
 * When using automatic linking (see above), output a message that tells the
williamr@2
   230
 * user which lib is getting linked via 'pragma message(..)'.
williamr@2
   231
 * This setting has no effect if automatic linking is not active.
williamr@2
   232
 */
williamr@2
   233
/*
williamr@2
   234
#define _STLP_VERBOSE_AUTO_LINK 1
williamr@2
   235
*/
williamr@2
   236
williamr@2
   237
/*
williamr@2
   238
 * Use minimum set of default arguments on template classes that have more
williamr@2
   239
 * than one - for example map<>, set<>.
williamr@2
   240
 * This has effect only if _STLP_LIMITED_DEFAULT_TEMPLATES is on.
williamr@2
   241
 * If _STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS is set, you'll be able to compile
williamr@2
   242
 * set<T> with those compilers, but you'll have to use __set__<T, less<T>>
williamr@2
   243
 *
williamr@2
   244
 * Affects : map<>, multimap<>, set<>, multiset<>, hash_*<>,
williamr@2
   245
 * queue<>, priority_queue<>, stack<>, istream_iterator<>
williamr@2
   246
 */
williamr@2
   247
/*
williamr@2
   248
#define _STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS 1
williamr@2
   249
*/
williamr@2
   250
williamr@2
   251
/*
williamr@2
   252
 * The agregation of strings using the + operator is an expensive operation
williamr@2
   253
 * as it requires construction of temporary objects that need memory allocation
williamr@2
   254
 * and deallocation. The problem can be even more important if you are adding
williamr@2
   255
 * several strings together in a single expression. To avoid this problem STLport
williamr@2
   256
 * implement expression template. With this technique addition of 2 strings is not
williamr@2
   257
 * a string anymore but a temporary object having a reference to each of the
williamr@2
   258
 * original strings involved in the expression. This object carry information
williamr@2
   259
 * directly to the destination string to set its size correctly and only make
williamr@2
   260
 * a single call to the allocator. This technique also works for the addition of
williamr@2
   261
 * N elements where elements are basic_string, C string or a single character.
williamr@2
   262
 * The drawback can be longer compilation time and bigger executable size.
williamr@2
   263
 * STLport rebuild: Yes
williamr@2
   264
 */
williamr@2
   265
/*
williamr@2
   266
#define _STLP_USE_TEMPLATE_EXPRESSION 1
williamr@2
   267
*/
williamr@2
   268
williamr@2
   269
/*
williamr@2
   270
 * By default the STLport basic_string implementation use a little static buffer
williamr@2
   271
 * (of 16 chars when writing this doc) to avoid systematically memory allocation
williamr@2
   272
 * in case of little basic_string. The drawback of such a method is bigger
williamr@2
   273
 * basic_string size and some performance penalty for method like swap. If you
williamr@2
   274
 * prefer systematical dynamic allocation turn on this macro.
williamr@2
   275
 * STLport rebuild: Yes
williamr@2
   276
 */
williamr@2
   277
/*
williamr@2
   278
#define _STLP_DONT_USE_SHORT_STRING_OPTIM 1
williamr@2
   279
*/
williamr@2
   280
williamr@2
   281
/*
williamr@2
   282
 * To reduce the famous code bloat trouble due to the use of templates STLport grant
williamr@2
   283
 * a specialization of some containers for pointer types. So all instanciations
williamr@2
   284
 * of those containers with a pointer type will use the same implementation based on
williamr@2
   285
 * a container of void*. This feature has show very good result on object files size
williamr@2
   286
 * but after link phase and optimization you will only experiment benefit if you use
williamr@2
   287
 * many container with pointer types.
williamr@2
   288
 */
williamr@2
   289
/*
williamr@2
   290
#define _STLP_USE_PTR_SPECIALIZATIONS 1
williamr@2
   291
*/
williamr@2
   292
williamr@2
   293
/*
williamr@2
   294
 * To achieve many different optimizations within the template implementations STLport
williamr@2
   295
 * uses some type traits technique. With this macro you can ask STLport to use the famous
williamr@2
   296
 * boost type traits rather than the internal one. The advantages are more compiler
williamr@2
   297
 * integration and a better support. If you only define this macro once the STLport has been
williamr@2
   298
 * built you just have to add the boost install path within your include path. If you want
williamr@2
   299
 * to use this feature at STLport built time you will have to define the
williamr@2
   300
 * STLP_BUILD_BOOST_PATH enrironment variable with the value of the boost library path.
williamr@2
   301
 */
williamr@2
   302
/*
williamr@2
   303
#define _STLP_USE_BOOST_SUPPORT 1
williamr@2
   304
*/
williamr@2
   305
williamr@2
   306
/*==========================================================*/
williamr@2
   307
williamr@2
   308
/*
williamr@2
   309
  Local Variables:
williamr@2
   310
  mode: C++
williamr@2
   311
  End:
williamr@2
   312
*/