File: faq.html

package info (click to toggle)
boost 1.32.0-6
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 93,952 kB
  • ctags: 128,458
  • sloc: cpp: 492,477; xml: 52,125; python: 13,519; ansic: 13,013; sh: 1,773; yacc: 853; makefile: 526; perl: 418; lex: 110; csh: 6
file content (114 lines) | stat: -rw-r--r-- 6,886 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
   <head>
      <title>Boost.Regex: FAQ</title>
      <meta name="generator" content="HTML Tidy, see www.w3.org">
      <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
      <link rel="stylesheet" type="text/css" href="../../../boost.css">
   </head>
   <body>
      <p></p>
      <table id="Table1" cellspacing="1" cellpadding="1" width="100%" border="0">
         <tr>
            <td valign="top" width="300">
               <h3><a href="../../../index.htm"><img height="86" width="277" alt="C++ Boost" src="../../../boost.png" border="0"></a></h3>
            </td>
            <td width="353">
               <h1 align="center">Boost.Regex</h1>
               <h2 align="center">FAQ</h2>
            </td>
            <td width="50">
               <h3><a href="index.html"><img height="45" width="43" alt="Boost.Regex Index" src="uarrow.gif" border="0"></a></h3>
            </td>
         </tr>
      </table>
      <br>
      <br>
      <hr>
      <font color="#ff0000"><font color="#ff0000"></font></font>
      <p><font color="#ff0000"><font color="#ff0000"><font color="#ff0000">&nbsp;Q. Why can't I 
                  use the "convenience" versions of regex_match / regex_search / regex_grep / 
                  regex_format / regex_merge?</font></font></font></p>
      <p>A. These versions may or may not be available depending upon the capabilities 
         of your compiler, the rules determining the format of these functions are quite 
         complex - and only the versions visible to a standard compliant compiler are 
         given in the help. To find out what your compiler supports, run 
         &lt;boost/regex.hpp&gt; through your C++ pre-processor, and search the output 
         file for the function that you are interested in.<font color="#ff0000"><font color="#ff0000"></font></font></p>
      <p><font color="#ff0000"><font color="#ff0000">Q. I can't get regex++ to work with 
               escape characters, what's going on?</font></font></p>
      <p>A. If you embed regular expressions in C++ code, then remember that escape 
         characters are processed twice: once by the C++ compiler, and once by the 
         regex++ expression compiler, so to pass the regular expression \d+ to regex++, 
         you need to embed "\\d+" in your code. Likewise to match a literal backslash 
         you will need to embed "\\\\" in your code. <font color="#ff0000"></font>
      </p>
      <p><font color="#ff0000">Q. Why does using parenthesis in a POSIX regular expression 
            change the result of a match?</font></p>
      <p>For POSIX (extended and basic) regular expressions, but not for perl regexes, 
         parentheses don't only mark; they determine what the best match is as well. 
         When the expression is compiled as a POSIX basic or extended regex then 
         Boost.regex follows the POSIX standard leftmost longest rule for determining 
         what matched. So if there is more than one possible match after considering the 
         whole expression, it looks next at the first sub-expression and then the second 
         sub-expression and so on. So...</p>
      <pre>
"(0*)([0-9]*)" against "00123" would produce
$1 = "00"
$2 = "123"
</pre>
      <p>where as</p>
      <pre>
"0*([0-9])*" against "00123" would produce
$1 = "00123"
</pre>
      <p>If you think about it, had $1 only matched the "123", this would be "less good" 
         than the match "00123" which is both further to the left and longer. If you 
         want $1 to match only the "123" part, then you need to use something like:</p>
      <pre>
"0*([1-9][0-9]*)"
</pre>
      <p>as the expression.</p>
      <p><font color="#ff0000">Q. Why don't character ranges work properly (POSIX mode 
            only)?</font><br>
         A. The POSIX standard specifies that character range expressions are locale 
         sensitive - so for example the expression [A-Z] will match any collating 
         element that collates between 'A' and 'Z'. That means that for most locales 
         other than "C" or "POSIX", [A-Z] would match the single character 't' for 
         example, which is not what most people expect - or at least not what most 
         people have come to expect from regular expression engines. For this reason, 
         the default behaviour of boost.regex (perl mode) is to turn locale sensitive 
         collation off by not setting the regex_constants::collate compile time flag. 
         However if you set a non-default compile time flag - for example 
         regex_constants::extended or regex_constants::basic, then locale dependent 
         collation will be enabled, this also applies to the POSIX API functions which 
         use either regex_constants::extended or regex_constants::basic internally. <i>[Note 
            - when regex_constants::nocollate in effect, the library behaves "as if" the 
            LC_COLLATE locale category were always "C", regardless of what its actually set 
            to - end note</i>].</p>
      <p><font color="#ff0000">Q. Why are there no throw specifications on any of the 
            functions? What exceptions can the library throw?</font></p>
      <p>A. Not all compilers support (or honor) throw specifications, others support 
         them but with reduced efficiency. Throw specifications may be added at a later 
         date as compilers begin to handle this better. The library should throw only 
         three types of exception: boost::bad_expression can be thrown by basic_regex 
         when compiling a regular expression, std::runtime_error can be thrown when a 
         call to basic_regex::imbue tries to open a message catalogue that doesn't 
         exist, or when a call to regex_search or regex_match results in an 
         "everlasting" search,&nbsp;or when a call to RegEx::GrepFiles or 
         RegEx::FindFiles tries to open a file that cannot be opened, finally 
         std::bad_alloc can be thrown by just about any of the functions in this 
         library.</p>
      <p></p>
      <hr>
      <p>Revised 
         <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan --> 
         24 Oct 2003 
         <!--webbot bot="Timestamp" endspan i-checksum="39359" --></p>
      <p><i> Copyright John Maddock&nbsp;1998- 
            <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y" startspan -->  2003<!--webbot bot="Timestamp" endspan i-checksum="39359" --></i></p>
      <P><I>Use, modification and distribution are subject to the Boost Software License, 
            Version 1.0. (See accompanying file <A href="../../../LICENSE_1_0.txt">LICENSE_1_0.txt</A>
            or copy at <A href="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</A>)</I></P>
   </body>
</html>