So what about 1?

...

2. Forwarding problem This library is affected by forwarding problem. I do not know how important it is, but may be we should use by-value scheme used by boost::bind?

won't boost::ref <> "solve" this. (don't bind use &?)

No and no.

...

3. Library doesn't allow to create const collections. Well, I am not sure whether or not it's doable but currently it's not supported

It has already been suggested to support

const vector<int> v = init( v )(1)(2).

How you plan to implement this? init( v ) wouldn't be able to modify v since it is declared const.

...

1. insert_assigner( C& c, const value_type& v ) (a) as well as fixed_size_assigner( const iterator& begin, const iterator& end, const value_type& v ) are unnecessary (b)

(a) is used with operator+=()

You don't need it template< typename C > inline insert_assigner<C> operator+=( C& c, const typename C::value_type& v ) { return insert_assigner<C>( c ), v; } The same idea with second guy.

(b) is used with operator<<(). If this goes away, it will sill eb used in eg

assign_all( array ) = 1,2,3;

Why?

...

2. Should we use Boost::pp to implement insert_assigner, fixed_size_assigner e.t.c. and have configurable limit?

Some have wanted this. I have no problems with it besides I can't see what its good for. Having a function/constructor with more than X arguments (x small) is hardly good practice.

Why 6 then? Why not 4?

...

4. ~fixed_size_assigner This method may throw an exception. Does it always safe to rely on uncaught_exception call?

No, it is not always safe, but the unsafe stuff happens if you use it in a destructor; not very likely. Sutter has an article about it.

Where?

...

5. No function template ordering handling Why not use usual trick with extra long parameter?

Sure. What's the trick and what's the issue?

template< typename C, typename V > inline void make_insertion( C& c, const V& v, long ) { c.insert( c.end(), v ); } ... void insert_( const value_type& v ) { make_insertion( c_, v, 0 ); // 0 is of type int } Now you could use generic version even for compilers that does not support partial ordering and you could remove all repetition from stl.hpp Gennadiy.

Thorsten Ottosen wrote:

...

...

won't boost::ref <> "solve" this. (don't bind use &?)

No and no.

(a) My comments about boost::bind comes from http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm

But bind's reference docs seems to use by-value.

Looking at the code, it seems boost::bind uses non-const reference for operator() -- the actual forwarding -- and by-value for arguments to 'bind' itself. So, you should add pass by non-const reference to the list of alternatives. What I think about it is that const-reference prevents you from passing non-const references to constructors of objects you put to container. OTOH, with non-const references you'd break the passing of integer literals -- which is the point of the library. Maybe, you really should support ref<> for passing non-const references. - Volodya

Hi Thorsten,

...

Looking at the code, it seems boost::bind uses non-const reference for operator() -- the actual forwarding -- and by-value for arguments to 'bind' itself.

I must admit I don't get that. I extended rhe example to show the problems (see attachment). As you point out, bind() *silently* compiles code that would not compile if one called the original function with those arguments. IMO, *very* trouplesome.

What I was saying is that bind uses non-const reference for operator(), so if you use: bind(foo, _1)(i); bind( foo, _1 )(ci); then it will work ok. In fact, first one compiles and the second one does not. And, BTW, "foo(i)" compiles just fine too, so your 'proper_forward(i)' should compile too, but it does not. As for bind(foo, i)(); bind(foo, ci)(); I don't have any opinion yet.

...

What I think about it is that const-reference prevents you from passing non-const references to constructors of objects you put to container.

only in the sense that you need to use boost::ref<>

Ah, since you only forward arguments boost::ref<> will work transparently and you never need to unwrap_reference in the library code.

...

OTOH, with non-const references you'd break the passing of integer literals --

any "literal", in fact.

Yes, I've used "integer" for example only.

...

Maybe, you really should support ref<> for passing non-const references.

Depends on what you mean by support :-) It's already supported by using ref<>. I think that is ok; afterall, reference arguments should not be used that much thoughout code.

I agree. In fact, my previous post was just a long-winded way to say that while in general non-const references might be preferrable, for this library const references are better. - Volodya

"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

...

I don't have any opinion yet.

I guess I didn't know that I was "misusing" bind(). Anyway, I find it wrong that bind(foo,_1)(i) and bind(foo,i)() differs.

Naturally it has to differ. bind(foo,i) needs to take a copy of i, or we wouldn't be able to do things like: int square(int); function<void(void)> f(int x) { return bind(square, x * 5); } -- Dave Abrahams Boost Consulting www.boost-consulting.com

Thorsten Ottosen wrote:

My point is that if the prototype was

void square( int& );

then

function< void(void) > f( int x ) { return bind( square, x*5 ); }

should not compile.

Why should it not compile? int increment(int & x) { return ++x; } template<class F> void test_nonconst(F f) { std::cout << f() << '\n'; std::cout << f() << '\n'; std::cout << f() << '\n'; } template<class F> void test_const(F const & f) { std::cout << f() << '\n'; std::cout << f() << '\n'; std::cout << f() << '\n'; } int main() { test_nonconst( bind(increment, 0) ); // 1 2 3 test_const( bind(increment, 0) ); // compile-fail } It's as if you've written struct increment { int a1_; int operator()() { return ++a1_; } }; yourself.

Thorsten Ottosen wrote:

"Peter Dimov" <pdimov@mmltd.net> wrote in message news:001501c42095$eb0425b0$1d00a8c0@pdimov2...

...

Thorsten Ottosen wrote:

...

My point is that if the prototype was

void square( int& );

then

function< void(void) > f( int x ) { return bind( square, x*5 ); }

should not compile.

Why should it not compile?

consider instead

void write_to( string& s ) { s += " foo"; }

string s = "bar"; bind( write_to, s )(); cout << s; // won't print "bar foo"

That's how bind works. All arguments in "bind(write_to, s)" are copied, including 'write_to'. If you make 'write_to' a stateful function object, "bind(write_to, s)()" won't update 'write_to' either.

Thorsten Ottosen wrote:

"Peter Dimov" <pdimov@mmltd.net> wrote in message news:000d01c420a3$e68d6240$1d00a8c0@pdimov2...

...

Thorsten Ottosen wrote: [snip]

...

...

Why should it not compile?

consider instead

void write_to( string& s ) { s += " foo"; }

string s = "bar"; bind( write_to, s )(); cout << s; // won't print "bar foo"

That's how bind works. All arguments in "bind(write_to, s)" are copied, including 'write_to'. If you make 'write_to' a stateful function object, "bind(write_to, s)()" won't update 'write_to' either.

But isn't it possible to reject compiling the above example? It's really not what I would expect people to expect, especially since bind(write,_1)(s) differs.

Yes, of course it is possible to reject the example. But I don't want to reject it. It's useful. bind(write, _1)(s) is a false analogy. bind is never used like that outside of toy illustrative examples. You always pass bind(write, _1) to someone else, and bind(f, a) always makes copies of f and a for lifetime reasons, regardless of their types. Consider using lambda::bind, which fails the above example. Isn't competition wonderful?

Thorsten Ottosen wrote:

Hi Peter,

[snp]

...

Yes, of course it is possible to reject the example. But I don't want to reject it. It's useful.

Ok. Could you present an example?

This feature of bind is used to create stateful function objects. In a "real" lambda facility it corresponds to a local static variable: for_each( first, last, lambda(v) { static int x = 0; f(v, ++x); } ); The bind equivalent is for_each( first, last, bind( f, _1, bind(incr, 0) ) ); It calls f(first[0], 1), f(first[1], 2), and so on.

Let me explain what bothers me. I simply fail to see why a call-back created with bind() should silently behave differently from what it forwards to. IMO that will create confusion.

Bind's emphasis is on usefulness, not hand-holding. Its learning curve is inherently steep and more importantly, it simply cannot be flattened by making bind less useful. To focus on how to make it less confusing would mean to penalize advanced users while, at the same time, not helping beginners in any significant way.

Vladimir Prus <ghost@cs.msu.su> writes:

Looking at the code, it seems boost::bind uses non-const reference for operator() -- the actual forwarding -- and by-value for arguments to 'bind' itself.

Note that templated non-const references will bind to const and non-const lvalues (with different 'T' deduction). The only things they won't bind to are rvalues. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Hi Keith, "Keith Burton" <kb@xtramax.co.uk> wrote in message news:KBDUALJnY2bH6qNwqDt00000001@xtramax.co.uk...

Thorsten

I trust that you are aware of the following quoted, from MSDN for all Microsoft C++ compilers

Thanks for the pointer. I must admit I always assume the compiler is a C++ compiler :-)

" As can be seen in the Visual C++ source file, uncaught.cpp, uncaught_exception always returns false even in cases where the standard specifies that it should return true.

See Knowledge Base article Q242192 for more information. "

dreadful. br Thorsten