From: Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>
To: libstdc++@gcc.gnu.org
Subject: string::iterator should have more error checking
Date: Thu, 23 Jun 2022 22:05:22 +0100 [thread overview]
Message-ID: <CALtZhhNKysaytQeW_nwbZa2-Sft9CV0dsBhHQAa96EPb+uRthw@mail.gmail.com> (raw)
If a program is compiled with "-D_GLIBCXX_DEBUG", I would expect it at
runtime to catch the error on the last line in the following program:
#include <iostream>
#include <string>
#include <string_view>
#include <type_traits>
using namespace std;
int main(void)
{
cout << "string::const_iterator is "
<< (is_same_v< string::const_iterator, char const * > ? "just
a raw pointer" : "NOT a simple pointer") << endl;
cout << "string_view::const_iterator is "
<< (is_same_v< string_view::const_iterator, char const * > ?
"just a raw pointer" : "NOT a simple pointer") << endl;
string s("brush");
cout << string_view( &*(s.cbegin() + 1u), &*(s.cend() + 876u) ) << endl;
}
string::iterator is NOT a simple pointer -- it is a class and so we
can overload the following operators to catch errors:
(1) unary operator*
(2) binary operator+
(3) binary operator-
The error on the last line of the above program would be caught at
runtime if the iterator were written as follows:
class string {
class iterator {
char const *const p_min, *const p_max; // initialised in constructor
char *p;
public:
iterator &operator+(ptrdiff_t const n)
{
assert( p+n >= p_min );
assert( p+n <= p_max );
// more code here
}
};
};
Similarly the unary operator* could be overloaded to catch the error
when "end()" gets dereferenced.
next reply other threads:[~2022-06-23 21:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-23 21:05 Frederick Virchanza Gotham [this message]
2022-06-23 21:26 ` Jonathan Wakely
2022-06-23 22:01 ` Frederick Virchanza Gotham
2022-06-23 22:35 ` Jonathan Wakely
2022-06-24 9:06 ` Frederick Virchanza Gotham
2022-06-24 9:35 ` Jonathan Wakely
2022-06-24 10:10 ` Frederick Virchanza Gotham
2022-06-24 10:28 ` Jonathan Wakely
2022-06-24 11:14 ` Frederick Virchanza Gotham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALtZhhNKysaytQeW_nwbZa2-Sft9CV0dsBhHQAa96EPb+uRthw@mail.gmail.com \
--to=cauldwell.thomas@gmail.com \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).