From: Edward Diener (eddielee_at_[hidden])
Date: 2002-11-14 12:49:21
"Anthony Williams" <anthony.williamsNOSPAM_at_[hidden]> wrote in
> Edward Diener writes:
> > "Anthony Williams" <anthony.williamsNOSPAM_at_[hidden]> wrote in
> > message news:15826.2782.569000.619636_at_gargle.gargle.HOWL...
> > > Edward Diener writes:
> > > > Finally I would like a non-partisan answer from you to my next
> > and
> > > > I am perfectly willing to be wrong and accept the fact that my
> > > > understanding of "concept" based explanations are at fault. Do you
> > that
> > > > the answers to my 2 questions are readily apparent to most
> > C++
> > > > programmers from reading the property map docs ?
> > >
> > > As Jan Langer pointed out, there are specific pages for each of the
> > property
> > > map categories. If you missed these you will have difficulty piecing
> > > everything together.
> > No, I saw them from the beginning. I just didn't ( and still don't )
> > understand how they fit in with some sort of global get(), put(), and
> > operator template functions.
> operator has to be a member function if it exists at all, unless the
> built-in operator is sufficient.
> get() and put() may or may not be global, and may or may not be
> templates. They must be implemented for each property map so that the
> expressions get(property_map,key_value) and
> put(property_map,key_value,new_value) compile and work OK. This means that
> they may be global, or they may be in an associated namespace of the
> map or key value types, and found by ADL.
> The parameter types may or may not exactly match the types of the property
> etc., provided that the functions can be found, and the supplied arguments
> be converted to the required parameter types --- e.g. if the property map
> actually a pointer to X, then the real parameter for get() could be a
> to Y, if Y is an unambiguous public base of X --- and provided that
> resolution finds the correct function. I would expect in the common case,
> the get() and put() functions are supplied in the same namespace as a
> map type, and the parameter types exactly match the types of the property
> and key value, give or take a const&, but this is not necessarily the
> The presence of a template get() will probably be an impediment if the
> parameters are not an exact match for the supplied types, since deduced
> template parameters have a nasty tendency to exactly match the supplied
> arguments, and may therefore be picked in preference, or cause an
Then the get(), put(), and operator values are purely user defined and
there are no common implementations for these which automatically work with
any property map. Everything having to do with property maps are just a
generalized concept of how this should work so that a given property map has
effective get(), put() and operator functions which an end user can use to
associate a value with a property ( key ). Whatever implementations exist in
the header files are just specific types of property maps which have already
been developed based on the different categories.
Is this a correct understanding of the property map concept ? If so, it is
something I completely missed from the docs, but which others were able to
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk