Andrew Sutton wrote:
const property_map<...>::const_type map; // or something similar.
For all property maps, map = get(...) is a valid expression, regardless of whether your map is a ::type or ::const_type. By declaring it const, and then instantiating a template with the const pmap, you're going to run into problems - probably the problem you reported earlier.
Okay, so if I understand correctly I shouldn't use const prop maps with const_type at all?
It seems to me like a line such as the above should still theoretically compile. At least from the perspective of a concept check for Readability; this is by definition what const is meant to restrict objects to so in theory in should be allowable no? If I'm right it would be a compilation error caused by the underlying implementation. Either that or a debatable foible that should be documented? *shrug*.
I don't think you should be using const property maps at all - with type or const_type. For example:
Okay.
/* 1 */ property_map<...>::const_type p; // Good /* 2 */ const property_map<...>::const_type p; // Bad
The const_type in 1 forces the p to operate on its underlying reference in a const way. Returing const references, no put() operation, etc. The leading const in 2 means that you can't write:
p = q; // Assuming q is type property_map<...>::type
It's a compiler error since p is not modifiable.
I agree, both situations are perfectly reasonable.
If you look at the concept definition in boost/property_map.hpp for ReadablePropertyMapConcept, you'll find, in the constraints() member, this line:
val = get(pmap, k)
So apparently, the concept definition actually requires that property maps are never const - which is admittedly a little weird.
It sounds like we're now on the same page! The above essentially means that it becomes literally impossible to write perfectly const-correct code (from a user standpoint). While const-incorrect code is bad enough, it also means that I may be missing out on potential compiler optimizations, that bugs me quite a bit more. What may be done to remedy this?
Andrew Sutton andrew.n.sutton@gmail.com
Thanks, Geoff