On Thu, 4 Mar 2010, Steven Watanabe wrote:
AMDG
Jeremiah Willcock wrote:
I guess I don't know how many programs use boost::get from BGL as opposed to just get. Users are supposed to use ADL to find get, at least in generic code, but it would still have to be in boost because that's where the graph types are. Remember that BGL's get is part of a concept so it needs to be accessible using an unqualified name when called on a built-in graph type. I don't see any obviously good ways to do this -- changing Variant would break more code but the fix would be simpler (since it's probably just a search-and-replace for boost::get< and get< since people won't use those syntaxes with BGL). For BGL, it might be possible to move the built-in property names (and references to them would need to be fixed up), but that's a hack just to get an additional associated namespace for the built-in definitions of get(). The other fix would be to move the graph types, but that would require user code changes as well; there would also need to be a rule that graph types could not go in boost:: anymore. I added [variant] into the subject line so we can get the Variant developers in here and try to get this worked out -- it is going to be an increasing problem as you said.
Do you know which BGL overload of get is triggering this? IMHO, the graph library should not globally reserve a common name like get. Variant's overloads are well behaved, (they should never match anything except a variant and will not cause an error when they don't match.)
There are a lot of BGL overloads of get; it is intended to be found by ADL, and there's (at least) one definition for each graph type. The graph library's get has been around for a while. It is not globally reserved, at least not technically; it only applies to known graph and property map types, just like variant's. The problem is that variant's get takes explicit template arguments and that seems to make the overloading work incorrectly. I suspect that the error in this thread, for example, is coming from the boost::get version for two_bit_color_map; that function is restricted to work on only that property map type but instantiating its signature appears to be failing without SFINAE because of the explicit template argument. I think this is something that's fixed in C++0x but that doesn't help us now. Your workaround might fix the common cases though (since the compiler seems to differentiate functions based on the number of template arguments given); for some reason, the extra template argument in ::key_type is important in that definition of get. It will be annoying to have to work around this issue repeatedly, though. -- Jeremiah Willcock