Don't use the standard containers by default.

Revert the change of wxUSE_STD_CONTAINERS to 1 by default as this introduces
more incompatibilities which risk hamper upgrading to 3.0 unnecessarily.

Update the documentation to better explain why do the non-standard container
classes exist in wxWidgets and, especially, that they shouldn't be used when
possible. Also document the differences between the normal and STL containers
build in the manual.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67735 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

configure

@@ -1,5 +1,5 @@
 #! /bin/sh
-# From configure.in Id: configure.in 67603 2011-04-26 17:35:35Z RD .
+# From configure.in Id.
 # Guess values for system-dependent variables and create Makefiles.
 # Generated by GNU Autoconf 2.61 for wxWidgets 2.9.2.
 #
@@ -2974,7 +2974,7 @@ esac
 
 DEFAULT_wxUSE_ALL_FEATURES=yes
 
-DEFAULT_wxUSE_STD_CONTAINERS=$DEFAULT_STD_FLAG
+DEFAULT_wxUSE_STD_CONTAINERS=no
 DEFAULT_wxUSE_STD_IOSTREAM=$DEFAULT_STD_FLAG
 DEFAULT_wxUSE_STD_STRING=$DEFAULT_STD_FLAG
 
@@ -4778,6 +4778,11 @@ fi
           { echo "$as_me:$LINENO: result: $result" >&5
 echo "${ECHO_T}$result" >&6; }
 
+if test "$wxUSE_STL" = "yes"; then
+    DEFAULT_wxUSE_STD_CONTAINERS=yes
+    DEFAULT_wxUSE_STD_IOSTREAM=yes
+    DEFAULT_wxUSE_STD_STRING=yes
+fi
 
           enablestring=
           defaultval=
@@ -17233,7 +17238,7 @@ if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
 else
   ac_cv_prog_gcc_traditional=no
 fi
-rm -f -r conftest*
+rm -f conftest*
 
 
   if test $ac_cv_prog_gcc_traditional = no; then
@@ -17250,7 +17255,7 @@ if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
   $EGREP "$ac_pattern" >/dev/null 2>&1; then
   ac_cv_prog_gcc_traditional=yes
 fi
-rm -f -r conftest*
+rm -f conftest*
 
   fi
 fi
@@ -19876,7 +19881,7 @@ if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
 else
   ac_cv_header_stdc=no
 fi
-rm -f -r conftest*
+rm -f conftest*
 
 fi
 
@@ -19897,7 +19902,7 @@ if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
 else
   ac_cv_header_stdc=no
 fi
-rm -f -r conftest*
+rm -f conftest*
 
 fi
 
@@ -24702,11 +24707,13 @@ _ACEOF
 cat confdefs.h >>conftest.$ac_ext
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
-#include <stdio.h>
+#include <sys/types.h> /* for off_t */
+     #include <stdio.h>
 int
 main ()
 {
-return fseeko (stdin, 0, 0) && (fseeko) (stdin, 0, 0);
+int (*fp) (FILE *, off_t, int) = fseeko;
+     return fseeko (stdin, 0, 0) && fp (stdin, 0, 0);
   ;
   return 0;
 }
@@ -24746,11 +24753,13 @@ cat confdefs.h >>conftest.$ac_ext
 cat >>conftest.$ac_ext <<_ACEOF
 /* end confdefs.h.  */
 #define _LARGEFILE_SOURCE 1
-#include <stdio.h>
+#include <sys/types.h> /* for off_t */
+     #include <stdio.h>
 int
 main ()
 {
-return fseeko (stdin, 0, 0) && (fseeko) (stdin, 0, 0);
+int (*fp) (FILE *, off_t, int) = fseeko;
+     return fseeko (stdin, 0, 0) && fp (stdin, 0, 0);
   ;
   return 0;
 }
@@ -24797,7 +24806,7 @@ cat >>confdefs.h <<_ACEOF
 _ACEOF
 ;;
 esac
-rm -f -r conftest*
+rm -f conftest*
 
 # We used to try defining _XOPEN_SOURCE=500 too, to work around a bug
 # in glibc 2.1.3, but that breaks too many other things.
@@ -31489,7 +31498,7 @@ _ACEOF
       eval "ac_im_$ac_var=\`\${MAKE-make} $ac_var 2>/dev/null | sed -n 's/^$ac_var=//p'\`"
     done
     # Open Windows xmkmf reportedly sets LIBDIR instead of USRLIBDIR.
-    for ac_extension in a so sl dylib la dll; do
+    for ac_extension in a so sl; do
       if test ! -f "$ac_im_usrlibdir/libX11.$ac_extension" &&
 	 test -f "$ac_im_libdir/libX11.$ac_extension"; then
 	ac_im_usrlibdir=$ac_im_libdir; break
@@ -31642,7 +31651,7 @@ sed 's/^/| /' conftest.$ac_ext >&5
 for ac_dir in `echo "$ac_x_includes $ac_x_header_dirs" | sed s/include/lib/g`
 do
   # Don't even attempt the hair of trying to link an X program!
-  for ac_extension in a so sl dylib la dll; do
+  for ac_extension in a so sl; do
     if test -r "$ac_dir/libX11.$ac_extension"; then
       ac_x_libraries=$ac_dir
       break 2

configure.in

@@ -372,7 +372,7 @@ dnl wxUSE_ALL_FEATURES which is the only which has to be set to "yes" by
 dnl default)
 DEFAULT_wxUSE_ALL_FEATURES=yes
 
-DEFAULT_wxUSE_STD_CONTAINERS=$DEFAULT_STD_FLAG
+DEFAULT_wxUSE_STD_CONTAINERS=no
 DEFAULT_wxUSE_STD_IOSTREAM=$DEFAULT_STD_FLAG
 DEFAULT_wxUSE_STD_STRING=$DEFAULT_STD_FLAG
 
@@ -701,6 +701,11 @@ dnl ---------------------------------------------------------------------------
 
 WX_ARG_DISABLE(shared,     [  --disable-shared        create static library instead of shared], wxUSE_SHARED)
 WX_ARG_ENABLE(stl,         [  --enable-stl            use standard C++ classes for everything], wxUSE_STL)
+if test "$wxUSE_STL" = "yes"; then
+    DEFAULT_wxUSE_STD_CONTAINERS=yes
+    DEFAULT_wxUSE_STD_IOSTREAM=yes
+    DEFAULT_wxUSE_STD_STRING=yes
+fi
 WX_ARG_ENABLE(std_containers,[  --enable-std_containers use standard C++ container classes], wxUSE_STD_CONTAINERS)
 WX_ARG_ENABLE(std_iostreams, [  --enable-std_iostreams  use standard C++ stream classes], wxUSE_STD_IOSTREAM)
 WX_ARG_ENABLE(std_string,    [  --enable-std_string     use standard C++ string classes], wxUSE_STD_STRING)

docs/changes.txt

@@ -59,43 +59,6 @@ changes:
   their overridden OnExecute() or override a more convenient OnExec() instead.
 
 
-Use of STL containers by default
---------------------------------
-
-wxWidgets uses STL containers for the implementation of wxVector, wxList,
-wxDList and wxStack by default since 2.9.2 release. While the STL-based
-versions are mostly compatible with the old ones, there are some differences:
-
- - wxList::compatibility_iterator must be used instead of wxList::Node* when
-   iterating over the list contents. The compatibility_iterator class has the
-   same semantics as a Node pointer but it is an object and not a pointer, so
-   you need to write
-
-        for ( wxWindowList::compatibility_iterator it = list.GetFirst();
-              it;
-              it = it->GetNext() )
-            ...
-
-   instead of the old
-
-        for ( wxWindowList::Node *n = list.GetFirst(); n; n = n->GetNext() )
-            ...
-
- - wxSortedArrayString and wxArrayString are separate classes now and the
-   former doesn't derive from the latter. If you need to convert a sorted array
-   to a normal one, you must copy all the elements. Alternatively, you may
-   avoid the use of wxSortedArrayString by using a normal array and calling its
-   Sort() method when needed.
-
- - WX_DEFINE_ARRAY_INT(bool) cannot be used because of the differences in
-   std::vector<bool> specialization compared with the generic std::vector<>
-   class. Please either use std::vector<bool> directly or use an integer array
-   instead.
-
-Finally notice that you may set wxUSE_STD_CONTAINERS to 0 when compiling
-wxWidgets to use the non-STL containers.
-
-
 wxODBC and contrib libraries removal
 ------------------------------------
 

docs/doxygen/overviews/container.h

@@ -10,21 +10,44 @@
 
 @page overview_container Container Classes
 
-Classes: wxList<T>, wxArray<T>, wxVector<T>
+Classes: wxList<T>, wxArray<T>, wxVector<T>, wxStack<T>, wxHashMap, wxHashSet
 
-wxWidgets uses itself several container classes including doubly-linked lists
+@section overview_container_intro Overview
-and dynamic arrays (i.e. arrays which expand automatically when they become
-full). For both historical and portability reasons wxWidgets does not require
-the use of STL (which provides the standard implementation of many container
-classes in C++) but it can be compiled in STL mode. Additionally, wxWidgets
-provides the new wxVector<T> class template which can be used like the std::vector
-class and is actually just a typedef to std::vector if wxWidgets is compiled
-in STL mode.
 
-wxWidgets non-template container classes don't pretend to be as powerful or full as STL
+For historical reasons, wxWidgets uses custom container classes internally.
-ones, but they are quite useful and may be compiled with absolutely any C++
+This was unfortunately unavoidable during a long time when the standard library
-compiler. They're used internally by wxWidgets, but may, of course, be used in
+wasn't widely available and can't be easily changed even now that it is for
-your programs as well if you wish.
+compatibility reasons. If you are building your own version of the library and
+don't care about compatibility nor slight (less than 5%) size penalty imposed
+by the use of STL classes, you may choose to use the "STL" build of wxWidgets
+in which these custom classes are replaced with their standard counterparts and
+only read the section @ref overview_container_std explaining how to do it.
+
+Otherwise you will need to know about the custom wxWidgets container classes
+such as wxList<T> and wxArray<T> if only to use wxWidgets functions that work
+with them, e.g. wxWindow::GetChildren(), and you should find the information
+about using these classes below useful.
+
+Notice that we recommend that you use standard classes directly in your own
+code instead of the container classes provided by wxWidgets in any case as the
+standard classes are easier to use and may also be safer because of extra
+run-time checks they may perform as well as more efficient.
+
+Finally notice that recent versions of wxWidgets also provide standard-like
+classes such as wxVector<T>, wxStack<T> or wxDList which can be used exactly
+like the std::vector<T>, std::stack<T> and std::list<T*>, respectively, and
+actually are just typedefs for the corresponding types if wxWidgets is compiled
+in STL mode. These classes could be useful if you wish to avoid the use of the
+standard library in your code for some reason.
+
+To summarize, you should use the standard container classes such as
+std::vector<T> and std::list<T> if possible and wxVector<T> or wxDList<T> if
+it isn't and only use legacy wxWidgets containers such as wxArray<T> and
+wxList<T> when you must, i.e. when you use a wxWidgets function taking or
+returning a container of such type.
+
+
+@section overview_container_legacy Legacy Classes
 
 The list classes in wxWidgets are doubly-linked lists which may either own the
 objects they contain (meaning that the list deletes the object when it is
@@ -40,10 +63,10 @@ two sorts: the "plain" arrays which store either built-in types such as "char",
 own the object pointers to which they store.
 
 For the same portability reasons, the container classes implementation in
-wxWidgets does not use templates, but is rather based on C preprocessor i.e. is
+wxWidgets don't use templates, but are rather based on C preprocessor i.e. are
-done with the macros: WX_DECLARE_LIST() and WX_DEFINE_LIST() for the linked
+implemented using the macros: WX_DECLARE_LIST() and WX_DEFINE_LIST() for the
-lists and WX_DECLARE_ARRAY(), WX_DECLARE_OBJARRAY() and WX_DEFINE_OBJARRAY()
+linked lists and WX_DECLARE_ARRAY(), WX_DECLARE_OBJARRAY() and
-for the dynamic arrays.
+WX_DEFINE_OBJARRAY() for the dynamic arrays.
 
 The "DECLARE" macro declares a new container class containing the elements of
 given type and is needed for all three types of container classes: lists,
@@ -67,5 +90,41 @@ wxArrayString. The first three store elements of corresponding types, but
 wxArrayString is somewhat special: it is an optimized version of wxArray which
 uses its knowledge about wxString reference counting schema.
 
+
+@section overview_container_std STL Build
+
+To build wxWidgets with the standard containers you need to set
+wxUSE_STD_CONTAINERS option to 1 in @c wx/msw/setup.h for wxMSW builds or
+specify @c --enable-std_containers option to configure (which is also
+implicitly enabled by @c --enable-stl option) in Unix builds.
+
+The standard container build is mostly, but not quite, compatible with the
+default one. Here are the most important differences:
+ - wxList::compatibility_iterator must be used instead of wxList::Node* when
+   iterating over the list contents. The compatibility_iterator class has the
+   same semantics as a Node pointer but it is an object and not a pointer, so
+   you need to write
+        @code
+        for ( wxWindowList::compatibility_iterator it = list.GetFirst();
+              it;
+              it = it->GetNext() )
+            ...
+        @endcode
+   instead of the old
+        @code
+        for ( wxWindowList::Node *n = list.GetFirst(); n; n = n->GetNext() )
+            ...
+        @endcode
+ - wxSortedArrayString and wxArrayString are separate classes now and the
+   former doesn't derive from the latter. If you need to convert a sorted array
+   to a normal one, you must copy all the elements. Alternatively, you may
+   avoid the use of wxSortedArrayString by using a normal array and calling its
+   Sort() method when needed.
+ - WX_DEFINE_ARRAY_INT(bool) cannot be used because of the differences in
+   std::vector<bool> specialization compared with the generic std::vector<>
+   class. Please either use std::vector<bool> directly or use an integer array
+   instead.
+
+
 */
 

include/wx/motif/setup0.h

@@ -303,20 +303,18 @@
 // usually more limited) implementations are used which allows to avoid the
 // dependency on the C++ run-time library.
 //
-// Default is 1 if compiler supports it. Currently this means not one of the
+// Notice that the compilers mentioned in wxUSE_STD_DEFAULT comment above don't
-// compilers mentioned in wxUSE_STD_DEFAULT comment and also not VC6 as it
+// support using standard containers and that VC6 needs non-default options for
-// needs non-default options for such build to avoid getting "fatal error
+// such build to avoid getting "fatal error C1076: compiler limit : internal
-// C1076: compiler limit : internal heap limit reached; use /Zm to specify a
+// heap limit reached; use /Zm to specify a higher limit" in its own standard
-// higher limit" in its own standard headers, so you need to ensure you do
+// headers, so you need to ensure you do increase the heap size before enabling
-// increase the heap size before enabling this option for this compiler.
+// this option for this compiler.
 //
-// Recommended setting: 1 unless you use a system without good implementation
+// Default is 0 for compatibility reasons.
-// of STL.
+//
-#if defined(_MSC_VER) && _MSC_VER < 1300
+// Recommended setting: 1 unless compatibility with the official wxWidgets
-    #define wxUSE_STD_CONTAINERS 0
+// build and/or the existing code is a concern.
-#else
+#define wxUSE_STD_CONTAINERS 0
-    #define wxUSE_STD_CONTAINERS wxUSE_STD_DEFAULT
-#endif
 
 // Use standard C++ streams if 1 instead of wx streams in some places. If
 // disabled, wx streams are used everywhere and wxWidgets doesn't depend on the

include/wx/msw/setup0.h

@@ -303,20 +303,18 @@
 // usually more limited) implementations are used which allows to avoid the
 // dependency on the C++ run-time library.
 //
-// Default is 1 if compiler supports it. Currently this means not one of the
+// Notice that the compilers mentioned in wxUSE_STD_DEFAULT comment above don't
-// compilers mentioned in wxUSE_STD_DEFAULT comment and also not VC6 as it
+// support using standard containers and that VC6 needs non-default options for
-// needs non-default options for such build to avoid getting "fatal error
+// such build to avoid getting "fatal error C1076: compiler limit : internal
-// C1076: compiler limit : internal heap limit reached; use /Zm to specify a
+// heap limit reached; use /Zm to specify a higher limit" in its own standard
-// higher limit" in its own standard headers, so you need to ensure you do
+// headers, so you need to ensure you do increase the heap size before enabling
-// increase the heap size before enabling this option for this compiler.
+// this option for this compiler.
 //
-// Recommended setting: 1 unless you use a system without good implementation
+// Default is 0 for compatibility reasons.
-// of STL.
+//
-#if defined(_MSC_VER) && _MSC_VER < 1300
+// Recommended setting: 1 unless compatibility with the official wxWidgets
-    #define wxUSE_STD_CONTAINERS 0
+// build and/or the existing code is a concern.
-#else
+#define wxUSE_STD_CONTAINERS 0
-    #define wxUSE_STD_CONTAINERS wxUSE_STD_DEFAULT
-#endif
 
 // Use standard C++ streams if 1 instead of wx streams in some places. If
 // disabled, wx streams are used everywhere and wxWidgets doesn't depend on the

include/wx/msw/wince/setup.h

@@ -303,20 +303,18 @@
 // usually more limited) implementations are used which allows to avoid the
 // dependency on the C++ run-time library.
 //
-// Default is 1 if compiler supports it. Currently this means not one of the
+// Notice that the compilers mentioned in wxUSE_STD_DEFAULT comment above don't
-// compilers mentioned in wxUSE_STD_DEFAULT comment and also not VC6 as it
+// support using standard containers and that VC6 needs non-default options for
-// needs non-default options for such build to avoid getting "fatal error
+// such build to avoid getting "fatal error C1076: compiler limit : internal
-// C1076: compiler limit : internal heap limit reached; use /Zm to specify a
+// heap limit reached; use /Zm to specify a higher limit" in its own standard
-// higher limit" in its own standard headers, so you need to ensure you do
+// headers, so you need to ensure you do increase the heap size before enabling
-// increase the heap size before enabling this option for this compiler.
+// this option for this compiler.
 //
-// Recommended setting: 1 unless you use a system without good implementation
+// Default is 0 for compatibility reasons.
-// of STL.
+//
-#if defined(_MSC_VER) && _MSC_VER < 1300
+// Recommended setting: 1 unless compatibility with the official wxWidgets
-    #define wxUSE_STD_CONTAINERS 0
+// build and/or the existing code is a concern.
-#else
+#define wxUSE_STD_CONTAINERS 0
-    #define wxUSE_STD_CONTAINERS wxUSE_STD_DEFAULT
-#endif
 
 // Use standard C++ streams if 1 instead of wx streams in some places. If
 // disabled, wx streams are used everywhere and wxWidgets doesn't depend on the

include/wx/os2/setup0.h

@@ -303,20 +303,18 @@
 // usually more limited) implementations are used which allows to avoid the
 // dependency on the C++ run-time library.
 //
-// Default is 1 if compiler supports it. Currently this means not one of the
+// Notice that the compilers mentioned in wxUSE_STD_DEFAULT comment above don't
-// compilers mentioned in wxUSE_STD_DEFAULT comment and also not VC6 as it
+// support using standard containers and that VC6 needs non-default options for
-// needs non-default options for such build to avoid getting "fatal error
+// such build to avoid getting "fatal error C1076: compiler limit : internal
-// C1076: compiler limit : internal heap limit reached; use /Zm to specify a
+// heap limit reached; use /Zm to specify a higher limit" in its own standard
-// higher limit" in its own standard headers, so you need to ensure you do
+// headers, so you need to ensure you do increase the heap size before enabling
-// increase the heap size before enabling this option for this compiler.
+// this option for this compiler.
 //
-// Recommended setting: 1 unless you use a system without good implementation
+// Default is 0 for compatibility reasons.
-// of STL.
+//
-#if defined(_MSC_VER) && _MSC_VER < 1300
+// Recommended setting: 1 unless compatibility with the official wxWidgets
-    #define wxUSE_STD_CONTAINERS 0
+// build and/or the existing code is a concern.
-#else
+#define wxUSE_STD_CONTAINERS 0
-    #define wxUSE_STD_CONTAINERS wxUSE_STD_DEFAULT
-#endif
 
 // Use standard C++ streams if 1 instead of wx streams in some places. If
 // disabled, wx streams are used everywhere and wxWidgets doesn't depend on the

include/wx/osx/setup0.h

@@ -304,20 +304,18 @@
 // usually more limited) implementations are used which allows to avoid the
 // dependency on the C++ run-time library.
 //
-// Default is 1 if compiler supports it. Currently this means not one of the
+// Notice that the compilers mentioned in wxUSE_STD_DEFAULT comment above don't
-// compilers mentioned in wxUSE_STD_DEFAULT comment and also not VC6 as it
+// support using standard containers and that VC6 needs non-default options for
-// needs non-default options for such build to avoid getting "fatal error
+// such build to avoid getting "fatal error C1076: compiler limit : internal
-// C1076: compiler limit : internal heap limit reached; use /Zm to specify a
+// heap limit reached; use /Zm to specify a higher limit" in its own standard
-// higher limit" in its own standard headers, so you need to ensure you do
+// headers, so you need to ensure you do increase the heap size before enabling
-// increase the heap size before enabling this option for this compiler.
+// this option for this compiler.
 //
-// Recommended setting: 1 unless you use a system without good implementation
+// Default is 0 for compatibility reasons.
-// of STL.
+//
-#if defined(_MSC_VER) && _MSC_VER < 1300
+// Recommended setting: 1 unless compatibility with the official wxWidgets
-    #define wxUSE_STD_CONTAINERS 0
+// build and/or the existing code is a concern.
-#else
+#define wxUSE_STD_CONTAINERS 0
-    #define wxUSE_STD_CONTAINERS wxUSE_STD_DEFAULT
-#endif
 
 // Use standard C++ streams if 1 instead of wx streams in some places. If
 // disabled, wx streams are used everywhere and wxWidgets doesn't depend on the

include/wx/palmos/setup0.h

@@ -303,20 +303,18 @@
 // usually more limited) implementations are used which allows to avoid the
 // dependency on the C++ run-time library.
 //
-// Default is 1 if compiler supports it. Currently this means not one of the
+// Notice that the compilers mentioned in wxUSE_STD_DEFAULT comment above don't
-// compilers mentioned in wxUSE_STD_DEFAULT comment and also not VC6 as it
+// support using standard containers and that VC6 needs non-default options for
-// needs non-default options for such build to avoid getting "fatal error
+// such build to avoid getting "fatal error C1076: compiler limit : internal
-// C1076: compiler limit : internal heap limit reached; use /Zm to specify a
+// heap limit reached; use /Zm to specify a higher limit" in its own standard
-// higher limit" in its own standard headers, so you need to ensure you do
+// headers, so you need to ensure you do increase the heap size before enabling
-// increase the heap size before enabling this option for this compiler.
+// this option for this compiler.
 //
-// Recommended setting: 1 unless you use a system without good implementation
+// Default is 0 for compatibility reasons.
-// of STL.
+//
-#if defined(_MSC_VER) && _MSC_VER < 1300
+// Recommended setting: 1 unless compatibility with the official wxWidgets
-    #define wxUSE_STD_CONTAINERS 0
+// build and/or the existing code is a concern.
-#else
+#define wxUSE_STD_CONTAINERS 0
-    #define wxUSE_STD_CONTAINERS wxUSE_STD_DEFAULT
-#endif
 
 // Use standard C++ streams if 1 instead of wx streams in some places. If
 // disabled, wx streams are used everywhere and wxWidgets doesn't depend on the

include/wx/setup_inc.h

@@ -299,20 +299,18 @@
 // usually more limited) implementations are used which allows to avoid the
 // dependency on the C++ run-time library.
 //
-// Default is 1 if compiler supports it. Currently this means not one of the
+// Notice that the compilers mentioned in wxUSE_STD_DEFAULT comment above don't
-// compilers mentioned in wxUSE_STD_DEFAULT comment and also not VC6 as it
+// support using standard containers and that VC6 needs non-default options for
-// needs non-default options for such build to avoid getting "fatal error
+// such build to avoid getting "fatal error C1076: compiler limit : internal
-// C1076: compiler limit : internal heap limit reached; use /Zm to specify a
+// heap limit reached; use /Zm to specify a higher limit" in its own standard
-// higher limit" in its own standard headers, so you need to ensure you do
+// headers, so you need to ensure you do increase the heap size before enabling
-// increase the heap size before enabling this option for this compiler.
+// this option for this compiler.
 //
-// Recommended setting: 1 unless you use a system without good implementation
+// Default is 0 for compatibility reasons.
-// of STL.
+//
-#if defined(_MSC_VER) && _MSC_VER < 1300
+// Recommended setting: 1 unless compatibility with the official wxWidgets
-    #define wxUSE_STD_CONTAINERS 0
+// build and/or the existing code is a concern.
-#else
+#define wxUSE_STD_CONTAINERS 0
-    #define wxUSE_STD_CONTAINERS wxUSE_STD_DEFAULT
-#endif
 
 // Use standard C++ streams if 1 instead of wx streams in some places. If
 // disabled, wx streams are used everywhere and wxWidgets doesn't depend on the

include/wx/univ/setup0.h

@@ -302,20 +302,18 @@
 // usually more limited) implementations are used which allows to avoid the
 // dependency on the C++ run-time library.
 //
-// Default is 1 if compiler supports it. Currently this means not one of the
+// Notice that the compilers mentioned in wxUSE_STD_DEFAULT comment above don't
-// compilers mentioned in wxUSE_STD_DEFAULT comment and also not VC6 as it
+// support using standard containers and that VC6 needs non-default options for
-// needs non-default options for such build to avoid getting "fatal error
+// such build to avoid getting "fatal error C1076: compiler limit : internal
-// C1076: compiler limit : internal heap limit reached; use /Zm to specify a
+// heap limit reached; use /Zm to specify a higher limit" in its own standard
-// higher limit" in its own standard headers, so you need to ensure you do
+// headers, so you need to ensure you do increase the heap size before enabling
-// increase the heap size before enabling this option for this compiler.
+// this option for this compiler.
 //
-// Recommended setting: 1 unless you use a system without good implementation
+// Default is 0 for compatibility reasons.
-// of STL.
+//
-#if defined(_MSC_VER) && _MSC_VER < 1300
+// Recommended setting: 1 unless compatibility with the official wxWidgets
-    #define wxUSE_STD_CONTAINERS 0
+// build and/or the existing code is a concern.
-#else
+#define wxUSE_STD_CONTAINERS 0
-    #define wxUSE_STD_CONTAINERS wxUSE_STD_DEFAULT
-#endif
 
 // Use standard C++ streams if 1 instead of wx streams in some places. If
 // disabled, wx streams are used everywhere and wxWidgets doesn't depend on the

setup.h.in

@@ -216,11 +216,7 @@
     #define wxUSE_STD_DEFAULT  0
 #endif
 
-#if defined(_MSC_VER) && _MSC_VER < 1300
+#define wxUSE_STD_CONTAINERS 0
-    #define wxUSE_STD_CONTAINERS 0
-#else
-    #define wxUSE_STD_CONTAINERS wxUSE_STD_DEFAULT
-#endif
 
 #define wxUSE_STD_IOSTREAM  wxUSE_STD_DEFAULT