I have a problem with the Effects clause of regex_traits::transform,
which says:

Effects:
string_type str(first, last);
return use_face<collate<charT> >(getloc()).transform(&*str.begin(),
&*str.end());

Already the &*str.end() is fishy, but perhaps allowed.

However, does this not also require that string_type, being a
basic_string specialization, has a contiguous buffer?



Is the code not to be taken literally, or what?


Bo Persson


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Bo Persson wrote:
> I have a problem with the Effects clause of regex_traits::transform,
> which says:
>=20
> Effects:
> string_type str(first, last);
> return use_face<collate<charT> >(getloc()).transform(&*str.begin(),
> &*str.end());
>=20
> Already the &*str.end() is fishy, but perhaps allowed.

I don't think it's allowed. In 24.1/5 it is said that "The library never=20
assumes that past-the-end values are dereferenceable" so you cannot=20
safely assume that *str.end() is defined.

>=20
> However, does this not also require that string_type, being a
> basic_string specialization, has a contiguous buffer?
>=20
 > Is the code not to be taken literally, or what?

Maybe the requirement could be better stated in terms of data() and=20
size(), such as:

Effects:
   string_type str(first, last);
   const char* data =3D str.data();
   return use_face<collate<charT> >(getloc()).transform(data, data +=20
str.size());

The pointer returned by str.data() is guaranteed to point to a=20
contiguous buffer of at least str.size() bytes.

Just my =800.02

Alberto

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Bo Persson wrote:
>
> Already the &*str.end() is fishy, but perhaps allowed.
>

It's allowed, and meaningful. Unfortunately, its meaning isn't what's
needed here.

> However, does this not also require that string_type, being a
> basic_string specialization, has a contiguous buffer?
>
> Is the code not to be taken literally, or what?
>

Well, yes, but it's wrong. Or maybe not. <g> You're right: it assumes a
contiguous array. That's what a collate facet's transform function
requires. transform(first, last) calls do_transform(first, last), and
the standard says that the latter returns "A basic_string<charT> value
that, compared lexicographically with the result of calling transform()
on another string, yields the same result as calling do_compare() on the
same two strings." It's a bit sloppy in its use of the word "string",
but it seems to be making the same assumption. Of course, do_transform
is virtual, so it can't be a template member funtion, which is why it
got the interface that it has. Sloppy all around. (I confess: I wrote
the description of regex_traits::transform.)

I've submitted a defect report. Thanks!

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]