"Anthony Williams" <[EMAIL PROTECTED]> wrote in message news:15827.36666.343000.937688@;gargle.gargle.HOWL... > Edward Diener writes: > > "Anthony Williams" <[EMAIL PROTECTED]> wrote in > > message news:15826.2782.569000.619636@;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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
