Sebastian Redl wrote:

MB wrote:

...

Hi,

Does boost has anything like :

template< class T > inline const T& const_(const T& x) { return x; }

I guess that boost::cref is different...

What exactly is the use of this? Did you perhaps mean to make the parameter non-const? If so, why would you need a function for something that's an implicit cast anyway?

Hi, A short story is: struct X { }; void f(X& x); void f(const X& x); void test() { X x; { // initialize x. } f(const_(x)); } Here is the long story: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1674.pdf Regards, MB p-stade.sourceforge.net

Sebastian Redl wrote:

MB wrote:

...

A short story is:

struct X { }; void f(X& x); void f(const X& x);

void test() { X x; { // initialize x. }

f(const_(x)); }

Here is the long story: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1674.pdf

I don't see the connection. Are you looking for a way to simplify the code in listing 4?

Yes. 'const_' is something like an object-generator like 'make_pair'. Regards, MB p-stade.sourceforge.net

2006/1/15, Felipe Magno de Almeida <felipe.m.almeida@gmail.com>:

[snip]

Offtopic: Maybe the problem doesnt lie on const/non-const member functions? And the ugly syntax to choose the const when using a non-const class? Maybe this proposal shouldnt be more general? Not applying only to iterator/const_iterator. IMO, if it was, it would probably have more chance of acceptance.

IMHO, cbegin/cend proposal may be too specific as you mentioned. There may be other cases where const/non-const member function overload resolution by programmers is desirable. And inline cv-qualification conversion may become a more generic approach in such cases. For example, consider the following code. // a vector class with copy-on-write template< class T > class vector_with_cow { ..... T &operator[]( size_type index ); T const &operator[]( size_type index ) const; ..... }; void f( vector_with_cow< int > &v ) { if( const_( v )[0] == 0 ){ // do not require deep copy return; } // write some values into v, require deep copy } Best regards, -- Ai Azuma <ai.azuma@gmail.com>

Felipe Magno de Almeida wrote:

On 1/14/06, MB <mb2act@yahoo.co.jp> wrote:

[snip]

...

Here is the long story: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1674.pdf

Offtopic: Maybe the problem doesnt lie on const/non-const member functions? And the ugly syntax to choose the const when using a non-const class? Maybe this proposal shouldnt be more general? Not applying only to iterator/const_iterator.

I agree. Boost.Range has 'const_begin/end' for this purpose. But I think it could be applied to more. I renamed 'const_range' to 'const_'.

IMO, if it was, it would probably have more chance of acceptance.

If 'const_' is really missing from boost, I might do. :-) Regards, MB p-stade.sourceforge.net

On 15 Jan 2006 14:53:00 +0000, Jens Theisen <jens-theisen@gmx.de> wrote: [snip]

So it's purpose is to abbreviate a const_cast. Still useful.

It's more readable and documents better the code too. Since const_cast can take consts away, but const_ only makes it const, and easier to use in generic code, since you dont need to rewrite the instance's type to be able to add const to it.

Jens

-- Felipe Magno de Almeida

At 15:25 2006-01-15, Eric Niebler wrote:

Felipe Magno de Almeida wrote:

...

On 15 Jan 2006 14:53:00 +0000, Jens Theisen <jens-theisen@gmx.de> wrote:

...

So it's purpose is to abbreviate a const_cast. Still useful.

It's more readable and documents better the code too. Since const_cast can take consts away, but const_ only makes it const

Then perhaps it should be called "add_const".

didn't I read about something called that (or something close) in the MPL book?

-- Eric Niebler Boost Consulting www.boost-consulting.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

Sebastian Redl wrote:

Victor A. Wagner Jr. wrote:

...

didn't I read about something called that (or something close) in the MPL book?

Yes, but that's only for types (code example not authoritative - I have no idea how the thing is really called):

template<typename T> void funct(T bla) { typename boost::mpl::add_const<T>::type constant(10); // ... }

The type of constant is "const T".

Sebastian Redl

I think 'add_const' is reserved for Boost.TypeTraits. I post this tiny proposal to Boost.Devel anyway. Regards, MB p-stade.sourceforge.net

Thorsten Ottosen wrote:

MB wrote:

...

Sebastian Redl wrote:

I think 'add_const' is reserved for Boost.TypeTraits.

I post this tiny proposal to Boost.Devel anyway.

When we discussed the wg21 proposal many months ago and I added const_begin() etc to boost.range, Dave Abrahams used this function

template< class T > inline T const& as_const( T const& r ) { return r; }

I found the thread. http://lists.boost.org/Archives/boost/2004/09/72340.php Maybe the time has come? :-) A range algorithm like Boost.StringAlgorithm no longer allows users to call 'const_begin/end'. Now that something like 'as_const' is really needed. boost::for_each( rng | const_qualified | // protect rng! reversed | null_terminated | tab_expanded | utf8_decoded | transformed(toZero()), &do_something ); I think 'const_rbegin' is obviously blob ;-)

Similarly, we might add

as_volatile(); as_const_volatile(); as_mutable();

The latter would be a cast from rvalue to lvalue like it happens in boost.foreach.

Beyond my sight. Is it possible such conversion? Regards, MB p-stade.sourceforge.net

Eric Niebler wrote:

Thorsten Ottosen wrote:

...

as_mutable();

The latter would be a cast from rvalue to lvalue like it happens in boost.foreach.

Not sure what you're referring to. Boost.Foreach does no such rvalue-to-lvalue cast.

So this wouldn't compile: vector<int> foo(); ... BOOST_FOREACH( int& r, foo() ) ++r ? -Thorsten

Eric Niebler wrote:

Thorsten Ottosen wrote:

...

Eric Niebler wrote:

...

...

Not sure what you're referring to. Boost.Foreach does no such rvalue-to-lvalue cast.

So this wouldn't compile:

vector<int> foo(); ... BOOST_FOREACH( int& r, foo() ) ++r

?

No, it doesn't compile, and it shouldn't. What would be the point of mutating the unnamed temporary vector returned by foo()?

I would probably be efficiency. Assume it was a vector of strings and that you had to append "_" to each of the strings and then pass the string to some other function. Or maybe I wanted to do the following: foo::copy( foo::unique( boost::as_mutable( foo() ) ), some_where ); -Thorsten