X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/06ad863606966ceee6e7eea537f8d427f0d891a9..ce756cb06a93facb4faa35a1d57c7038fc26e8e1:/docs/latex/wx/tcontain.tex?ds=inline diff --git a/docs/latex/wx/tcontain.tex b/docs/latex/wx/tcontain.tex index c2e7364f36..b05595b261 100644 --- a/docs/latex/wx/tcontain.tex +++ b/docs/latex/wx/tcontain.tex @@ -2,36 +2,36 @@ Classes: \helpref{wxList}{wxlist}, \helpref{wxArray}{wxarray} -wxWindows uses itself several container classes including doubly-linked lists +wxWidgets uses itself several container classes including doubly-linked lists and dynamic arrays (i.e. arrays which expand automatically when they become -full). For both historical and portability reasons wxWindows does not +full). For both historical and portability reasons wxWidgets does not use STL which provides the standard implementation of many container classes in -C++. First of all, wxWindows has existed since well before STL was written, and +C++. First of all, wxWidgets has existed since well before STL was written, and secondly we don't believe that today compilers can deal really well with all of STL classes (this is especially true for some less common platforms). Of course, the compilers are evolving quite rapidly and hopefully their progress -will allow to base future versions of wxWindows on STL - but this is not yet +will allow to base future versions of wxWidgets on STL - but this is not yet the case. -wxWindows container classes don't pretend to be as powerful or full as STL +wxWidgets container classes don't pretend to be as powerful or full as STL ones, but they are quite useful and may be compiled with absolutely any C++ -compiler. They're used internally by wxWindows, but may, of course, be used in +compiler. They're used internally by wxWidgets, but may, of course, be used in your programs as well if you wish. -The list classes in wxWindows are doubly-linked lists which may either own the +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 removed from the list or the list itself is destroyed) or just store the pointers depending on whether you called or not \helpref{wxList::DeleteContents}{wxlistdeletecontents} method. Dynamic arrays resemble C arrays but with two important differences: they -provide run-time range checking in debug builds and they expand automatically +provide run-time range checking in debug builds and they automatically expand the allocated memory when there is no more space for new items. They come in two sorts: the "plain" arrays which store either built-in types such as "char", "int" or "bool" or the pointers to arbitrary objects, or "object arrays" which own the object pointers to which they store. -For the same portability reasons, the container classes implementation in wxWindows +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 done with the macros: {\it WX\_DECLARE\_LIST} and {\it WX\_DEFINE\_LIST} for the linked lists and {\it WX\_DECLARE\_ARRAY}, {\it WX\_DECLARE\_OBJARRAY} and {\it WX\_DEFINE\_OBJARRAY} for @@ -47,7 +47,7 @@ no WX\_DEFINE\_ARRAY macro for them. Examples of usage of these macros may be found in \helpref{wxList}{wxlist} and \helpref{wxArray}{wxarray} documentation. -Finally, wxWindows predefines several commonly used container classes. wxList +Finally, wxWidgets predefines several commonly used container classes. wxList is defined for compatibility with previous versions as a list containing wxObjects and wxStringList as a list of C-style strings (char *), both of these classes are deprecated and should not be used in new programs. The following