ReactOS Fundraising Campaign 2012
 
€ 4,410 / € 30,000

Information | Donate

Home | Info | Community | Development | myReactOS | Contact Us

  1. Home
  2. Community
  3. Development
  4. myReactOS
  5. Fundraiser 2012

  1. Main Page
  2. Alphabetical List
  3. Data Structures
  4. Directories
  5. File List
  6. Data Fields
  7. Globals
  8. Related Pages

ReactOS Development > Doxygen

user_config.h
Go 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 STLport use its own namespace, see _STLP_NO_OWN_NAMESPACE in host.h, it will try
00107  * by default 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 if STLport uses its own namespace.
00116  * Normally, STLport only imports necessary components from native std:: namespace.
00117  * You might want everything from std:: being available in std:: namespace when you
00118  * include corresponding STLport header (like STLport <map> provides std::map as well, etc.),
00119  * if you are going to use both stlport:: and std:: components in your code.
00120  * Otherwise this option is not recommended as it increases the size of your object files
00121  * and slows down compilation.
00122  * Beware, if you do not use STLport iostream (_STLP_NO_IOSTREAMS above), ask STLport to
00123  * not rename std:: in stlport:: and try to have access to whole native Standard stuff then
00124  * STLport will only throw exceptions from the std namespace and not from stlport.
00125  * For instance a problem in stlport::vector::at will throw a std::out_of_range exception
00126  * and not a stlport::out_of_range.
00127  * Notice that STLport exceptions inherits from std::exception.
00128  */
00129 /*
00130 #define _STLP_WHOLE_NATIVE_STD
00131 */
00132 
00133 /*
00134  * Use this option to catch uninitialized members in your classes.
00135  * When it is set, construct() and destroy() fill the class storage
00136  * with _STLP_SHRED_BYTE (see below).
00137  * Note : _STLP_DEBUG and _STLP_DEBUG_ALLOC don't set this option automatically.
00138  */
00139 /*
00140 #define _STLP_DEBUG_UNINITIALIZED 1
00141 #define _STLP_DEBUG_ALLOC 1
00142 */
00143 
00144 /*
00145  * Uncomment and provide a definition for the byte with which raw memory
00146  * will be filled if _STLP_DEBUG_ALLOC or _STLP_DEBUG_UNINITIALIZED is defined.
00147  * Choose a value which is likely to cause a noticeable problem if dereferenced
00148  * or otherwise abused. A good value may already be defined for your platform.
00149  */
00150 /*
00151 #define _STLP_SHRED_BYTE 0xA3
00152 */
00153 
00154 /*
00155  *  This option is for gcc users only and only affects systems where native linker
00156  *  does not let gcc to implement automatic instantiation of static template data members/
00157  *  It is being put in this file as there is no way to check if we are using GNU ld automatically,
00158  *  so it becomes user's responsibility.
00159  */
00160 #ifdef __MINGW32__
00161 #  define _STLP_GCC_USES_GNU_LD
00162 #endif
00163 
00164 /*==========================================================
00165  * Compatibility section
00166  *==========================================================*/
00167 
00168 /*
00169  *  Define this macro to disable anachronistic constructs (like the ones used in HP STL and
00170  *  not included in final standard, etc.
00171  */
00172 /*
00173 #define _STLP_NO_ANACHRONISMS 1
00174 */
00175 
00176 /*
00177  *  Define this macro to disable STLport extensions (for example, to make sure your code will
00178  *  compile with some other implementation )
00179  */
00180 /*
00181 #define _STLP_NO_EXTENSIONS 1
00182 */
00183 
00184 /*
00185  * You should define this macro if compiling with MFC - STLport <stl/config/_windows.h>
00186  * then include <afx.h> instead of <windows.h> to get synchronisation primitives
00187  */
00188 /*
00189 #define _STLP_USE_MFC 1
00190 */
00191 
00192 /*
00193  * boris : this setting is here as we cannot detect precense of new Platform SDK automatically
00194  * If you are using new PSDK with VC++ 6.0 or lower,
00195  * please define this to get correct prototypes for InterlockedXXX functions
00196  */
00197 #define _STLP_NEW_PLATFORM_SDK 1
00198 
00199 /*
00200  * For the same reason as the one above we are not able to detect easily use
00201  * of the compiler coming with the Platform SDK instead of the one coming with
00202  * a Microsoft Visual Studio release. This change native C/C++ library location
00203  * and implementation, please define this to get correct STLport configuration.
00204  */
00205 #define _STLP_USING_PLATFORM_SDK_COMPILER 1
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 #define _STLP_DONT_USE_AUTO_LINK 1
00215 
00216 /*
00217  * If you customize the STLport generated library names don't forget to give
00218  * the motif you used during configuration here if you still want the auto link
00219  * to work. (Do not remove double quotes in the macro value)
00220  */
00221 /*
00222 #define _STLP_LIB_NAME_MOTIF "???"
00223  */
00224 
00225 /*
00226  * Uncomment to get feedback at compilation time about result of build environment
00227  * introspection.
00228  */
00229 /*
00230 #define _STLP_VERBOSE 1
00231 */
00232 
00233 /*
00234  * Use minimum set of default arguments on template classes that have more
00235  * than one - for example map<>, set<>.
00236  * This has effect only if _STLP_LIMITED_DEFAULT_TEMPLATES is on.
00237  * If _STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS is set, you'll be able to compile
00238  * set<T> with those compilers, but you'll have to use __set__<T, less<T>>
00239  *
00240  * Affects : map<>, multimap<>, set<>, multiset<>, hash_*<>,
00241  * queue<>, priority_queue<>, stack<>, istream_iterator<>
00242  */
00243 /*
00244 #define _STLP_MINIMUM_DEFAULT_TEMPLATE_PARAMS 1
00245 */
00246 
00247 /*
00248  * The agregation of strings using the + operator is an expensive operation
00249  * as it requires construction of temporary objects that need memory allocation
00250  * and deallocation. The problem can be even more important if you are adding
00251  * several strings together in a single expression. To avoid this problem STLport
00252  * implement expression template. With this technique addition of 2 strings is not
00253  * a string anymore but a temporary object having a reference to each of the
00254  * original strings involved in the expression. This object carry information
00255  * directly to the destination string to set its size correctly and only make
00256  * a single call to the allocator. This technique also works for the addition of
00257  * N elements where elements are basic_string, C string or a single character.
00258  * The drawback can be longer compilation time and bigger executable size.
00259  * Another problem is that some compilers (gcc) fail to use string proxy object
00260  * if do with class derived from string (see unit tests for details).
00261  * STLport rebuild: Yes
00262  */
00263 /*
00264 #define _STLP_USE_TEMPLATE_EXPRESSION 1
00265 */
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 shown 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  * There are however a number of limitation to use this option:
00288  *   - with compilers not supporting partial template specialization feature, you won't
00289  *     be able to access some nested container types like iterator as long as the
00290  *     definition of the type used to instanciate the container will be incomplete
00291  *     (see IncompleteClass definition in test/unit/vector_test.cpp).
00292  *   - you won't be able to use complex Standard allocator implementations which are
00293  *     allocators having pointer nested type not being a real C pointer.
00294  */
00295 /*
00296 #define _STLP_USE_PTR_SPECIALIZATIONS 1
00297 */
00298 
00299 /*
00300  * To achieve many different optimizations within the template implementations STLport
00301  * uses some type traits technique. With this macro you can ask STLport to use the famous
00302  * boost type traits rather than the internal one. The advantages are more compiler
00303  * integration and a better support. If you only define this macro once the STLport has been
00304  * built you just have to add the boost install path within your include path. If you want
00305  * to use this feature at STLport built time you will have to define the
00306  * STLP_BUILD_BOOST_PATH enrironment variable with the value of the boost library path.
00307  */
00308 
00309 /*
00310 #define _STLP_USE_BOOST_SUPPORT 1
00311 */
00312 
00313 
00314 /*==========================================================*/
00315 
00316 /*
00317   Local Variables:
00318   mode: C++
00319   End:
00320 */

Generated on Sat May 26 2012 04:28:24 for ReactOS by doxygen 1.7.6.1

ReactOS is a registered trademark or a trademark of ReactOS Foundation in the United States and other countries.