/home/ntakagi/work/STLport-5.1.5/stlport/stl/config/user_config.hGo to the documentation of this file.00001 /* 00002 * Copyright (c) 1999 00003 * Boris Fomitchev 00004 * 00005 * This material is provided "as is", with absolutely no warranty expressed 00006 * or implied. Any use is at your own risk. 00007 * 00008 * Permission to use or copy this software for any purpose is hereby granted 00009 * without fee, provided the above notices are retained on all copies. 00010 * Permission to modify the code and to distribute modified code is granted, 00011 * provided the above notices are retained, and a notice that the code was 00012 * modified is included with the above copyright notice. 00013 */ 00014 00015 /* 00016 * Purpose of this file : 00017 * 00018 * To hold user-definable portion of STLport settings which may be overridden 00019 * on per-project basis. 00020 * Please note that if you use STLport iostreams (compiled library) then you have 00021 * to use consistent settings when you compile STLport library and your project. 00022 * Those settings are defined in host.h and have to be the same for a given 00023 * STLport installation. 00024 */ 00025 00026 00027 /*========================================================== 00028 * User-settable macros that control compilation: 00029 * Features selection 00030 *==========================================================*/ 00031 00032 /* 00033 * Use this switch for embedded systems where no iostreams are available 00034 * at all. STLport own iostreams will also get disabled automatically then. 00035 * You can either use STLport iostreams, or no iostreams. 00036 * If you want iostreams, you have to compile library in ../build/lib 00037 * and supply resulting library at link time. 00038 */ 00039 /* 00040 #define _STLP_NO_IOSTREAMS 1 00041 */ 00042 00043 /* 00044 * Set _STLP_DEBUG to turn the "Debug Mode" on. 00045 * That gets you checked iterators/ranges in the manner 00046 * of "Safe STL". Very useful for debugging. Thread-safe. 00047 * Please do not forget to link proper STLport library flavor 00048 * (e.g libstlportstlg.so or libstlportstlg.a) when you set this flag 00049 * in STLport iostreams mode, namespace customization guaranty that you 00050 * link to the right library. 00051 */ 00052 /* 00053 #define _STLP_DEBUG 1 00054 */ 00055 /* 00056 * You can also choose the debug level: 00057 * STLport debug level: Default value 00058 * Check only what the STLport implementation consider as invalid. 00059 * It also change the iterator invalidation schema. 00060 * Standard debug level: Check for all operations the standard consider as "undefined behavior" 00061 * even if STlport implement it correctly. It also invalidates iterators 00062 * more often. 00063 */ 00064 /* 00065 #define _STLP_DEBUG_LEVEL _STLP_STLPORT_DBG_LEVEL 00066 #define _STLP_DEBUG_LEVEL _STLP_STANDARD_DBG_LEVEL 00067 */ 00068 /* When an inconsistency is detected by the 'safe STL' the program will abort. 00069 * If you prefer an exception define the following macro. The thrown exception 00070 * will be the Standard runtime_error exception. 00071 */ 00072 /* 00073 #define _STLP_DEBUG_MODE_THROWS 00074 */ 00075 00076 /* 00077 * _STLP_NO_CUSTOM_IO : define this if you do not instantiate basic_xxx iostream 00078 * classes with custom types (which is most likely the case). Custom means types 00079 * other than char, wchar_t, char_traits<> and allocator<> like 00080 * basic_ostream<my_char_type, my_traits<my_char_type> > or 00081 * basic_string<char, char_traits<char>, my_allocator > 00082 * When this option is on, most non-inline template functions definitions for iostreams 00083 * are not seen by the client which saves a lot of compile time for most compilers, 00084 * also object and executable size for some. 00085 * Default is off, just not to break compilation for those who do use those types. 00086 * That also guarantees that you still use optimized standard i/o when you compile 00087 * your program without optimization. Option does not affect STLport library build; you 00088 * may use the same binary library with and without this option, on per-project basis. 00089 */ 00090 /* 00091 #define _STLP_NO_CUSTOM_IO 00092 */ 00093 00094 /* 00095 * _STLP_NO_RELOPS_NAMESPACE: if defined, don't put the relational 00096 * operator templates (>, <=. >=, !=) in namespace std::rel_ops, even 00097 * if the compiler supports namespaces. 00098 * Note : if the compiler do not support namespaces, those operators are not be provided by default, 00099 * to simulate hiding them into rel_ops. This was proved to resolve many compiler bugs with ambiguity. 00100 */ 00101 /* 00102 #define _STLP_NO_RELOPS_NAMESPACE 1 00103 */ 00104 00105 /* 00106 * If _STLP_USE_OWN_NAMESPACE is in effect, STLport by default will try 00107 * to rename std:: for the user to stlport::. If you do not want this feature, 00108 * please define the following switch and then use stlport:: 00109 */ 00110 /* 00111 #define _STLP_DONT_REDEFINE_STD 1 00112 */ 00113 00114 /* 00115 * _STLP_WHOLE_NATIVE_STD : only meaningful in _STLP_USE_OWN_NAMESPACE mode. 00116 * Normally, STLport only imports necessary components from native std:: namespace - 00117 * those not yet provided by STLport (<iostream>, <complex>, etc.) 00118 * and their dependencies (<string>, <stdexcept>). 00119 * You might want everything from std:: being available in std:: namespace when you 00120 * include corresponding STLport header (like STLport <map> provides std::map as well, etc.), 00121 * if you are going to use both stlport:: and std:: components in your code. 00122 * Otherwise this option is not recommended as it increases the size of your object files 00123 * and slows down compilation. 00124 */ 00125 /* 00126 #define _STLP_WHOLE_NATIVE_STD 00127 */ 00128 00129 /* 00130 * Use this option to catch uninitialized members in your classes. 00131 * When it is set, construct() and destroy() fill the class storage 00132 * with _STLP_SHRED_BYTE (see below). 00133 * Note : _STLP_DEBUG and _STLP_DEBUG_ALLOC don't set this option automatically. 00134 */ 00135 /* 00136 #define _STLP_DEBUG_UNINITIALIZED 1 00137 #define _STLP_DEBUG_ALLOC 1 00138 */ 00139 00140 /* 00141 * Uncomment and provide a definition for the byte with which raw memory 00142 * will be filled if _STLP_DEBUG_ALLOC or _STLP_DEBUG_UNINITIALIZED is defined. 00143 * Choose a value which is likely to cause a noticeable problem if dereferenced 00144 * or otherwise abused. A good value may already be defined for your platform. 00145 */ 00146 /* 00147 #define _STLP_SHRED_BYTE 0xA3 00148 */ 00149 00150 /* 00151 * This option is for gcc users only and only affects systems where native linker 00152 * does not let gcc to implement automatic instantiation of static template data members/ 00153 * It is being put in this file as there is no way to check if we are using GNU ld automatically, 00154 * so it becomes user's responsibility. 00155 */ 00156 /* 00157 #define _STLP_GCC_USES_GNU_LD 00158 */ 00159 00160 /*========================================================== 00161 * Compatibility section 00162 *==========================================================*/ 00163 00164 /* 00165 * Define this macro to disable anachronistic constructs (like the ones used in HP STL and 00166 * not included in final standard, etc. 00167 */ 00168 /* 00169 #define _STLP_NO_ANACHRONISMS 1 00170 */ 00171 00172 /* 00173 * Define this macro to disable STLport extensions (for example, to make sure your code will 00174 * compile with some other implementation ) 00175 */ 00176 /* 00177 #define _STLP_NO_EXTENSIONS 1 00178 */ 00179 00180 /* 00181 * You should define this macro if compiling with MFC - STLport <stl/config/_windows.h> 00182 * then include <afx.h> instead of <windows.h> to get synchronisation primitives 00183 */ 00184 /* 00185 #define _STLP_USE_MFC 1 00186 */ 00187 00188 /* 00189 * boris : this setting is here as we cannot detect precense of new Platform SDK automatically 00190 * If you are using new PSDK with VC++ 6.0 or lower, 00191 * please define this to get correct prototypes for InterlockedXXX functions 00192 */ 00193 /* 00194 #define _STLP_NEW_PLATFORM_SDK 1 00195 */ 00196 00197 /* 00198 * For the same reason as the one above we are not able to detect easily use 00199 * of the compiler coming with the Platform SDK instead of the one coming with 00200 * a Microsoft Visual Studio release. This change native C/C++ library location 00201 * and implementation, please define this to get correct STLport configuration. 00202 */ 00203 /* 00204 #define _STLP_USING_PLATFORM_SDK_COMPILER 1 00205 */ 00206 00207 /* 00208 * Some compilers support the automatic linking feature. 00209 * Uncomment the following if you prefer to specify the STLport library 00210 * to link with yourself. 00211 * For the moment, this feature is only supported and implemented within STLport 00212 * by the Microsoft compilers. 00213 */ 00214 /* 00215 #define _STLP_DONT_USE_AUTO_LINK 1 00216 */ 00217 00218 /* 00219 * If you customize the STLport generated library names don't forget to give 00220 * the motif you used during configuration here if you still want the auto link 00221 * to work. (Do not remove double quotes in the macro value) 00222 */ 00223 /* 00224 #define _STLP_LIB_NAME_MOTIF "???" 00225 */ 00226 00227 /* 00228 * When using automatic linking (see above), output a message that tells the 00229 * user which lib is getting linked via 'pragma message(..)'. 00230 * This setting has no effect if automatic linking is not active. 00231 */ 00232 /* 00233 #define _STLP_VERBOSE_AUTO_LINK 1 00234 */ 00235 00236 /* 00237 * Use minimum set of default arguments on template classes that have more 00238 * than one - for example map<>, set<>. 00239 * This has effect only if _STLP_LIMITED_DEFAULT_TEMPLATES is on. 00240 * If _STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS is set, you'll be able to compile 00241 * set<T> with those compilers, but you'll have to use __set__<T, less<T>> 00242 * 00243 * Affects : map<>, multimap<>, set<>, multiset<>, hash_*<>, 00244 * queue<>, priority_queue<>, stack<>, istream_iterator<> 00245 */ 00246 /* 00247 #define _STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS 1 00248 */ 00249 00250 /* 00251 * The agregation of strings using the + operator is an expensive operation 00252 * as it requires construction of temporary objects that need memory allocation 00253 * and deallocation. The problem can be even more important if you are adding 00254 * several strings together in a single expression. To avoid this problem STLport 00255 * implement expression template. With this technique addition of 2 strings is not 00256 * a string anymore but a temporary object having a reference to each of the 00257 * original strings involved in the expression. This object carry information 00258 * directly to the destination string to set its size correctly and only make 00259 * a single call to the allocator. This technique also works for the addition of 00260 * N elements where elements are basic_string, C string or a single character. 00261 * The drawback can be longer compilation time and bigger executable size. 00262 * STLport rebuild: Yes 00263 */ 00264 /* 00265 #define _STLP_USE_TEMPLATE_EXPRESSION 1 00266 */ 00267 00268 /* 00269 * By default the STLport basic_string implementation use a little static buffer 00270 * (of 16 chars when writing this doc) to avoid systematically memory allocation 00271 * in case of little basic_string. The drawback of such a method is bigger 00272 * basic_string size and some performance penalty for method like swap. If you 00273 * prefer systematical dynamic allocation turn on this macro. 00274 * STLport rebuild: Yes 00275 */ 00276 /* 00277 #define _STLP_DONT_USE_SHORT_STRING_OPTIM 1 00278 */ 00279 00280 /* 00281 * To reduce the famous code bloat trouble due to the use of templates STLport grant 00282 * a specialization of some containers for pointer types. So all instanciations 00283 * of those containers with a pointer type will use the same implementation based on 00284 * a container of void*. This feature has show very good result on object files size 00285 * but after link phase and optimization you will only experiment benefit if you use 00286 * many container with pointer types. 00287 */ 00288 /* 00289 #define _STLP_USE_PTR_SPECIALIZATIONS 1 00290 */ 00291 00292 /* 00293 * To achieve many different optimizations within the template implementations STLport 00294 * uses some type traits technique. With this macro you can ask STLport to use the famous 00295 * boost type traits rather than the internal one. The advantages are more compiler 00296 * integration and a better support. If you only define this macro once the STLport has been 00297 * built you just have to add the boost install path within your include path. If you want 00298 * to use this feature at STLport built time you will have to define the 00299 * STLP_BUILD_BOOST_PATH enrironment variable with the value of the boost library path. 00300 */ 00301 /* 00302 #define _STLP_USE_BOOST_SUPPORT 1 00303 */ 00304 00305 /*==========================================================*/ 00306 00307 /* 00308 Local Variables: 00309 mode: C++ 00310 End: 00311 */
Generated on Mon Mar 10 15:32:46 2008 by ![]() |