From fcc4e6ef1a7183828dd83ab3e28cddb9ddcd009c Mon Sep 17 00:00:00 2001 From: Jurko Date: Thu, 27 Nov 2014 02:27:25 +0100 Subject: [PATCH] trim trailing spaces --- doc/design.xml | 20 ++-- doc/overview.xml | 106 +++++++++--------- .../boost/program_options/eof_iterator.hpp | 34 +++--- include/boost/program_options/parsers.hpp | 68 +++++------ .../boost/program_options/variables_map.hpp | 34 +++--- 5 files changed, 131 insertions(+), 131 deletions(-) diff --git a/doc/design.xml b/doc/design.xml index 3051e5e..86f440a 100644 --- a/doc/design.xml +++ b/doc/design.xml @@ -22,7 +22,7 @@ not mean strict 7-bit ASCII encoding, but rather "char" strings in local 8-bit encoding. - + Generally, "Unicode support" can mean many things, but for the program_options library it means that: @@ -54,7 +54,7 @@ passed to an ascii value will be converted using a codecvt facet (which may be specified by the user). - + @@ -94,7 +94,7 @@ The primary question in implementing the Unicode support is whether to use templates and std::basic_string or to use some internal encoding and convert between internal and external encodings on - the interface boundaries. + the interface boundaries. The choice, mostly, is between code size and execution @@ -171,14 +171,14 @@ number of new instantiations. - + There's no clear leader, but the last point seems important, so UTF-8 - will be used. + will be used. - Choosing the UTF-8 encoding allows the use of existing parsers, - because 7-bit ascii characters retain their values in UTF-8, + Choosing the UTF-8 encoding allows the use of existing parsers, + because 7-bit ascii characters retain their values in UTF-8, so searching for 7-bit strings is simple. However, there are two subtle issues: @@ -197,16 +197,16 @@ almost universal encoding and since composing characters following '=' (and other characters with special meaning to the library) are not likely to appear. - + - + - +
@@ -390,7 +390,7 @@ pd.add("output-file", 2).add("input-file", -1); The results of parsing are returned as an instance of the &parsed_options; class. Typically, that object is passed directly to the storage component. However, it also can be used directly, or undergo some additional - processing. + processing. @@ -422,8 +422,8 @@ pd.add("output-file", 2).add("input-file", -1); - - + +
@@ -512,7 +512,7 @@ visual_bell=yes gui.accessibility.visual_bell=yes - +
@@ -538,7 +538,7 @@ gui.accessibility.visual_bell=yes what option names must correspond to it. To describe the second parameter we need to consider naming conventions for environment variables. - + If you have an option that should be specified via environment variable, you need make up the variable's name. To avoid name clashes, we suggest that you use a sufficiently unique prefix for environment @@ -551,9 +551,9 @@ gui.accessibility.visual_bell=yes Say, if you pass BOOST_ as the prefix, and there are two variables, CVSROOT and BOOST_PROXY, the first variable will be ignored, and the second one will be converted to - option proxy. + option proxy. - + The above logic is sufficient in many cases, but it is also possible to pass, as the second parameter of the &parse_environment; function, any function taking a std::string and returning @@ -561,35 +561,35 @@ gui.accessibility.visual_bell=yes environment variable and should return either the name of the option, or empty string if the variable should be ignored. - +
Annotated List of Symbols - + The following table describes all the important symbols in the library, for quick access. - + - + - - + + Symbol Description - + - - + + Options description component - + &options_description; describes a number of options @@ -599,10 +599,10 @@ gui.accessibility.visual_bell=yes defines the option's value - + Parsers component - + &parse_command_line; parses command line (simpified interface) @@ -624,7 +624,7 @@ gui.accessibility.visual_bell=yes parses environment - + Storage component @@ -632,20 +632,20 @@ gui.accessibility.visual_bell=yes &variables_map; storage for option values - + - + - +
- +