...

...

Can anyone tell why boost 1.35 dropped support of boost::begin()/end() for zero terminated strings (const char*/wchar_t*)?

Because it was evil in generic code. An array of char was interpreted as being as long as the initial sequence of nonzero elements, but an array of anything else was interpreted as being as long as the array.

You might ask why we didn't make it so that char(&)[N] was interpreted as an array of length N but char* was interpreted as a null-terminated string that only has forward iterators (to avoid O(N) "random access" operations, which are also evil in generic code)... I'm not entirely sure of the answer to that.

Actually, the support was not dropped altogether. It was just made explicit instead of implicit. You need to use as_literal/as_array helpers if you want to dealy with char*/char[]/wchar_t*/wchar_t[] as ranges.

Pavol, great thanks for info!

David Abrahams wrote:

on Wed Jun 18 2008, Raider wrote:

...

Can anyone tell why boost 1.35 dropped support of boost::begin()/end() for zero terminated strings (const char*/wchar_t*)?

Because it was evil in generic code. An array of char was interpreted as being as long as the initial sequence of nonzero elements, but an array of anything else was interpreted as being as long as the array.

You might ask why we didn't make it so that char(&)[N] was interpreted as an array of length N but char* was interpreted as a null-terminated string that only has forward iterators (to avoid O(N) "random access" operations, which are also evil in generic code)... I'm not entirely sure of the answer to that.

I've got the problem. It's not possible to correctly distinguish null-terminated strings and straight arrays... May be the solution is to make something like strbegin()/strend() and include it to the Boost.StringAlgo library. Or... proxy container like this: template <typename Char> class NullTerminatedStringRange { NullTerminatedStringRange(Char*); Char* begin(); Char* end(); }