| <sect1 id="manual.intro.setup.test" xreflabel="Testing"> |
| <?dbhtml filename="test.html"?> |
| |
| <sect1info> |
| <keywordset> |
| <keyword> |
| ISO C++ |
| </keyword> |
| <keyword> |
| test |
| </keyword> |
| <keyword> |
| testsuite |
| </keyword> |
| <keyword> |
| performance |
| </keyword> |
| <keyword> |
| conformance |
| </keyword> |
| <keyword> |
| ABI |
| </keyword> |
| <keyword> |
| exception safety |
| </keyword> |
| </keywordset> |
| </sect1info> |
| |
| <title>Test</title> |
| |
| <para> |
| The libstdc++ testsuite includes testing for standard conformance, |
| regressions, ABI, and performance. |
| </para> |
| |
| <sect2 id="test.organization" xreflabel="test.organization"> |
| <title>Organization</title> |
| |
| <sect3 id="test.organization.layout" xreflabel="Directory Layout"> |
| <title>Directory Layout</title> |
| |
| <para> |
| The directory <emphasis>libsrcdir/testsuite</emphasis> contains the |
| individual test cases organized in sub-directories corresponding to |
| chapters of the C++ standard (detailed below), the dejagnu test |
| harness support files, and sources to various testsuite utilities |
| that are packaged in a separate testing library. |
| </para> |
| |
| <para> |
| All test cases for functionality required by the runtime components |
| of the C++ standard (ISO 14882) are files within the following |
| directories. |
| </para> |
| |
| <programlisting> |
| 17_intro |
| 18_support |
| 19_diagnostics |
| 20_util |
| 21_strings |
| 22_locale |
| 23_containers |
| 25_algorithms |
| 26_numerics |
| 27_io |
| </programlisting> |
| |
| <para> |
| In addition, the following directories include test files: |
| </para> |
| |
| <programlisting> |
| tr1 Tests for components as described by the Technical Report on Standard Library Extensions (TR1). |
| backward Tests for backwards compatibility and deprecated features. |
| demangle Tests for __cxa_demangle, the IA 64 C++ ABI demangler |
| ext Tests for extensions. |
| performance Tests for performance analysis, and performance regressions. |
| thread Tests for threads. |
| </programlisting> |
| |
| <para> |
| Some directories don't have test files, but instead contain |
| auxiliary information (<ulink url="#internals">more information</ulink>): |
| </para> |
| |
| <programlisting> |
| config Files for the dejagnu test harness. |
| lib Files for the dejagnu test harness. |
| libstdc++* Files for the dejagnu test harness. |
| data Sample text files for testing input and output. |
| util Files for libtestc++, utilities and testing routines. |
| </programlisting> |
| |
| <para> |
| Within a directory that includes test files, there may be |
| additional subdirectories, or files. Originally, test cases |
| were appended to one file that represented a particular section |
| of the chapter under test, and was named accordingly. For |
| instance, to test items related to <code> 21.3.6.1 - |
| basic_string::find [lib.string::find]</code> in the standard, |
| the following was used: |
| </para> |
| <programlisting> |
| 21_strings/find.cc |
| </programlisting> |
| <para> |
| However, that practice soon became a liability as the test cases |
| became huge and unwieldy, and testing new or extended |
| functionality (like wide characters or named locales) became |
| frustrating, leading to aggressive pruning of test cases on some |
| platforms that covered up implementation errors. Now, the test |
| suite has a policy of one file, one test case, which solves the |
| above issues and gives finer grained results and more manageable |
| error debugging. As an example, the test case quoted above |
| becomes: |
| </para> |
| <programlisting> |
| 21_strings/basic_string/find/char/1.cc |
| 21_strings/basic_string/find/char/2.cc |
| 21_strings/basic_string/find/char/3.cc |
| 21_strings/basic_string/find/wchar_t/1.cc |
| 21_strings/basic_string/find/wchar_t/2.cc |
| 21_strings/basic_string/find/wchar_t/3.cc |
| </programlisting> |
| |
| <para> |
| All new tests should be written with the policy of one test |
| case, one file in mind. |
| </para> |
| </sect3> |
| |
| |
| <sect3 id="test.organization.naming" xreflabel="Naming Conventions"> |
| <title>Naming Conventions</title> |
| |
| <para> |
| In addition, there are some special names and suffixes that are |
| used within the testsuite to designate particular kinds of |
| tests. |
| </para> |
| |
| <itemizedlist> |
| <listitem> |
| <para> |
| <emphasis>_xin.cc</emphasis> |
| </para> |
| <para> |
| This test case expects some kind of interactive input in order |
| to finish or pass. At the moment, the interactive tests are not |
| run by default. Instead, they are run by hand, like: |
| </para> |
| <programlisting> |
| g++ 27_io/objects/char/3_xin.cc |
| cat 27_io/objects/char/3_xin.in | a.out |
| </programlisting> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>.in</emphasis> |
| </para> |
| <para> |
| This file contains the expected input for the corresponding <emphasis> |
| _xin.cc</emphasis> test case. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>_neg.cc</emphasis> |
| </para> |
| <para> |
| This test case is expected to fail: it's a negative test. At the |
| moment, these are almost always compile time errors. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>char</emphasis> |
| </para> |
| <para> |
| This can either be a directory name or part of a longer file |
| name, and indicates that this file, or the files within this |
| directory are testing the <code>char</code> instantiation of a |
| template. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>wchar_t</emphasis> |
| </para> |
| <para> |
| This can either be a directory name or part of a longer file |
| name, and indicates that this file, or the files within this |
| directory are testing the <code>wchar_t</code> instantiation of |
| a template. Some hosts do not support <code>wchar_t</code> |
| functionality, so for these targets, all of these tests will not |
| be run. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>thread</emphasis> |
| </para> |
| <para> |
| This can either be a directory name or part of a longer file |
| name, and indicates that this file, or the files within this |
| directory are testing situations where multiple threads are |
| being used. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>performance</emphasis> |
| </para> |
| <para> |
| This can either be an enclosing directory name or part of a |
| specific file name. This indicates a test that is used to |
| analyze runtime performance, for performance regression testing, |
| or for other optimization related analysis. At the moment, these |
| test cases are not run by default. |
| </para> |
| </listitem> |
| </itemizedlist> |
| |
| </sect3> |
| </sect2> |
| |
| |
| <sect2 id="test.run" xreflabel="test.run"> |
| <title>Running the Testsuite</title> |
| |
| <sect3 id="test.run.basic" xreflabel="test.run.basic"> |
| <title>Basic</title> |
| |
| <para> |
| You can check the status of the build without installing it |
| using the dejagnu harness, much like the rest of the gcc |
| tools.</para> |
| <programlisting> make check</programlisting> |
| <para>in the <emphasis>libbuilddir</emphasis> directory.</para> |
| <para>or</para> |
| <programlisting> make check-target-libstdc++-v3</programlisting> |
| <para>in the <emphasis>gccbuilddir</emphasis> directory. |
| </para> |
| |
| <para> |
| These commands are functionally equivalent and will create a |
| 'testsuite' directory underneath |
| <emphasis>libbuilddir</emphasis> containing the results of the |
| tests. Two results files will be generated: <emphasis> |
| libstdc++.sum</emphasis>, which is a PASS/FAIL summary for each |
| test, and <emphasis>libstdc++.log</emphasis> which is a log of |
| the exact command line passed to the compiler, the compiler |
| output, and the executable output (if any). |
| </para> |
| |
| <para> |
| Archives of test results for various versions and platforms are |
| available on the GCC website in the <ulink |
| url="http://gcc.gnu.org/gcc-4.3/buildstat.html">build |
| status</ulink> section of each individual release, and are also |
| archived on a daily basis on the <ulink |
| url="http://gcc.gnu.org/ml/gcc-testresults/current">gcc-testresults</ulink> |
| mailing list. Please check either of these places for a similar |
| combination of source version, operating system, and host CPU. |
| </para> |
| </sect3> |
| |
| <sect3 id="test.run.variations" xreflabel="test.run.variations"> |
| <title>Variations</title> |
| <para> |
| There are several options for running tests, including testing |
| the regression tests, testing a subset of the regression tests, |
| testing the performance tests, testing just compilation, testing |
| installed tools, etc. In addition, there is a special rule for |
| checking the exported symbols of the shared library. |
| </para> |
| <para> |
| To debug the dejagnu test harness during runs, try invoking with a |
| specific argument to the variable RUNTESTFLAGS, as below. |
| </para> |
| |
| <programlisting> |
| make check-target-libstdc++-v3 RUNTESTFLAGS="-v" |
| </programlisting> |
| |
| <para> |
| or |
| </para> |
| |
| <programlisting> |
| make check-target-libstdc++-v3 RUNTESTFLAGS="-v -v" |
| </programlisting> |
| |
| <para> |
| To run a subset of the library tests, you will need to generate |
| the <emphasis>testsuite_files</emphasis> file by running |
| <command>make testsuite_files</command> in the |
| <emphasis>libbuilddir/testsuite</emphasis> directory, described |
| below. Edit the file to remove the tests you don't want and |
| then run the testsuite as normal. |
| </para> |
| |
| <para> |
| There are two ways to run on a simulator: set up DEJAGNU to point to a |
| specially crafted site.exp, or pass down --target_board flags. |
| </para> |
| |
| <para> |
| Example flags to pass down for various embedded builds are as follows: |
| </para> |
| |
| <programlisting> |
| --target=powerpc-eabism (libgloss/sim) |
| make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=powerpc-sim" |
| |
| --target=calmrisc32 (libgloss/sid) |
| make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=calmrisc32-sid" |
| |
| --target=xscale-elf (newlib/sim) |
| make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=arm-sim" |
| </programlisting> |
| |
| <para> |
| Also, here is an example of how to run the libstdc++ testsuite |
| for a multilibed build directory with different ABI settings: |
| </para> |
| |
| <programlisting> |
| make check-target-libstdc++-v3 RUNTESTFLAGS='--target_board \"unix{-mabi=32,,-mabi=64}\"' |
| </programlisting> |
| |
| <para> |
| You can run the tests with a compiler and library that have |
| already been installed. Make sure that the compiler (e.g., |
| <code>g++</code>) is in your <code>PATH</code>. If you are |
| using shared libraries, then you must also ensure that the |
| directory containing the shared version of libstdc++ is in your |
| <code>LD_LIBRARY_PATH</code>, or equivalent. If your GCC source |
| tree is at <code>/path/to/gcc</code>, then you can run the tests |
| as follows: |
| </para> |
| |
| <programlisting> |
| runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite |
| </programlisting> |
| |
| <para> |
| The testsuite will create a number of files in the directory in |
| which you run this command,. Some of those files might use the |
| same name as files created by other testsuites (like the ones |
| for GCC and G++), so you should not try to run all the |
| testsuites in parallel from the same directory. |
| </para> |
| |
| <para> |
| In addition, there are some testing options that are mostly of |
| interest to library maintainers and system integrators. As such, |
| these tests may not work on all cpu and host combinations, and |
| may need to be executed in the |
| <emphasis>libbuilddir/testsuite</emphasis> directory. These |
| options include, but are not necessarily limited to, the |
| following: |
| </para> |
| |
| <programlisting> |
| make testsuite_files |
| </programlisting> |
| |
| <para> |
| Five files are generated that determine what test files |
| are run. These files are: |
| </para> |
| |
| <itemizedlist> |
| <listitem> |
| <para> |
| <emphasis>testsuite_files</emphasis> |
| </para> |
| <para> |
| This is a list of all the test cases that will be run. Each |
| test case is on a separate line, given with an absolute path |
| from the <emphasis>libsrcdir/testsuite</emphasis> directory. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| <emphasis>testsuite_files_interactive</emphasis> |
| </para> |
| <para> |
| This is a list of all the interactive test cases, using the |
| same format as the file list above. These tests are not run |
| by default. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| <emphasis>testsuite_files_performance</emphasis> |
| </para> |
| <para> |
| This is a list of all the performance test cases, using the |
| same format as the file list above. These tests are not run |
| by default. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| <emphasis>testsuite_thread</emphasis> |
| </para> |
| <para> |
| This file indicates that the host system can run tests which |
| involved multiple threads. |
| </para> |
| </listitem> |
| |
| <listitem> |
| <para> |
| <emphasis>testsuite_wchar_t</emphasis> |
| </para> |
| <para> |
| This file indicates that the host system can run the wchar_t |
| tests, and corresponds to the macro definition <code> |
| _GLIBCXX_USE_WCHAR_T</code> in the file c++config.h. |
| </para> |
| </listitem> |
| </itemizedlist> |
| |
| <programlisting> |
| make check-abi |
| </programlisting> |
| |
| <para> |
| The library ABI can be tested. This involves testing the shared |
| library against an ABI-defining previous version of symbol |
| exports. |
| </para> |
| |
| <programlisting> |
| make check-compile |
| </programlisting> |
| |
| <para> |
| This rule compiles, but does not link or execute, the |
| <emphasis>testsuite_files</emphasis> test cases and displays the |
| output on stdout. |
| </para> |
| |
| <programlisting> |
| make check-performance |
| </programlisting> |
| |
| <para> |
| This rule runs through the |
| <emphasis>testsuite_files_performance</emphasis> test cases and |
| collects information for performance analysis and can be used to |
| spot performance regressions. Various timing information is |
| collected, as well as number of hard page faults, and memory |
| used. This is not run by default, and the implementation is in |
| flux. |
| </para> |
| |
| <para> |
| We are interested in any strange failures of the testsuite; |
| please email the main libstdc++ mailing list if you see |
| something odd or have questions. |
| </para> |
| </sect3> |
| |
| <sect3 id="test.run.permutations" xreflabel="test.run.permutations"> |
| <title>Permutations</title> |
| <para> |
| To run the libstdc++ test suite under the <link |
| linkend="manual.ext.debug_mode">debug mode</link>, edit |
| <filename>libstdc++-v3/scripts/testsuite_flags</filename> to add the |
| compile-time flag <constant>-D_GLIBCXX_DEBUG</constant> to the |
| result printed by the <literal>--build-cxx</literal> |
| option. Additionally, add the |
| <constant>-D_GLIBCXX_DEBUG_PEDANTIC</constant> flag to turn on |
| pedantic checking. The libstdc++ test suite should produce |
| precisely the same results under debug mode that it does under |
| release mode: any deviation indicates an error in either the |
| library or the test suite. |
| </para> |
| |
| <para> |
| The <link linkend="manual.ext.parallel_mode">parallel |
| mode</link> can be tested in much the same manner, substituting |
| <constant>-D_GLIBCXX_PARALLEL</constant> for |
| <constant>-D_GLIBCXX_DEBUG</constant> in the previous paragraph. |
| </para> |
| |
| <para> |
| Or, just run the testsuites with <constant>CXXFLAGS</constant> |
| set to <constant>-D_GLIBCXX_DEBUG</constant> or |
| <constant>-D_GLIBCXX_PARALLEL</constant>. |
| </para> |
| </sect3> |
| </sect2> |
| |
| <sect2 id="test.new_tests" xreflabel="test.new_tests"> |
| <title>Writing a new test case</title> |
| |
| <para> |
| The first step in making a new test case is to choose the correct |
| directory and file name, given the organization as previously |
| described. |
| </para> |
| |
| <para> |
| All files are copyright the FSF, and GPL'd: this is very |
| important. The first copyright year should correspond to the date |
| the file was checked in to SVN. |
| </para> |
| |
| <para> |
| As per the dejagnu instructions, always return 0 from main to |
| indicate success. |
| </para> |
| |
| <para> |
| A bunch of utility functions and classes have already been |
| abstracted out into the testsuite utility library, <code> |
| libtestc++</code>. To use this functionality, just include the |
| appropriate header file: the library or specific object files will |
| automatically be linked in as part of the testsuite run. |
| </para> |
| |
| <para> |
| For a test that needs to take advantage of the dejagnu test |
| harness, what follows below is a list of special keyword that |
| harness uses. Basically, a test case contains dg-keywords (see |
| dg.exp) indicating what to do and what kinds of behavior are to be |
| expected. New test cases should be written with the new style |
| DejaGnu framework in mind. |
| </para> |
| |
| <para> |
| To ease transition, here is the list of dg-keyword documentation |
| lifted from dg.exp. |
| </para> |
| |
| <programlisting> |
| # The currently supported options are: |
| # |
| # dg-prms-id N |
| # set prms_id to N |
| # |
| # dg-options "options ..." [{ target selector }] |
| # specify special options to pass to the tool (eg: compiler) |
| # |
| # dg-do do-what-keyword [{ target/xfail selector }] |
| # `do-what-keyword' is tool specific and is passed unchanged to |
| # ${tool}-dg-test. An example is gcc where `keyword' can be any of: |
| # preprocess|compile|assemble|link|run |
| # and will do one of: produce a .i, produce a .s, produce a .o, |
| # produce an a.out, or produce an a.out and run it (the default is |
| # compile). |
| # |
| # dg-error regexp comment [{ target/xfail selector } [{.|0|linenum}]] |
| # indicate an error message <regexp> is expected on this line |
| # (the test fails if it doesn't occur) |
| # Linenum=0 for general tool messages (eg: -V arg missing). |
| # "." means the current line. |
| # |
| # dg-warning regexp comment [{ target/xfail selector } [{.|0|linenum}]] |
| # indicate a warning message <regexp> is expected on this line |
| # (the test fails if it doesn't occur) |
| # |
| # dg-bogus regexp comment [{ target/xfail selector } [{.|0|linenum}]] |
| # indicate a bogus error message <regexp> use to occur here |
| # (the test fails if it does occur) |
| # |
| # dg-build regexp comment [{ target/xfail selector }] |
| # indicate the build use to fail for some reason |
| # (errors covered here include bad assembler generated, tool crashes, |
| # and link failures) |
| # (the test fails if it does occur) |
| # |
| # dg-excess-errors comment [{ target/xfail selector }] |
| # indicate excess errors are expected (any line) |
| # (this should only be used sparingly and temporarily) |
| # |
| # dg-output regexp [{ target selector }] |
| # indicate the expected output of the program is <regexp> |
| # (there may be multiple occurrences of this, they are concatenated) |
| # |
| # dg-final { tcl code } |
| # add some tcl code to be run at the end |
| # (there may be multiple occurrences of this, they are concatenated) |
| # (unbalanced braces must be \-escaped) |
| # |
| # "{ target selector }" is a list of expressions that determine whether the |
| # test succeeds or fails for a particular target, or in some cases whether the |
| # option applies for a particular target. If the case of `dg-do' it specifies |
| # whether the test case is even attempted on the specified target. |
| # |
| # The target selector is always optional. The format is one of: |
| # |
| # { xfail *-*-* ... } - the test is expected to fail for the given targets |
| # { target *-*-* ... } - the option only applies to the given targets |
| # |
| # At least one target must be specified, use *-*-* for "all targets". |
| # At present it is not possible to specify both `xfail' and `target'. |
| # "native" may be used in place of "*-*-*". |
| |
| Example 1: Testing compilation only |
| // { dg-do compile } |
| |
| Example 2: Testing for expected warnings on line 36, which all targets fail |
| // { dg-warning "string literals" "" { xfail *-*-* } 36 |
| |
| Example 3: Testing for expected warnings on line 36 |
| // { dg-warning "string literals" "" { target *-*-* } 36 |
| |
| Example 4: Testing for compilation errors on line 41 |
| // { dg-do compile } |
| // { dg-error "no match for" "" { target *-*-* } 41 } |
| |
| Example 5: Testing with special command line settings, or without the |
| use of pre-compiled headers, in particular the stdc++.h.gch file. Any |
| options here will override the DEFAULT_CXXFLAGS and PCH_CXXFLAGS set |
| up in the normal.exp file. |
| // { dg-options "-O0" { target *-*-* } } |
| </programlisting> |
| |
| <para> |
| More examples can be found in the libstdc++-v3/testsuite/*/*.cc files. |
| </para> |
| </sect2> |
| |
| |
| <sect2 id="test.harness" xreflabel="Test Harness and Utilities"> |
| <title>Test Harness and Utilities</title> |
| |
| <sect3 id="test.harness.dejagnu" xreflabel="test.harness.dejagnu"> |
| <title>Dejagnu Harness Details</title> |
| <para> |
| Underlying details of testing for conformance and regressions are |
| abstracted via the GNU Dejagnu package. This is similar to the |
| rest of GCC. |
| </para> |
| |
| |
| <para>This is information for those looking at making changes to the testsuite |
| structure, and/or needing to trace dejagnu's actions with --verbose. This |
| will not be useful to people who are "merely" adding new tests to the existing |
| structure. |
| </para> |
| |
| <para>The first key point when working with dejagnu is the idea of a "tool". |
| Files, directories, and functions are all implicitly used when they are |
| named after the tool in use. Here, the tool will always be "libstdc++". |
| </para> |
| |
| <para>The <code>lib</code> subdir contains support routines. The |
| <code>lib/libstdc++.exp</code> file ("support library") is loaded |
| automagically, and must explicitly load the others. For example, files can |
| be copied from the core compiler's support directory into <code>lib</code>. |
| </para> |
| |
| <para>Some routines in <code>lib/libstdc++.exp</code> are callbacks, some are |
| our own. Callbacks must be prefixed with the name of the tool. To easily |
| distinguish the others, by convention our own routines are named "v3-*". |
| </para> |
| |
| <para>The next key point when working with dejagnu is "test files". Any |
| directory whose name starts with the tool name will be searched for test files. |
| (We have only one.) In those directories, any <code>.exp</code> file is |
| considered a test file, and will be run in turn. Our main test file is called |
| <code>normal.exp</code>; it runs all the tests in testsuite_files using the |
| callbacks loaded from the support library. |
| </para> |
| |
| <para>The <code>config</code> directory is searched for any particular "target |
| board" information unique to this library. This is currently unused and sets |
| only default variables. |
| </para> |
| |
| </sect3> |
| |
| <sect3 id="test.harness.utils" xreflabel="test.utils"> |
| <title>Utilities</title> |
| <para> |
| </para> |
| <para> |
| The testsuite directory also contains some files that implement |
| functionality that is intended to make writing test cases easier, |
| or to avoid duplication, or to provide error checking in a way that |
| is consistent across platforms and test harnesses. A stand-alone |
| executable, called <emphasis>abi_check</emphasis>, and a static |
| library called <emphasis>libtestc++</emphasis> are |
| constructed. Both of these items are not installed, and only used |
| during testing. |
| </para> |
| |
| <para> |
| These files include the following functionality: |
| </para> |
| |
| <itemizedlist> |
| <listitem> |
| <para> |
| <emphasis>testsuite_abi.h</emphasis>, |
| <emphasis>testsuite_abi.cc</emphasis>, |
| <emphasis>testsuite_abi_check.cc</emphasis> |
| </para> |
| <para> |
| Creates the executable <emphasis>abi_check</emphasis>. |
| Used to check correctness of symbol versioning, visibility of |
| exported symbols, and compatibility on symbols in the shared |
| library, for hosts that support this feature. More information |
| can be found in the ABI documentation <ulink url="abi.html">here</ulink> |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>testsuite_allocator.h</emphasis>, |
| <emphasis>testsuite_allocator.cc</emphasis> |
| </para> |
| <para> |
| Contains specialized allocators that keep track of construction |
| and destruction. Also, support for overriding global new and |
| delete operators, including verification that new and delete |
| are called during execution, and that allocation over max_size |
| fails. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>testsuite_character.h</emphasis> |
| </para> |
| <para> |
| Contains <code>std::char_traits</code> and |
| <code>std::codecvt</code> specializations for a user-defined |
| POD. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>testsuite_hooks.h</emphasis>, |
| <emphasis>testsuite_hooks.cc</emphasis> |
| </para> |
| <para> |
| A large number of utilities, including: |
| </para> |
| <itemizedlist> |
| <listitem><para>VERIFY</para></listitem> |
| <listitem><para>set_memory_limits</para></listitem> |
| <listitem><para>verify_demangle</para></listitem> |
| <listitem><para>run_tests_wrapped_locale</para></listitem> |
| <listitem><para>run_tests_wrapped_env</para></listitem> |
| <listitem><para>try_named_locale</para></listitem> |
| <listitem><para>try_mkfifo</para></listitem> |
| <listitem><para>func_callback</para></listitem> |
| <listitem><para>counter</para></listitem> |
| <listitem><para>copy_tracker</para></listitem> |
| <listitem><para>copy_constructor</para></listitem> |
| <listitem><para>assignment_operator</para></listitem> |
| <listitem><para>destructor</para></listitem> |
| <listitem> |
| <para>pod_char, pod_int and associated char_traits specializations</para> |
| </listitem> |
| </itemizedlist> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>testsuite_io.h</emphasis> |
| </para> |
| <para> |
| Error, exception, and constraint checking for |
| <code>std::streambuf, std::basic_stringbuf, std::basic_filebuf</code>. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>testsuite_iterators.h</emphasis> |
| </para> |
| <para> |
| Wrappers for various iterators. |
| </para> |
| </listitem> |
| <listitem> |
| <para> |
| <emphasis>testsuite_performance.h</emphasis> |
| </para> |
| <para> |
| A number of class abstractions for performance counters, and |
| reporting functions including: |
| </para> |
| <itemizedlist> |
| <listitem><para>time_counter</para></listitem> |
| <listitem><para>resource_counter</para></listitem> |
| <listitem><para>report_performance</para></listitem> |
| </itemizedlist> |
| </listitem> |
| </itemizedlist> |
| </sect3> |
| |
| </sect2> |
| </sect1> |