Topic: Defect report [N2134]: Missing members in match_results
Author: "=?iso-8859-1?q?Daniel_Kr=FCgler?=" <daniel.kruegler@googlemail.com>
Date: Mon, 26 Feb 2007 12:51:00 CST Raw View
According to the description given in 28.10/2 the class template
match_results "shall satisfy the requirements of a Sequence, [..],
except that only operations defined for const-qualified Sequences
are supported".
Comparing the provided operations from 28.10/3 with the sequence
/container tables 80 and 81 one recognizes the following
missing operations:
1) The members
const_iterator rbegin() const;
const_iterator rend() const;
should exists because 23.1/10 demands these for containers
(all sequences are containers) which support bidirectional
iterators. Aren't these supported by match_result? This is not
explicitely expressed, but it's somewhat implied by two arguments:
(a) Several typedefs delegate to
iterator_traits<BidirectionalIterator>.
(b) The existence of const_reference operator[](size_type n) const
implies even random-access iteration.
I also suggest, that match_result should explicitly mention,
which minimum iterator category is supported and if this does
not include random-access the existence of operator[] is
somewhat questionable.
Furtheron it seems somewhat deliberate to provide operator[]
but not the at()/front()/back() members which all four belong
to the optional sequence operations of table 83.
2) The new "convenience" members
const_iterator cbegin() const;
const_iterator cend() const;
const_iterator crbegin() const;
const_iterator crend() const;
should be added according to tables 80/81.
Greetings from Bremen,
Daniel Kr gler
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Author: "=?iso-8859-1?q?Daniel_Kr=FCgler?=" <daniel.kruegler@googlemail.com>
Date: Mon, 26 Feb 2007 13:22:54 CST Raw View
> Furtheron it seems somewhat deliberate to provide operator[]
> but not the at()/front()/back() members which all four belong
> to the optional sequence operations of table 83.
Sorry for this one: I see now that at() is really not needed.
Daniel
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]