Do not force PGI compiler to use fallback version of lexical_cast (PGI fails tests even in fallback version)

Trialing whitespaces removed

[SVN r78521]

doc/Jamfile.v2

@@ -6,9 +6,9 @@ using quickbook ;
 import boostbook : boostbook ;
 
 xml lexical_cast : lexical_cast.qbk ;
-boostbook standalone 
-    : 
-    lexical_cast 
+boostbook standalone
+    :
+    lexical_cast
     :
         <xsl:param>boost.root=../../../..
         <format>pdf:<xsl:param>boost.url.prefix=http://www.boost.org/doc/libs/release/doc/html

doc/lexical_cast.qbk

@@ -34,7 +34,7 @@ The standard C++ library offers `stringstream` for the kind of in-core formattin
 
 The `lexical_cast` function template offers a convenient and consistent form for supporting common conversions to and from arbitrary types when they are represented as text. The simplification it offers is in expression-level convenience for such conversions. For more involved conversions, such as where precision or formatting need tighter control than is offered by the default behavior of `lexical_cast`, the conventional `std::stringstream` approach is recommended. Where the conversions are numeric to numeric, __numericcast__ may offer more reasonable behavior than `lexical_cast`.
 
-For a good discussion of the options and issues involved in string-based formatting, including comparison of `stringstream`, `lexical_cast`, and others, see Herb Sutter's article, [@http://www.gotw.ca/publications/mill19.htm The String Formatters of Manor Farm]. Also, take a look at the [link boost_lexical_cast.performance Performance] section. 
+For a good discussion of the options and issues involved in string-based formatting, including comparison of `stringstream`, `lexical_cast`, and others, see Herb Sutter's article, [@http://www.gotw.ca/publications/mill19.htm The String Formatters of Manor Farm]. Also, take a look at the [link boost_lexical_cast.performance Performance] section.
 [endsect]
 
 [section Examples]
@@ -105,8 +105,8 @@ The character type of the underlying stream is assumed to be `char` unless eithe
 * `boost::iterator_range<WideCharPtr>`, where `WideCharPtr` is a pointer to wide-character or pointer to const wide-character
 
 [important Many compilers and runtime libraries fail to make conversions using new Unicode characters. Make shure that the following code compiles and outputs nonzero values, before using new types:
-`` 
-    std::cout 
+``
+    std::cout
         << booat::lexical_cast<std::u32string>(1.0).size()
         << "  "
         << booat::lexical_cast<std::u16string>(1.0).size();
@@ -151,13 +151,13 @@ Consider the following example:
             return data_length;
         }
     };
-    
+
     inline std::ostream& operator << (std::ostream& ostr, const example_class& rhs) {
         return ostr << boost::make_iterator_range(rhs.data(), rhs.data() + rhs.size());
     }
 ``
 
-This is a good generic solution for most use cases. 
+This is a good generic solution for most use cases.
 But we can make it even faster for some performance critical applications. During conversion, we loose speed at:
 
  * `std::ostream` construction     (it makes some heap allocations)
@@ -182,35 +182,35 @@ Now `boost::lexical_cast<some_type>(example_class_instance)` conversions won't c
 [section Frequently Asked Questions]
 
 * [*Question:]    Why does `lexical_cast<int8_t>("127")` throw `bad_lexical_cast`?
-  * [*Answer:]      The type `int8_t` is a `typedef` to `char` or `signed char`. Lexical conversion to these types is simply reading a byte from source but since the source has more than one byte, the exception is thrown. 
-Please use other integer types such as `int` or `short int`. If bounds checking is important, you can also 
-call __numericcast__: 
+  * [*Answer:]      The type `int8_t` is a `typedef` to `char` or `signed char`. Lexical conversion to these types is simply reading a byte from source but since the source has more than one byte, the exception is thrown.
+Please use other integer types such as `int` or `short int`. If bounds checking is important, you can also
+call __numericcast__:
 `numeric_cast<int8_t>(lexical_cast<int>("127"));`
 
 [pre
 ]
 
 * [*Question:]    Why does `lexical_cast<unsigned char>("127")` throw `bad_lexical_cast`?
-  * [*Answer:]      Lexical conversion to any char type is simply reading a byte from source. But since the source has more than one byte, the exception is thrown. 
-Please use other integer types such as `int` or `short int`. If bounds checking is important, you can also 
-call __numericcast__: 
+  * [*Answer:]      Lexical conversion to any char type is simply reading a byte from source. But since the source has more than one byte, the exception is thrown.
+Please use other integer types such as `int` or `short int`. If bounds checking is important, you can also
+call __numericcast__:
 `numeric_cast<unsigned char>(lexical_cast<int>("127"));`
 
 [pre
 ]
 
 * [*Question:]    What does `lexical_cast<std::string>` of an `int8_t` or `uint8_t` not do what I expect?
-  * [*Answer:]      As above, note that int8_t and uint8_t are actually chars and are formatted as such. To avoid 
+  * [*Answer:]      As above, note that int8_t and uint8_t are actually chars and are formatted as such. To avoid
 this, cast to an integer type first: `lexical_cast<std::string>(static_cast<int>(n));`
 
 [pre
 ]
 
-* [*Question:]    The implementation always resets the `ios_base::skipws` flag of an underlying stream object. 
+* [*Question:]    The implementation always resets the `ios_base::skipws` flag of an underlying stream object.
 It breaks my `operator>>` that works only in presence of this flag. Can you remove code that resets the flag?
-  * [*Answer:]      May be in a future version. There is no requirement in 
-__proposallong__ to reset the flag but 
-remember that __proposalshort__ is not yet accepted by the committee. By the way, it's a great opportunity to 
+  * [*Answer:]      May be in a future version. There is no requirement in
+__proposallong__ to reset the flag but
+remember that __proposalshort__ is not yet accepted by the committee. By the way, it's a great opportunity to
 make your `operator>>` conform to the standard.
 Read a good C++ book, study `std::sentry` and [@boost:libs/io/doc/ios_state.html `ios_state_saver`].
 
@@ -218,17 +218,17 @@ Read a good C++ book, study `std::sentry` and [@boost:libs/io/doc/ios_state.html
 ]
 
 * [*Question:]    Why `std::cout << boost::lexical_cast<unsigned int>("-1");` does not throw, but outputs 4294967295?
-  * [*Answer:]      `boost::lexical_cast` has the behavior of `std::stringstream`, which uses `num_get` functions of 
-`std::locale` to convert numbers. If we look at the Programming languages — C++, we'll see, that `num_get` uses 
-the rules of `scanf` for conversions. And in the C99 standard for unsigned input value minus sign is optional, so 
+  * [*Answer:]      `boost::lexical_cast` has the behavior of `std::stringstream`, which uses `num_get` functions of
+`std::locale` to convert numbers. If we look at the Programming languages — C++, we'll see, that `num_get` uses
+the rules of `scanf` for conversions. And in the C99 standard for unsigned input value minus sign is optional, so
 if a negative number is read, no errors will arise and the result will be the two's complement.
 
 [pre
 ]
 
 * [*Question:]    Why `boost::lexical_cast<int>(L'A');` outputs 65 and `boost::lexical_cast<wchar_t>(L"65");` does not throw?
-  * [*Answer:]      If you are using an old version of Visual Studio or compile code with /Zc:wchar_t- flag, 
-`boost::lexical_cast` sees single `wchar_t` character as `unsigned short`. It is not a `boost::lexical_cast` mistake, but a 
+  * [*Answer:]      If you are using an old version of Visual Studio or compile code with /Zc:wchar_t- flag,
+`boost::lexical_cast` sees single `wchar_t` character as `unsigned short`. It is not a `boost::lexical_cast` mistake, but a
 limitation of compiler options that you use.
 
 [pre
@@ -236,7 +236,7 @@ limitation of compiler options that you use.
 
 * [*Question:]    Why `boost::lexical_cast<double>("-1.#IND");` throws `boost::bad_lexical_cast`?
   * [*Answer:]      `"-1.#IND"` is a compiler extension, that violates standard. You shall input `"-nan"`, `"nan"`, `"inf"`
-, `"-inf"` (case insensitive) strings to get NaN and Inf values. `boost::lexical_cast<string>` outputs `"-nan"`, `"nan"`, 
+, `"-inf"` (case insensitive) strings to get NaN and Inf values. `boost::lexical_cast<string>` outputs `"-nan"`, `"nan"`,
 `"inf"`, `"-inf"` strings, when has NaN or Inf input values.
 
 * [*Question:]    What is the fastest way to convert a non zero terminated string or a substring using `boost::lexical_cast`?
@@ -246,21 +246,21 @@ limitation of compiler options that you use.
 
 [section Changes]
 * [*boost 1.50.0 :]
-  
+
     * `boost::bad_lexical_cast` exception is now globaly visible and can be catched even if code is compiled with -fvisibility=hidden.
     * Now it is possible to compile library with disabled exceptions.
     * Better performance, less memory usage and bugfixes for `boost::iterator_range<character_type*>` conversions.
 
 * [*boost 1.49.0 :]
-  
-    * Restored work with typedefed wchar_t (compilation flag /Zc:wchar_t- for Visual Studio). 
+
+    * Restored work with typedefed wchar_t (compilation flag /Zc:wchar_t- for Visual Studio).
     * Better performance and less memory usage for `boost::container::basic_string` conversions.
-    
+
 * [*boost 1.48.0 :]
-  
-    * Added code to work with Inf and NaN on any platform.    
+
+    * Added code to work with Inf and NaN on any platform.
     * Better performance and less memory usage for conversions to float type (and to double type, if `sizeof(double) < sizeof(long double)`).
-  
+
 * [*boost 1.47.0 :]
 
     * Optimizations for "C" and other locales without number grouping.
@@ -283,7 +283,7 @@ limitation of compiler options that you use.
     * The previous version of lexical_cast used the default stream precision for reading and writing floating-point numbers. For numerics that have a corresponding specialization of `std::numeric_limits`, the current version now chooses a precision to match.
     * The previous version of lexical_cast did not support conversion to or from any wide-character-based types. For compilers with full language and library support for wide characters, `lexical_cast` now supports conversions from `wchar_t`, `wchar_t *`, and `std::wstring` and to `wchar_t` and `std::wstring`.
     * The previous version of `lexical_cast` assumed that the conventional stream extractor operators were sufficient for reading values. However, string I/O is asymmetric, with the result that spaces play the role of I/O separators rather than string content. The current version fixes this error for `std::string` and, where supported, `std::wstring`: `lexical_cast<std::string>("Hello, World")` succeeds instead of failing with a `bad_lexical_cast` exception.
-    * The previous version of `lexical_cast` allowed unsafe and meaningless conversions to pointers. The current version now throws a `bad_lexical_cast` for conversions to pointers: `lexical_cast<char *>("Goodbye, World")` now throws an exception instead of causing undefined behavior. 
+    * The previous version of `lexical_cast` allowed unsafe and meaningless conversions to pointers. The current version now throws a `bad_lexical_cast` for conversions to pointers: `lexical_cast<char *>("Goodbye, World")` now throws an exception instead of causing undefined behavior.
 
 [endsect]
 
@@ -328,7 +328,7 @@ All the tests measure execution speed in milliseconds for 10000 iterations of th
   ``]
   ]
 ]
-Fastest results are highlitened with "!!! *x* !!!". 
+Fastest results are highlitened with "!!! *x* !!!".
 Do not use this results to compare compilers, because tests were taken on different hardware.
 
 [endsect]