boost.range and "const char[]".

[sergey_shandar]

// Both boost::end(...) and boost::size(...) return
wrong values.
// Compilers: GCC 3.3.4 and VC 7.1.
// A simple example:

#include <boost/range/size.hpp>
#include <boost/test/minimal.hpp>

int test_main(int, char *[])
{
	const char A[] = "\0A";
	BOOST_CHECK(boost::size(A)==2); // failed.
	return 0;
}

[nobody]

Logged In: NO 

The size is supposed to be 3 in this example. As described in the C++ 
standard, C-style strings include a terminating "\0" character. Your string 
will have 3 characters, '\0', 'A', and '\0'.

[sergey_shandar]

Logged In: YES 
user_id=957289

I know that a size of this array is 3. boost::size(A) should
return 2 because of
http://www.boost.org/libs/range/doc/boost_range.html#size.
But it returns 0. The problem is boost::size and boost::end
handles A as "const char *" instead of "const char[3]".

I have not checked other functions as rbegin.

[Thorsten Ottosen]

Logged In: YES 
user_id=637229

The support for string arguments is deprecated and will go 
away in the next major release. According to the current 
implementation, the code behaves just as designed.

br

Thorsten

[sergey_shandar]

Logged In: YES 
user_id=957289

>According to the current 
implementation, the code behaves just as designed.

No, it doesn't. Accordint to the documentation 
http://www.boost.org/libs/range/doc/boost_range.html#size it
MUST return 2 but it returns 0. It's a serious bug. Change
either documentation or code.

[Thorsten Ottosen]

Logged In: YES 
user_id=637229

arrays (and so string literals) have their size deduced at 
compile-time. Embedding a null will not change that.

What is the use of the literal above anyway?

-Thorsten

[sergey_shandar]

Logged In: YES 
user_id=957289

>arrays (and so string literals) have their size deduced at 
compile-time. Embedding a null will not change that.

Yeah, it would be good if it beahaves like this. However, 
according to example, the size depends on a position of a 
null so boost::size(A) == 0 (Boost 1.33). Sure I expected 
compile time - 2.

>What is the use of the literal above anyway?

It's just a minimal example that shows a bug in Boost.Range 
1.33, I don't know much about 1.34. I prefer compile time 
computation where it's possible. Currently, I use my own 
range library (http://cbear.berlios.de/range), it doesn't 
accept char* and wchar_t* as a range. Only T(&)[N] types 
are accepteble.

[anonymous]

The same bug in 1.34