Hi,
Please take a look at the code below.
The point is that for_each_treenode calls for_each_treenode_child. It seems
to me that
bind(Print, ref(cout), _1)(&t);
is not the same as
Print(cout, &t);
But if this is the case, how come that
for_each_treenode_child(&t, bind(Print, ref(cout), _1));
compiles and works without problem?
The compiler I use is VC 7.1.
Thx,
Gus
----------------------------------------------------------------------
// xBindTemplFuncPtr.cpp : Defines the entry point for the console
application.
//
#include "stdafx.h"
#include <iostream>
#include <vector>
#include <string>
#include
Agoston Bejo wrote:
Hi, Please take a look at the code below. The point is that for_each_treenode calls for_each_treenode_child. It seems to me that bind(Print, ref(cout), _1)(&t); is not the same as Print(cout, &t); But if this is the case, how come that for_each_treenode_child(&t, bind(Print, ref(cout), _1)); compiles and works without problem?
[...]
Print(cout, &t); // WORKS bind(Print, ref(cout), _)(&t); // GENERATES ERROR (1)
The error is caused by the fact that &t is an rvalue. Tree * pt = &t; bind(Print, ref(cout), _1)(pt); // should work
for_each_treenode_child(&t, bind(Print, ref(cout), _1)); // WORKS for_each_treenode(&t, bind(Print, ref(cout), _1)); // GENERATES ERROR (2)
This is a bit more convoluted. The problem is that for_each_treenode uses
bind(Print, ref(cout), _1) as an argument to bind. The inner bind is
interpreted as a nested bind expression and evaluated. Use either
for_each_treenode(&t, protect(bind(Print, ref(cout), _1))); // should work
or change the bind in for_each_treenode to bind(thisFunc, _1, protect(f)).
protect lives in
Peter Dimov wrote:
Agoston Bejo wrote:
Hi, Please take a look at the code below. The point is that for_each_treenode calls for_each_treenode_child. It seems to me that bind(Print, ref(cout), _1)(&t); is not the same as Print(cout, &t); But if this is the case, how come that for_each_treenode_child(&t, bind(Print, ref(cout), _1)); compiles and works without problem?
[...]
Print(cout, &t); // WORKS bind(Print, ref(cout), _)(&t); // GENERATES ERROR (1)
The error is caused by the fact that &t is an rvalue.
Tree * pt = &t; bind(Print, ref(cout), _1)(pt); // should work
for_each_treenode_child(&t, bind(Print, ref(cout), _1)); // WORKS for_each_treenode(&t, bind(Print, ref(cout), _1)); // GENERATES ERROR (2)
This is a bit more convoluted. The problem is that for_each_treenode uses bind(Print, ref(cout), _1) as an argument to bind. The inner bind is interpreted as a nested bind expression and evaluated. Use either
for_each_treenode(&t, protect(bind(Print, ref(cout), _1))); // should work
or change the bind in for_each_treenode to bind(thisFunc, _1, protect(f)).
protect lives in
.
I think, Mr. Dimov, if you could document 'protect' and 'apply' a little better in relation to boost::bind and give more exmaples of their usage, it would be helpful to many programmers running into problems such as the current one has. In particular, explaining better exactly what is meant by 'evaluated' would be helpful in the documentation to nested binds. If I am too picky asking for a clearer and slower explanation of these things in the documentation, then it is clearly my fault that I find some of them hard to understand as written.
Edward Diener wrote:
I think, Mr. Dimov, if you could document 'protect' and 'apply' a little better in relation to boost::bind and give more exmaples of their usage, it would be helpful to many programmers running into problems such as the current one has.
I am left with the impression that you think that I find the documentation perfect, have plenty of free time, but deliberately don't update it. ;-) Believe me, this is not the case. I merely find it "good enough" for a volunteer one man effort from which I have not derived (and have never expected) any monetary value. Perhaps it would be possible for you to write a short (*) Bind article that complements the current documentation? We can then decide whether and how to incorporate it in the official distribution. -- (*) Or long. ;-)
Peter Dimov wrote:
Edward Diener wrote:
I think, Mr. Dimov, if you could document 'protect' and 'apply' a little better in relation to boost::bind and give more exmaples of their usage, it would be helpful to many programmers running into problems such as the current one has.
I am left with the impression that you think that I find the documentation perfect, have plenty of free time, but deliberately don't update it. ;-)
What in the language to my comment would make you believe that ? You have greatly misinterpreted my simple suggestion or something in the tone of it. I did see your smiley, but I think you are reading into the above more than is actually there.
Believe me, this is not the case. I merely find it "good enough" for a volunteer one man effort from which I have not derived (and have never expected) any monetary value.
Fair enough. I really don't see what your deriving any monetary value has to do with your viewpoint, however. If you were well paid for the documentation would you then not find it "good enough" ?
Perhaps it would be possible for you to write a short (*) Bind article that complements the current documentation? We can then decide whether and how to incorporate it in the official distribution.
I really don't quite understand how "protect" and "apply" actually work myself, which is why I asked for a clearer explanation, with some good examples. The word "evaluate" confuses me when referring to these ideas. I was hoping that by suggesting a clearer explanation of it in the documentation I would understand how better to use these constructs. If I could understand it, I would gladly write something about it and send it to you as possible additional documentation to boost::bind, since I think very highly of boost::bind and have used it in some of my own software. I don't mean to sound dumb about "protect" and "apply" by this idea of lazy or immediate evaluation in boost::bind eludes me.
Edward Diener wrote:
Peter Dimov wrote:
Edward Diener wrote:
I think, Mr. Dimov, if you could document 'protect' and 'apply' a little better in relation to boost::bind and give more exmaples of their usage, it would be helpful to many programmers running into problems such as the current one has.
I am left with the impression that you think that I find the documentation perfect, have plenty of free time, but deliberately don't update it. ;-)
What in the language to my comment would make you believe that ?
Well, since you asked: it struck my ear that way too, and I think the reason is that the "I think, Mr. Dimov" gives the whole thing too formal a tone, almost as if you were talking down to him or demanding that he do something about it. If you had omitted those first four words it would have been a simple request; if you had omitted the "Mr. Dimov", it would have had a much more friendly tone. In some contexts "Mr. Dimov" would show respect, but in the informal context of a mailing list it has the opposite effect. From your reply you obviously didn't mean it the way it sounded to Peter and to me; no big deal--that's one of the hazards of written communication with people you've never met. Mike
At Friday 2004-06-04 07:35, Mike wrote: [elided] some contexts "Mr. Dimov" would show respect, but in the informal context of a mailing list it has the opposite effect.
From your reply you obviously didn't mean it the way it sounded to Peter and to me; no big deal--that's one of the hazards of written communication with people you've never met.
especially ones from widely divergent backgrounds and custom. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
participants (5)
-
Agoston Bejo -
Edward Diener -
Michael Glassford -
Peter Dimov -
Victor A. Wagner Jr.