introduction.qbk 7.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163
  1. [/
  2. Copyright 2006-2007 John Maddock.
  3. Distributed under the Boost Software License, Version 1.0.
  4. (See accompanying file LICENSE_1_0.txt or copy at
  5. http://www.boost.org/LICENSE_1_0.txt).
  6. ]
  7. [section:intro Introduction and Overview]
  8. Regular expressions are a form of pattern-matching that are often used in
  9. text processing; many users will be familiar with the Unix utilities grep, sed
  10. and awk, and the programming language Perl, each of which make extensive use
  11. of regular expressions. Traditionally C++ users have been limited to the
  12. POSIX C API's for manipulating regular expressions, and while Boost.Regex does
  13. provide these API's, they do not represent the best way to use the library.
  14. For example Boost.Regex can cope with wide character strings, or search and
  15. replace operations (in a manner analogous to either sed or Perl), something
  16. that traditional C libraries can not do.
  17. The class [basic_regex] is the key class in this library; it represents a
  18. "machine readable" regular expression, and is very closely modeled on
  19. `std::basic_string`, think of it as a string plus the actual state-machine
  20. required by the regular expression algorithms. Like `std::basic_string` there
  21. are two typedefs that are almost always the means by which this class is referenced:
  22. namespace boost{
  23. template <class charT,
  24. class traits = regex_traits<charT> >
  25. class basic_regex;
  26. typedef basic_regex<char> regex;
  27. typedef basic_regex<wchar_t> wregex;
  28. }
  29. To see how this library can be used, imagine that we are writing a credit
  30. card processing application. Credit card numbers generally come as a string
  31. of 16-digits, separated into groups of 4-digits, and separated by either a
  32. space or a hyphen. Before storing a credit card number in a database
  33. (not necessarily something your customers will appreciate!), we may want to
  34. verify that the number is in the correct format. To match any digit we could
  35. use the regular expression \[0-9\], however ranges of characters like this are
  36. actually locale dependent. Instead we should use the POSIX standard
  37. form \[\[:digit:\]\], or the Boost.Regex and Perl shorthand for this \\d (note
  38. that many older libraries tended to be hard-coded to the C-locale,
  39. consequently this was not an issue for them). That leaves us with the
  40. following regular expression to validate credit card number formats:
  41. [pre (\d{4}\[- \]){3}\d{4}]
  42. Here the parenthesis act to group (and mark for future reference)
  43. sub-expressions, and the {4} means "repeat exactly 4 times". This is an
  44. example of the extended regular expression syntax used by Perl, awk and egrep.
  45. Boost.Regex also supports the older "basic" syntax used by sed and grep,
  46. but this is generally less useful, unless you already have some basic regular
  47. expressions that you need to reuse.
  48. Now let's take that expression and place it in some C++ code to validate the
  49. format of a credit card number:
  50. bool validate_card_format(const std::string& s)
  51. {
  52. static const boost::regex e("(\\d{4}[- ]){3}\\d{4}");
  53. return regex_match(s, e);
  54. }
  55. Note how we had to add some extra escapes to the expression: remember that
  56. the escape is seen once by the C++ compiler, before it gets to be seen by
  57. the regular expression engine, consequently escapes in regular expressions
  58. have to be doubled up when embedding them in C/C++ code. Also note that
  59. all the examples assume that your compiler supports argument-dependent
  60. lookup, if yours doesn't (for example VC6), then you will have to add some
  61. `boost::` prefixes to some of the function calls in the examples.
  62. Those of you who are familiar with credit card processing, will have realized
  63. that while the format used above is suitable for human readable card numbers,
  64. it does not represent the format required by online credit card systems; these
  65. require the number as a string of 16 (or possibly 15) digits, without any
  66. intervening spaces. What we need is a means to convert easily between the two
  67. formats, and this is where search and replace comes in. Those who are familiar
  68. with the utilities sed and Perl will already be ahead here; we need two
  69. strings - one a regular expression - the other a "format string" that provides
  70. a description of the text to replace the match with. In Boost.Regex this
  71. search and replace operation is performed with the algorithm [regex_replace],
  72. for our credit card example we can write two algorithms like this to
  73. provide the format conversions:
  74. // match any format with the regular expression:
  75. const boost::regex e("\\A(\\d{3,4})[- ]?(\\d{4})[- ]?(\\d{4})[- ]?(\\d{4})\\z");
  76. const std::string machine_format("\\1\\2\\3\\4");
  77. const std::string human_format("\\1-\\2-\\3-\\4");
  78. std::string machine_readable_card_number(const std::string s)
  79. {
  80. return regex_replace(s, e, machine_format, boost::match_default | boost::format_sed);
  81. }
  82. std::string human_readable_card_number(const std::string s)
  83. {
  84. return regex_replace(s, e, human_format, boost::match_default | boost::format_sed);
  85. }
  86. Here we've used marked sub-expressions in the regular expression to split out
  87. the four parts of the card number as separate fields, the format string then
  88. uses the sed-like syntax to replace the matched text with the reformatted version.
  89. In the examples above, we haven't directly manipulated the results of
  90. a regular expression match, however in general the result of a match contains
  91. a number of sub-expression matches in addition to the overall match. When the
  92. library needs to report a regular expression match it does so using an instance
  93. of the class [match_results], as before there are typedefs of this class for
  94. the most common cases:
  95. namespace boost{
  96. typedef match_results<const char*> cmatch;
  97. typedef match_results<const wchar_t*> wcmatch;
  98. typedef match_results<std::string::const_iterator> smatch;
  99. typedef match_results<std::wstring::const_iterator> wsmatch;
  100. }
  101. The algorithms [regex_search] and [regex_match] make use of [match_results]
  102. to report what matched; the difference between these algorithms is that
  103. [regex_match] will only find matches that consume /all/ of the input text,
  104. where as [regex_search] will search for a match anywhere within the text being matched.
  105. Note that these algorithms are not restricted to searching regular C-strings,
  106. any bidirectional iterator type can be searched, allowing for the
  107. possibility of seamlessly searching almost any kind of data.
  108. For search and replace operations, in addition to the algorithm [regex_replace]
  109. that we have already seen, the [match_results] class has a `format` member that
  110. takes the result of a match and a format string, and produces a new string
  111. by merging the two.
  112. For iterating through all occurrences of an expression within a text,
  113. there are two iterator types: [regex_iterator] will enumerate over the
  114. [match_results] objects found, while [regex_token_iterator] will enumerate
  115. a series of strings (similar to perl style split operations).
  116. For those that dislike templates, there is a high level wrapper class
  117. [RegEx] that is an encapsulation of the lower level template code - it
  118. provides a simplified interface for those that don't need the full
  119. power of the library, and supports only narrow characters, and the
  120. "extended" regular expression syntax. This class is now deprecated as
  121. it does not form part of the regular expressions C++ standard library proposal.
  122. The POSIX API functions: [regcomp], [regexec], [regfree] and [regerr],
  123. are available in both narrow character and Unicode versions, and are
  124. provided for those who need compatibility with these API's.
  125. Finally, note that the library now has
  126. [link boost_regex.background.locale run-time localization support],
  127. and recognizes the full POSIX regular expression syntax - including
  128. advanced features like multi-character collating elements and equivalence
  129. classes - as well as providing compatibility with other regular expression
  130. libraries including GNU and BSD4 regex packages, PCRE and Perl 5.
  131. [endsect]