mirror of
https://github.com/boostorg/regex.git
synced 2025-07-23 17:17:22 +02:00
Added missing preconditions, and fixed minor typos.
[SVN r22529]
This commit is contained in:
John Maddock
@ -76,7 +76,7 @@ typedef regex_token_iterator<const char*> cregex_token_i
|
||||
typedef regex_token_iterator<std::string::const_iterator> sregex_token_iterator;
|
||||
#ifndef BOOST_NO_WREGEX
|
||||
typedef regex_token_iterator<const wchar_t*> wcregex_token_iterator;
|
||||
typedef regex_token_iterator<<std::wstring::const_iterator> wsregex_token_iterator;
|
||||
typedef regex_token_iterator<<std::wstring::const_iterator> wsregex_token_iterator;
|
||||
#endif
|
||||
</PRE>
|
||||
<H3><A name="description"></A>Description</H3>
|
||||
@ -84,7 +84,8 @@ typedef regex_token_iterator<<std::wstring::const_iterator> wsregex_token_
|
||||
<P><B> Effects:</B> constructs an end of sequence iterator.</P>
|
||||
<PRE><A name=c2></A>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, const regex_type& re,
|
||||
int submatch = 0, match_flag_type m = match_default);</PRE>
|
||||
<P><B> Preconditions: </B><CODE>!re.empty()</CODE>.</P>
|
||||
<P><B> Preconditions: </B><CODE>!re.empty()</CODE>. Object re shall exist
|
||||
for the lifetime of the iterator constructed from it.</P>
|
||||
<P><B> Effects:</B> constructs a regex_token_iterator that will enumerate one
|
||||
string for each regular expression match of the expression <EM>re</EM> found
|
||||
within the sequence <EM>[a,b)</EM>, using match flags <EM>m</EM>. The
|
||||
@ -99,7 +100,8 @@ typedef regex_token_iterator<<std::wstring::const_iterator> wsregex_token_
|
||||
configured</A> in non-recursive mode).</P>
|
||||
<PRE><A name=c3></A>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, const regex_type& re,
|
||||
const std::vector<int>& submatches, match_flag_type m = match_default);</PRE>
|
||||
<P><B> Preconditions:</B> <CODE>submatches.size() && !re.empty()</CODE>.</P>
|
||||
<P><B> Preconditions:</B> <CODE>submatches.size() && !re.empty()</CODE>.
|
||||
Object re shall exist for the lifetime of the iterator constructed from it.</P>
|
||||
<P><B> Effects:</B> constructs a regex_token_iterator that will enumerate <EM>submatches.size()</EM>
|
||||
strings for each regular expression match of the expression <EM>re</EM> found
|
||||
within the sequence <EM>[a,b)</EM>, using match flags <EM>m</EM>. For
|
||||
@ -118,7 +120,8 @@ typedef regex_token_iterator<<std::wstring::const_iterator> wsregex_token_
|
||||
<PRE><A name=c4></A>template <std::size_t N>
|
||||
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, const regex_type& re,
|
||||
const int (&submatches)[R], match_flag_type m = match_default);</PRE>
|
||||
<P><B> Preconditions: </B><CODE>!re.empty()</CODE>.</P>
|
||||
<P><B> Preconditions: </B><CODE>!re.empty()</CODE>. Object re shall exist
|
||||
for the lifetime of the iterator constructed from it.</P>
|
||||
<P><STRONG>Effects:</STRONG></B> constructs a regex_token_iterator that will
|
||||
enumerate <EM>R</EM> strings for each regular expression match of the
|
||||
expression <EM>re</EM> found within the sequence <EM>[a,b)</EM>, using match
|
||||
|
||||
@ -91,18 +91,18 @@
|
||||
<P>Parentheses serve two purposes, to group items together into a sub-expression,
|
||||
and to mark what generated the match. For example the expression "(ab)*" would
|
||||
match all of the string "ababab". The matching algorithms <A href="regex_match.html">
|
||||
regex_match</A> and <A href="regex_search.html">regex_search</A>
|
||||
each take an instance of <A href="match_results.html">match_results</A>
|
||||
that reports what caused the match, on exit from these functions the <A href="match_results.html">
|
||||
match_results</A> contains information both on what the whole expression
|
||||
matched and on what each sub-expression matched. In the example above
|
||||
match_results[1] would contain a pair of iterators denoting the final "ab" of
|
||||
the matching string. It is permissible for sub-expressions to match null
|
||||
strings. If a sub-expression takes no part in a match - for example if it is
|
||||
part of an alternative that is not taken - then both of the iterators that are
|
||||
returned for that sub-expression point to the end of the input string, and the <I>matched</I>
|
||||
parameter for that sub-expression is <I>false</I>. Sub-expressions are indexed
|
||||
from left to right starting from 1, sub-expression 0 is the whole expression.
|
||||
regex_match</A> and <A href="regex_search.html">regex_search</A> each take
|
||||
an instance of <A href="match_results.html">match_results</A> that reports what
|
||||
caused the match, on exit from these functions the <A href="match_results.html">match_results</A>
|
||||
contains information both on what the whole expression matched and on what each
|
||||
sub-expression matched. In the example above match_results[1] would contain a
|
||||
pair of iterators denoting the final "ab" of the matching string. It is
|
||||
permissible for sub-expressions to match null strings. If a sub-expression
|
||||
takes no part in a match - for example if it is part of an alternative that is
|
||||
not taken - then both of the iterators that are returned for that
|
||||
sub-expression point to the end of the input string, and the <I>matched</I> parameter
|
||||
for that sub-expression is <I>false</I>. Sub-expressions are indexed from left
|
||||
to right starting from 1, sub-expression 0 is the whole expression.
|
||||
</P>
|
||||
<H3>Non-Marking Parenthesis
|
||||
</H3>
|
||||
@ -143,7 +143,7 @@
|
||||
<P>A set is a set of characters that can match any single character that is a
|
||||
member of the set. Sets are delimited by "[" and "]" and can contain literals,
|
||||
character ranges, character classes, collating elements and equivalence
|
||||
classes. Set declarations that start with "^" contain the compliment of the
|
||||
classes. Set declarations that start with "^" contain the complement of the
|
||||
elements that follow.
|
||||
</P>
|
||||
<P>Examples:
|
||||
@ -682,7 +682,8 @@
|
||||
chosen is the one with the longest first sub-expression, if that is the same
|
||||
for two or more matches, then the second sub-expression will be examined and so
|
||||
on.
|
||||
</P><P>
|
||||
</P>
|
||||
<P>
|
||||
The following table examples illustrate the main differences between Perl and
|
||||
POSIX regular expression matching rules:
|
||||
</P>
|
||||
@ -708,24 +709,23 @@
|
||||
<P><CODE>a|ab</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
xaby</CODE>
|
||||
<P><CODE> xaby</CODE>
|
||||
</P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
"ab"</CODE></P></TD>
|
||||
<P><CODE> "ab"</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
"a"</CODE></P></TD>
|
||||
<P><CODE> "a"</CODE></P>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
.*([[:alnum:]]+).*</CODE></P></TD>
|
||||
<P><CODE> .*([[:alnum:]]+).*</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
" abc def xyz "</CODE></P></TD>
|
||||
<P><CODE> " abc def xyz "</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P>$0 = " abc def xyz "<BR>
|
||||
$1 = "abc"</P>
|
||||
@ -737,14 +737,14 @@
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
.*(a|xayy)</CODE></P></TD>
|
||||
<P><CODE> .*(a|xayy)</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
zzxayyzz</CODE></P></TD>
|
||||
<P><CODE> zzxayyzz</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
"zzxayy"</CODE></P></TD>
|
||||
<P><CODE> "zzxayy"</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>"zzxa"</CODE></P>
|
||||
</TD>
|
||||
@ -753,19 +753,16 @@
|
||||
<P>These differences between Perl matching rules, and POSIX matching rules, mean
|
||||
that these two regular expression syntaxes differ not only in the features
|
||||
offered, but also in the form that the state machine takes and/or the
|
||||
algorithms used to traverse the state machine.</p>
|
||||
algorithms used to traverse the state machine.</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><EFBFBD> Copyright John Maddock 1998-
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y" startspan -->
|
||||
2003<!--webbot bot="Timestamp" endspan i-checksum="39359" --></i></p>
|
||||
<!--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>
|
||||
|
||||
|
||||
|
||||
@ -76,7 +76,7 @@ typedef regex_token_iterator<const char*> cregex_token_i
|
||||
typedef regex_token_iterator<std::string::const_iterator> sregex_token_iterator;
|
||||
#ifndef BOOST_NO_WREGEX
|
||||
typedef regex_token_iterator<const wchar_t*> wcregex_token_iterator;
|
||||
typedef regex_token_iterator<<std::wstring::const_iterator> wsregex_token_iterator;
|
||||
typedef regex_token_iterator<<std::wstring::const_iterator> wsregex_token_iterator;
|
||||
#endif
|
||||
</PRE>
|
||||
<H3><A name="description"></A>Description</H3>
|
||||
@ -84,7 +84,8 @@ typedef regex_token_iterator<<std::wstring::const_iterator> wsregex_token_
|
||||
<P><B> Effects:</B> constructs an end of sequence iterator.</P>
|
||||
<PRE><A name=c2></A>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, const regex_type& re,
|
||||
int submatch = 0, match_flag_type m = match_default);</PRE>
|
||||
<P><B> Preconditions: </B><CODE>!re.empty()</CODE>.</P>
|
||||
<P><B> Preconditions: </B><CODE>!re.empty()</CODE>. Object re shall exist
|
||||
for the lifetime of the iterator constructed from it.</P>
|
||||
<P><B> Effects:</B> constructs a regex_token_iterator that will enumerate one
|
||||
string for each regular expression match of the expression <EM>re</EM> found
|
||||
within the sequence <EM>[a,b)</EM>, using match flags <EM>m</EM>. The
|
||||
@ -99,7 +100,8 @@ typedef regex_token_iterator<<std::wstring::const_iterator> wsregex_token_
|
||||
configured</A> in non-recursive mode).</P>
|
||||
<PRE><A name=c3></A>regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, const regex_type& re,
|
||||
const std::vector<int>& submatches, match_flag_type m = match_default);</PRE>
|
||||
<P><B> Preconditions:</B> <CODE>submatches.size() && !re.empty()</CODE>.</P>
|
||||
<P><B> Preconditions:</B> <CODE>submatches.size() && !re.empty()</CODE>.
|
||||
Object re shall exist for the lifetime of the iterator constructed from it.</P>
|
||||
<P><B> Effects:</B> constructs a regex_token_iterator that will enumerate <EM>submatches.size()</EM>
|
||||
strings for each regular expression match of the expression <EM>re</EM> found
|
||||
within the sequence <EM>[a,b)</EM>, using match flags <EM>m</EM>. For
|
||||
@ -118,7 +120,8 @@ typedef regex_token_iterator<<std::wstring::const_iterator> wsregex_token_
|
||||
<PRE><A name=c4></A>template <std::size_t N>
|
||||
regex_token_iterator(BidirectionalIterator a, BidirectionalIterator b, const regex_type& re,
|
||||
const int (&submatches)[R], match_flag_type m = match_default);</PRE>
|
||||
<P><B> Preconditions: </B><CODE>!re.empty()</CODE>.</P>
|
||||
<P><B> Preconditions: </B><CODE>!re.empty()</CODE>. Object re shall exist
|
||||
for the lifetime of the iterator constructed from it.</P>
|
||||
<P><STRONG>Effects:</STRONG></B> constructs a regex_token_iterator that will
|
||||
enumerate <EM>R</EM> strings for each regular expression match of the
|
||||
expression <EM>re</EM> found within the sequence <EM>[a,b)</EM>, using match
|
||||
|
||||
@ -91,18 +91,18 @@
|
||||
<P>Parentheses serve two purposes, to group items together into a sub-expression,
|
||||
and to mark what generated the match. For example the expression "(ab)*" would
|
||||
match all of the string "ababab". The matching algorithms <A href="regex_match.html">
|
||||
regex_match</A> and <A href="regex_search.html">regex_search</A>
|
||||
each take an instance of <A href="match_results.html">match_results</A>
|
||||
that reports what caused the match, on exit from these functions the <A href="match_results.html">
|
||||
match_results</A> contains information both on what the whole expression
|
||||
matched and on what each sub-expression matched. In the example above
|
||||
match_results[1] would contain a pair of iterators denoting the final "ab" of
|
||||
the matching string. It is permissible for sub-expressions to match null
|
||||
strings. If a sub-expression takes no part in a match - for example if it is
|
||||
part of an alternative that is not taken - then both of the iterators that are
|
||||
returned for that sub-expression point to the end of the input string, and the <I>matched</I>
|
||||
parameter for that sub-expression is <I>false</I>. Sub-expressions are indexed
|
||||
from left to right starting from 1, sub-expression 0 is the whole expression.
|
||||
regex_match</A> and <A href="regex_search.html">regex_search</A> each take
|
||||
an instance of <A href="match_results.html">match_results</A> that reports what
|
||||
caused the match, on exit from these functions the <A href="match_results.html">match_results</A>
|
||||
contains information both on what the whole expression matched and on what each
|
||||
sub-expression matched. In the example above match_results[1] would contain a
|
||||
pair of iterators denoting the final "ab" of the matching string. It is
|
||||
permissible for sub-expressions to match null strings. If a sub-expression
|
||||
takes no part in a match - for example if it is part of an alternative that is
|
||||
not taken - then both of the iterators that are returned for that
|
||||
sub-expression point to the end of the input string, and the <I>matched</I> parameter
|
||||
for that sub-expression is <I>false</I>. Sub-expressions are indexed from left
|
||||
to right starting from 1, sub-expression 0 is the whole expression.
|
||||
</P>
|
||||
<H3>Non-Marking Parenthesis
|
||||
</H3>
|
||||
@ -143,7 +143,7 @@
|
||||
<P>A set is a set of characters that can match any single character that is a
|
||||
member of the set. Sets are delimited by "[" and "]" and can contain literals,
|
||||
character ranges, character classes, collating elements and equivalence
|
||||
classes. Set declarations that start with "^" contain the compliment of the
|
||||
classes. Set declarations that start with "^" contain the complement of the
|
||||
elements that follow.
|
||||
</P>
|
||||
<P>Examples:
|
||||
@ -682,7 +682,8 @@
|
||||
chosen is the one with the longest first sub-expression, if that is the same
|
||||
for two or more matches, then the second sub-expression will be examined and so
|
||||
on.
|
||||
</P><P>
|
||||
</P>
|
||||
<P>
|
||||
The following table examples illustrate the main differences between Perl and
|
||||
POSIX regular expression matching rules:
|
||||
</P>
|
||||
@ -708,24 +709,23 @@
|
||||
<P><CODE>a|ab</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
xaby</CODE>
|
||||
<P><CODE> xaby</CODE>
|
||||
</P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
"ab"</CODE></P></TD>
|
||||
<P><CODE> "ab"</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
"a"</CODE></P></TD>
|
||||
<P><CODE> "a"</CODE></P>
|
||||
</TD>
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
.*([[:alnum:]]+).*</CODE></P></TD>
|
||||
<P><CODE> .*([[:alnum:]]+).*</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
" abc def xyz "</CODE></P></TD>
|
||||
<P><CODE> " abc def xyz "</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P>$0 = " abc def xyz "<BR>
|
||||
$1 = "abc"</P>
|
||||
@ -737,14 +737,14 @@
|
||||
</TR>
|
||||
<TR>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
.*(a|xayy)</CODE></P></TD>
|
||||
<P><CODE> .*(a|xayy)</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
zzxayyzz</CODE></P></TD>
|
||||
<P><CODE> zzxayyzz</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>
|
||||
"zzxayy"</CODE></P></TD>
|
||||
<P><CODE> "zzxayy"</CODE></P>
|
||||
</TD>
|
||||
<TD vAlign="top" width="25%">
|
||||
<P><CODE>"zzxa"</CODE></P>
|
||||
</TD>
|
||||
@ -753,19 +753,16 @@
|
||||
<P>These differences between Perl matching rules, and POSIX matching rules, mean
|
||||
that these two regular expression syntaxes differ not only in the features
|
||||
offered, but also in the form that the state machine takes and/or the
|
||||
algorithms used to traverse the state machine.</p>
|
||||
algorithms used to traverse the state machine.</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><EFBFBD> Copyright John Maddock 1998-
|
||||
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y" startspan -->
|
||||
2003<!--webbot bot="Timestamp" endspan i-checksum="39359" --></i></p>
|
||||
<!--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>
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user