forked from boostorg/algorithm
77 lines
4.3 KiB
XML
77 lines
4.3 KiB
XML
|
<?xml version="1.0" encoding="utf-8"?>
|
||
|
|
<!DOCTYPE library PUBLIC "-//Boost//DTD BoostBook XML V1.0//EN"
|
||
|
|
"http://www.boost.org/tools/boostbook/dtd/boostbook.dtd">
|
||
|
|
<section id="string_algo.rationale" last-revision="$Date$">
|
||
|
|
<title>Rationale</title>
|
||
|
|
|
||
|
|
<using-namespace name="boost"/>
|
||
|
|
<using-namespace name="boost::string_algo"/>
|
||
|
|
|
||
|
|
<section id="string_algo.structure">
|
||
|
|
<title>Library structure</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
When designing a library it is always a problem to find a balance between generalization
|
||
|
|
and usability. A generic utility can have a wider range of usage with more options for extensibility,
|
||
|
|
but it can also bring unwanted complexity for everyday usage.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
Imagine a library for drawing geometric objects. It can contain one generic function <code>draw()</code>
|
||
|
|
with many parameters specifying what to draw, like size, number of edges, shape etc.
|
||
|
|
This would allow you to draw almost anything, but usually a user only needs to draw
|
||
|
|
only a triangle or a square and she will have to specify this simple request in a
|
||
|
|
very complicated way.For this purpose two functions, <code>draw_triangle()</code> and
|
||
|
|
<code>draw_square()</code>, would suit much better then a generic <code>draw()</code> function.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
The String Algorithm Library solves this problem by dividing the interface into two layers.
|
||
|
|
The first layer (defined in the namespace boost) contains ready to use algorithms specialized
|
||
|
|
for common tasks. They are provided in multiple variants to better suit specific needs.
|
||
|
|
The second layer (defined in the namespace <code>boost::string_algo</code>), provides generic interfaces with
|
||
|
|
more options for extending and tunning.
|
||
|
|
<para>
|
||
|
|
</para>
|
||
|
|
For instance, a <functionname>boost::trim()</functionname> algorithm trims spaces from
|
||
|
|
an input string. When there is a need to trim something else, there is
|
||
|
|
<functionname>boost::string_algo::trim()</functionname> which interface allows one to specify a
|
||
|
|
predicate which selects the characters to be removed.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
<section it="string_algo.locale">
|
||
|
|
<title>Locales</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Locales have a very close relation to string processing. They contain information about
|
||
|
|
the character sets and are used, for example, to change the case of characters and
|
||
|
|
to classify the characters.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
C++ allows to work with multiple different instances of locales at once. If an algorithm
|
||
|
|
manipulates some data in a way that requires the usage of locales, there must be a way
|
||
|
|
to specify them. However, one instance of locales is sufficient for most of the applications,
|
||
|
|
and for a user it could be very tedious to specify which locales to use on every place
|
||
|
|
where it is needed.
|
||
|
|
</para>
|
||
|
|
<para>
|
||
|
|
Fortunately, the C++ standard allows to specify the <emphasis>global</emphasis> locales (using static member
|
||
|
|
function <code>std:locale::global()</code>). When instantiating an
|
||
|
|
<code>std::locale</code> class without explicit information, the instance will
|
||
|
|
be initialized with the <emphasis>global</emphasis> locale. It means, that if an algorithm needs a locale,
|
||
|
|
it should have an <code>std::locale</code> parameter with default value <code>std::locale()</code>.
|
||
|
|
If a user needs to specify locales explicitly, she can do so. Otherwise the <emphasis>global</emphasis>
|
||
|
|
locales are used.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
<section id="string_algo.regex">
|
||
|
|
<title>Regular Expressions</title>
|
||
|
|
|
||
|
|
<para>
|
||
|
|
Regular expressions are an essential part of text processing. For this reason, the library
|
||
|
|
provides also regex variants of some algorithms. The library does not try to replace
|
||
|
|
<libraryname>Boost.Regex</libraryname>, but it merely wraps its functionality in a new interface.
|
||
|
|
As a part of this library regex algorithms integrate smoothly with other components which
|
||
|
|
brings additional value.
|
||
|
|
</para>
|
||
|
|
</section>
|
||
|
|
</section>
|