[parameter] Comments and concerns
1. For type extraction, the name "binding" is *much* better than the name "index_result". 2. With regard to the rvalue issue recently tackled by Dave Abrahams and Daniel Wallin: 2.1. In my projects, I seldom assign a possible rvalue to a const reference; I almost always use a const variable. The functions for which I require named parameters are initializer functions; that is, they build containers, graphs, mazes, etc. The cost of making even several copies of mostly primitive objects is negligible in comparison. 2.2. The handful of times I do bind an rvalue to a const reference, I don't even need the object; I just want its type, and the static functions associated with it. All in all, no problems here. 3. By default, most of the property maps used by the BGL are created in the following manner: make_iterator_property_map( std::vector<ValueType>( num_vertices(graph) ).begin() , index_map , ValueType() ); Assuming such a call is expensive enough that it should be a lazy default, the corresponding code (if I'm not mistaken) would be: typedef typename property_map<Graph,vertex_index_t>::type VertexIndexMap; ... typedef std::vector<ValueType> ValueVector; ... VertexIndexMap index_map = get(vertex_index_t(), graph); ... function_impl( graph , p[ some_named_parameter || bind( &make_iterator_property_map< typename ValueVector::iterator , ValueType , VertexIndexMap > , ValueVector(num_vertices(g)).begin() , index_map , ValueType() ); ] , ... ); 3.1. A new user may easily neglect to specify the template parameter types by naively expecting Boost.Bind to accept function templates just as it does ordinary functions. (I sure did.) This is not a Boost.Parameter issue per se, but if one expects to commonly use Boost.Bind to produce lazy defaults, perhaps a gentle warning would be in order. 3.2. BTW, according to <http://www.boost.org/libs/property_map/iterator_property_map.html>, ValueType and IndexMap should be the third and second template parameters, respectively. Should <boost/property_map.hpp> be fixed to match its documentation? 3.3. These are minor issues for me, but they may be major concerns for Doug Gregor, Jeremy Siek, et al. if they're revamping the BGL to use Boost.Parameter. 4. Ah, the joys of GUI programming... 4.1. Even the simplest WxWidgets program grinds to a halt when calling a function that uses the Boost.Parameter mechanism. The same goes for FLTK and FOX. 4.2. OTOH, Irrlicht <http://irrlicht.sourceforge.net/> gives full cooperation. The only apparent difference between this library and the others (aside from the fact that it is mainly a 3D library) is that it opens up a DOS box in the background. IIRC a similar concern was posted a while back, I think wrt Boost.Test + GUIs. 4.3. I haven't had the time to produce simple test cases. If you want them, let me know. Cromwell D. Enage __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Cromwell Enage <sponage@yahoo.com> writes:
1. For type extraction, the name "binding" is *much* better than the name "index_result".
Thanks.
2. With regard to the rvalue issue recently tackled by Dave Abrahams and Daniel Wallin: 2.1. In my projects, I seldom assign a possible rvalue to a const reference; I almost always use a const variable. The functions for which I require named parameters are initializer functions; that is, they build containers, graphs, mazes, etc. The cost of making even several copies of mostly primitive objects is negligible in comparison. 2.2. The handful of times I do bind an rvalue to a const reference, I don't even need the object; I just want its type, and the static functions associated with it. All in all, no problems here.
So you're saying that the current design works pretty well for you?
3. By default, most of the property maps used by the BGL are created in the following manner:
make_iterator_property_map( std::vector<ValueType>( num_vertices(graph) ).begin() , index_map , ValueType() );
Assuming such a call is expensive enough that it should be a lazy default
It almost certainly isn't expensive, but I'll humor you...
the corresponding code (if I'm not mistaken) would be:
typedef typename property_map<Graph,vertex_index_t>::type VertexIndexMap; ... typedef std::vector<ValueType> ValueVector; ... VertexIndexMap index_map = get(vertex_index_t(), graph); ... function_impl( graph , p[ some_named_parameter || bind( &make_iterator_property_map< typename ValueVector::iterator , ValueType , VertexIndexMap > , ValueVector(num_vertices(g)).begin() , index_map , ValueType() ); ] , ... );
Okay, seems plausible.
3.1. A new user may easily neglect to specify the template parameter types by naively expecting Boost.Bind to accept function templates just as it does ordinary functions. (I sure did.) This is not a Boost.Parameter issue per se
Not even a little bit.
but if one expects to commonly use Boost.Bind to produce lazy defaults, perhaps a gentle warning would be in order.
Perhaps a gentle encouragement to put the gentle warning in the Boost.Bind docs would be in order? ;-)
3.2. BTW, according to <http://www.boost.org/libs/property_map/iterator_property_map.html>, ValueType and IndexMap should be the third and second template parameters, respectively. Should <boost/property_map.hpp> be fixed to match its documentation?
I suggest you post this question under a new subject line, so that those concerned with the property map library will notice.
3.3. These are minor issues for me, but they may be major concerns for Doug Gregor, Jeremy Siek, et al. if they're revamping the BGL to use Boost.Parameter.
4. Ah, the joys of GUI programming... 4.1. Even the simplest WxWidgets program grinds to a halt when calling a function that uses the Boost.Parameter mechanism. The same goes for FLTK and FOX.
That's alarming! But do you mean that the compiler gets slow (and if so, which compiler?), or are you actually saying that the parameter library induces runtime costs that slow down WxWidgets programs to a crawl? That's almost impossible for me to believe.
4.2. OTOH, Irrlicht <http://irrlicht.sourceforge.net/> gives full cooperation. The only apparent difference between this library and the others (aside from the fact that it is mainly a 3D library) is that it opens up a DOS box in the background. IIRC a similar concern was posted a while back, I think wrt Boost.Test + GUIs. 4.3. I haven't had the time to produce simple test cases. If you want them, let me know.
I'm totally lost, so yeah, probably I need some test cases in order to get a grip on what you're talking about. -- Dave Abrahams Boost Consulting www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
Perhaps a gentle encouragement to put the gentle warning in the Boost.Bind docs would be in order? ;-)
Done. [snip]
template parameters, respectively. Should <boost/property_map.hpp> be fixed to match its documentation?
I suggest you post this question under a new subject line, so that those concerned with the property map library will notice.
Done. [snip]
That's alarming! But do you mean that the compiler gets slow (and if so, which compiler?), or are you actually saying that the parameter library induces runtime costs that slow down WxWidgets programs to a crawl? That's almost impossible for me to believe.
Did I say that the compiler "grinds to a halt"? I meant that the executable "runs into a brick wall", or "hangs". But that was when I ran the tests using the old version (Boost.NamedParams). The tests now run just fine using the current version (Boost.Parameter). So, sorry for the noise. Cromwell D. Enage __________________________________ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html
Cromwell Enage <sponage@yahoo.com> writes:
That's alarming! But do you mean that the compiler gets slow (and if so, which compiler?), or are you actually saying that the parameter library induces runtime costs that slow down WxWidgets programs to a crawl? That's almost impossible for me to believe.
Did I say that the compiler "grinds to a halt"?
No, but people are often imprecise so I didn't know what you meant.
I meant that the executable "runs into a brick wall", or "hangs".
But that was when I ran the tests using the old version (Boost.NamedParams).
The tests now run just fine using the current version (Boost.Parameter).
Whew!
So, sorry for the noise.
Not at all! If recent changes hadn't fixed the problem by chance, it would have been very important to know about it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
Cromwell Enage -
David Abrahams