williamr@2: /* williamr@2: * Copyright (c) 1999 williamr@2: * Boris Fomitchev williamr@2: * williamr@2: * This material is provided "as is", with absolutely no warranty expressed williamr@2: * or implied. Any use is at your own risk. williamr@2: * williamr@2: * Permission to use or copy this software for any purpose is hereby granted williamr@2: * without fee, provided the above notices are retained on all copies. williamr@2: * Permission to modify the code and to distribute modified code is granted, williamr@2: * provided the above notices are retained, and a notice that the code was williamr@2: * modified is included with the above copyright notice. williamr@2: */ williamr@2: williamr@2: /* williamr@2: * Purpose of this file : williamr@2: * williamr@2: * To hold user-definable portion of STLport settings which may be overridden williamr@2: * on per-project basis. williamr@2: * Please note that if you use STLport iostreams (compiled library) then you have williamr@2: * to use consistent settings when you compile STLport library and your project. williamr@2: * Those settings are defined in host.h and have to be the same for a given williamr@2: * STLport installation. williamr@2: */ williamr@2: williamr@2: williamr@2: /*========================================================== williamr@2: * User-settable macros that control compilation: williamr@2: * Features selection williamr@2: *==========================================================*/ williamr@2: williamr@2: /* williamr@2: * Use this switch for embedded systems where no iostreams are available williamr@2: * at all. STLport own iostreams will also get disabled automatically then. williamr@2: * You can either use STLport iostreams, or no iostreams. williamr@2: * If you want iostreams, you have to compile library in ../build/lib williamr@2: * and supply resulting library at link time. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_NO_IOSTREAMS 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * Set _STLP_DEBUG to turn the "Debug Mode" on. williamr@2: * That gets you checked iterators/ranges in the manner williamr@2: * of "Safe STL". Very useful for debugging. Thread-safe. williamr@2: * Please do not forget to link proper STLport library flavor williamr@2: * (e.g libstlportstlg.so or libstlportstlg.a) when you set this flag williamr@2: * in STLport iostreams mode, namespace customization guaranty that you williamr@2: * link to the right library. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_DEBUG 1 williamr@2: */ williamr@2: /* williamr@2: * You can also choose the debug level: williamr@2: * STLport debug level: Default value williamr@2: * Check only what the STLport implementation consider as invalid. williamr@2: * It also change the iterator invalidation schema. williamr@2: * Standard debug level: Check for all operations the standard consider as "undefined behavior" williamr@2: * even if STlport implement it correctly. It also invalidates iterators williamr@2: * more often. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_DEBUG_LEVEL _STLP_STLPORT_DBG_LEVEL williamr@2: #define _STLP_DEBUG_LEVEL _STLP_STANDARD_DBG_LEVEL williamr@2: */ williamr@2: /* When an inconsistency is detected by the 'safe STL' the program will abort. williamr@2: * If you prefer an exception define the following macro. The thrown exception williamr@2: * will be the Standard runtime_error exception. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_DEBUG_MODE_THROWS williamr@2: */ williamr@2: williamr@2: /* williamr@2: * _STLP_NO_CUSTOM_IO : define this if you do not instantiate basic_xxx iostream williamr@2: * classes with custom types (which is most likely the case). Custom means types williamr@2: * other than char, wchar_t, char_traits<> and allocator<> like williamr@2: * basic_ostream > or williamr@2: * basic_string, my_allocator > williamr@2: * When this option is on, most non-inline template functions definitions for iostreams williamr@2: * are not seen by the client which saves a lot of compile time for most compilers, williamr@2: * also object and executable size for some. williamr@2: * Default is off, just not to break compilation for those who do use those types. williamr@2: * That also guarantees that you still use optimized standard i/o when you compile williamr@2: * your program without optimization. Option does not affect STLport library build; you williamr@2: * may use the same binary library with and without this option, on per-project basis. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_NO_CUSTOM_IO williamr@2: */ williamr@2: williamr@2: /* williamr@2: * _STLP_NO_RELOPS_NAMESPACE: if defined, don't put the relational williamr@2: * operator templates (>, <=. >=, !=) in namespace std::rel_ops, even williamr@2: * if the compiler supports namespaces. williamr@2: * Note : if the compiler do not support namespaces, those operators are not be provided by default, williamr@2: * to simulate hiding them into rel_ops. This was proved to resolve many compiler bugs with ambiguity. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_NO_RELOPS_NAMESPACE 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * If _STLP_USE_OWN_NAMESPACE is in effect, STLport by default will try williamr@2: * to rename std:: for the user to stlport::. If you do not want this feature, williamr@2: * please define the following switch and then use stlport:: williamr@2: */ williamr@2: /* williamr@2: #define _STLP_DONT_REDEFINE_STD 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * _STLP_WHOLE_NATIVE_STD : only meaningful in _STLP_USE_OWN_NAMESPACE mode. williamr@2: * Normally, STLport only imports necessary components from native std:: namespace - williamr@2: * those not yet provided by STLport (, , etc.) williamr@2: * and their dependencies (, ). williamr@2: * You might want everything from std:: being available in std:: namespace when you williamr@2: * include corresponding STLport header (like STLport provides std::map as well, etc.), williamr@2: * if you are going to use both stlport:: and std:: components in your code. williamr@2: * Otherwise this option is not recommended as it increases the size of your object files williamr@2: * and slows down compilation. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_WHOLE_NATIVE_STD williamr@2: */ williamr@2: williamr@2: /* williamr@2: * Use this option to catch uninitialized members in your classes. williamr@2: * When it is set, construct() and destroy() fill the class storage williamr@2: * with _STLP_SHRED_BYTE (see below). williamr@2: * Note : _STLP_DEBUG and _STLP_DEBUG_ALLOC don't set this option automatically. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_DEBUG_UNINITIALIZED 1 williamr@2: #define _STLP_DEBUG_ALLOC 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * Uncomment and provide a definition for the byte with which raw memory williamr@2: * will be filled if _STLP_DEBUG_ALLOC or _STLP_DEBUG_UNINITIALIZED is defined. williamr@2: * Choose a value which is likely to cause a noticeable problem if dereferenced williamr@2: * or otherwise abused. A good value may already be defined for your platform; see williamr@2: * stl/_config.h williamr@2: */ williamr@2: /* williamr@2: #define _STLP_SHRED_BYTE 0xA3 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * This option is for gcc users only and only affects systems where native linker williamr@2: * does not let gcc to implement automatic instantiation of static template data members/ williamr@2: * It is being put in this file as there is no way to check if we are using GNU ld automatically, williamr@2: * so it becomes user's responsibility. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_GCC_USES_GNU_LD williamr@2: */ williamr@2: williamr@2: /*========================================================== williamr@2: * Compatibility section williamr@2: *==========================================================*/ williamr@2: williamr@2: /* williamr@2: * Define this macro to disable anachronistic constructs (like the ones used in HP STL and williamr@2: * not included in final standard, etc. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_NO_ANACHRONISMS 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * Define this macro to disable STLport extensions (for example, to make sure your code will williamr@2: * compile with some other implementation ) williamr@2: */ williamr@2: /* williamr@2: #define _STLP_NO_EXTENSIONS 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * You should define this macro if compiling with MFC - STLport williamr@2: * then include instead of to get synchronisation primitives williamr@2: */ williamr@2: /* williamr@2: #define _STLP_USE_MFC 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * boris : this setting is here as we cannot detect precense of new Platform SDK automatically williamr@2: * If you are using new PSDK with VC++ 6.0 or lower, williamr@2: * please define this to get correct prototypes for InterlockedXXX functions williamr@2: */ williamr@2: /* williamr@2: #define _STLP_NEW_PLATFORM_SDK 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * For the same reason as the one above we are not able to detect easily use williamr@2: * of the compiler coming with the Platform SDK instead of the one coming with williamr@2: * a Microsoft Visual Studio release. This change native C/C++ library location williamr@2: * and implementation, please define this to get correct STLport configuration. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_USING_PLATFORM_SDK_COMPILER 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * Some compilers support the automatic linking feature. williamr@2: * Uncomment the following if you prefer to specify the STLport library williamr@2: * to link with yourself. williamr@2: * For the moment, this feature is only supported and implemented within STLport williamr@2: * by the Microsoft compilers. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_DONT_USE_AUTO_LINK 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * If you customize the STLport generated library names don't forget to give williamr@2: * the motif you used during configuration here if you still want the auto link williamr@2: * to work. (Do not remove double quotes in the macro value) williamr@2: */ williamr@2: /* williamr@2: #define _STLP_LIB_NAME_MOTIF "???" williamr@2: */ williamr@2: williamr@2: /* williamr@2: * When using automatic linking (see above), output a message that tells the williamr@2: * user which lib is getting linked via 'pragma message(..)'. williamr@2: * This setting has no effect if automatic linking is not active. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_VERBOSE_AUTO_LINK 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * Use minimum set of default arguments on template classes that have more williamr@2: * than one - for example map<>, set<>. williamr@2: * This has effect only if _STLP_LIMITED_DEFAULT_TEMPLATES is on. williamr@2: * If _STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS is set, you'll be able to compile williamr@2: * set with those compilers, but you'll have to use __set__> williamr@2: * williamr@2: * Affects : map<>, multimap<>, set<>, multiset<>, hash_*<>, williamr@2: * queue<>, priority_queue<>, stack<>, istream_iterator<> williamr@2: */ williamr@2: /* williamr@2: #define _STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * The agregation of strings using the + operator is an expensive operation williamr@2: * as it requires construction of temporary objects that need memory allocation williamr@2: * and deallocation. The problem can be even more important if you are adding williamr@2: * several strings together in a single expression. To avoid this problem STLport williamr@2: * implement expression template. With this technique addition of 2 strings is not williamr@2: * a string anymore but a temporary object having a reference to each of the williamr@2: * original strings involved in the expression. This object carry information williamr@2: * directly to the destination string to set its size correctly and only make williamr@2: * a single call to the allocator. This technique also works for the addition of williamr@2: * N elements where elements are basic_string, C string or a single character. williamr@2: * The drawback can be longer compilation time and bigger executable size. williamr@2: * STLport rebuild: Yes williamr@2: */ williamr@2: /* williamr@2: #define _STLP_USE_TEMPLATE_EXPRESSION 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * By default the STLport basic_string implementation use a little static buffer williamr@2: * (of 16 chars when writing this doc) to avoid systematically memory allocation williamr@2: * in case of little basic_string. The drawback of such a method is bigger williamr@2: * basic_string size and some performance penalty for method like swap. If you williamr@2: * prefer systematical dynamic allocation turn on this macro. williamr@2: * STLport rebuild: Yes williamr@2: */ williamr@2: /* williamr@2: #define _STLP_DONT_USE_SHORT_STRING_OPTIM 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * To reduce the famous code bloat trouble due to the use of templates STLport grant williamr@2: * a specialization of some containers for pointer types. So all instanciations williamr@2: * of those containers with a pointer type will use the same implementation based on williamr@2: * a container of void*. This feature has show very good result on object files size williamr@2: * but after link phase and optimization you will only experiment benefit if you use williamr@2: * many container with pointer types. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_USE_PTR_SPECIALIZATIONS 1 williamr@2: */ williamr@2: williamr@2: /* williamr@2: * To achieve many different optimizations within the template implementations STLport williamr@2: * uses some type traits technique. With this macro you can ask STLport to use the famous williamr@2: * boost type traits rather than the internal one. The advantages are more compiler williamr@2: * integration and a better support. If you only define this macro once the STLport has been williamr@2: * built you just have to add the boost install path within your include path. If you want williamr@2: * to use this feature at STLport built time you will have to define the williamr@2: * STLP_BUILD_BOOST_PATH enrironment variable with the value of the boost library path. williamr@2: */ williamr@2: /* williamr@2: #define _STLP_USE_BOOST_SUPPORT 1 williamr@2: */ williamr@2: williamr@2: /*==========================================================*/ williamr@2: williamr@2: /* williamr@2: Local Variables: williamr@2: mode: C++ williamr@2: End: williamr@2: */