Re: [Boost-users] [graph][spirit][variant] Boost.Graph and Boost.Spirit incompatible ?

Subject: Re: [Boost-users] [graph][spirit][variant] Boost.Graph and Boost.Spirit incompatible ?
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2010-03-04 14:42:14

On Thu, Mar 4, 2010 at 1:21 PM, Jeremiah Willcock <jewillco_at_[hidden]>wrote:

> On Thu, 4 Mar 2010, Maxime van Noppen wrote:
>
>  On 03/04/2010 08:06 PM, Jeremiah Willcock wrote:
>>
>>> This is the same issue as variant actually -- the boost::get thing.  The
>>> info object that is causing trouble in char.hpp contains a variant that
>>> it's trying to get a field from.  It's too bad that a later library
>>> (variant) reused a name from an earlier one (graph), but it's probably
>>> too late to do anything about either one.
>>>
>>
>> This seems quite critical to me. As the times goes, more and more boost
>> libraries might use variant and therefore become incompatible with
>> Boost.Graph. Wouldn't it be better to break backward compatibility for a
>> given release and solve this issue ? The backward compatibility is
>> already broken : our codebase compiles fine in Boost 1.39 and doesn't in
>> Boost 1.41 because of this issue.
>>
>
> 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.
>
>
Frankly I have always thought boost::get is a terrible name.  Such a generic
name for a free function is practically inviting trouble.

Zach