[boost] Re: Re: Re: Property_map docs

From: Edward Diener (eddielee_at_[hidden])
Date: 2002-11-14 12:49:21

"Anthony Williams" <anthony.williamsNOSPAM_at_[hidden]> wrote in
message news:15827.36666.343000.937688_at_gargle.gargle.HOWL...
> 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
question
>  > and
>  > >  > I am perfectly willing to be wrong and accept the fact that my
lack of
>  > >  > understanding of "concept" based explanations are at fault. Do you
feel
>  > that
>  > >  > the answers to my 2 questions are readily apparent to most
intelligent
>  > 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
property
> map or key value types, and found by ADL.
>
> The parameter types may or may not exactly match the types of the property
map
> etc., provided that the functions can be found, and the supplied arguments
can
> be converted to the required parameter types --- e.g. if the property map
is
> actually a pointer to X, then the real parameter for get() could be a
pointer
> to Y, if Y is an unambiguous public base of X --- and provided that
overload
> resolution finds the correct function. I would expect in the common case,
that
> the get() and put() functions are supplied in the same namespace as a
property
> map type, and the parameter types exactly match the types of the property
map
> and key value, give or take a const&, but this is not necessarily the
case.
>
> 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
ambiguity.

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
understand immediately.