From: David Abrahams (dave_at_[hidden])
Date: 2005-05-19 08:15:12
Cromwell Enage <sponage_at_[hidden]> writes:
> 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.
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:
> , 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
> typedef std::vector<ValueType>
> index_map = get(vertex_index_t(), graph);
> , p[
> || bind(
> 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
> ValueType and IndexMap should be the third and second
> template parameters, respectively. Should
> <boost/property_map.hpp> be fixed to match its
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk