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