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