Re: [boost] [EXTERNAL] [graph] Sync develop with master?

Subject: Re: [boost] [EXTERNAL] [graph] Sync develop with master?
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-08-11 01:13:46

On 8/11/2016 12:31 AM, Belcourt, Kenneth wrote:
>
>> On Aug 10, 2016, at 2:38 PM, Murray Cumming <murrayc_at_[hidden]> wrote:
>>
>> On Di, 2016-08-09 at 17:28 +0000, Belcourt, Kenneth wrote:
>>> This is certainly an upgrade worth discussing.  I’m not convinced we
>>> should drop support for pre-C++11 compilers as I have several systems
>>> that I need to run BGL and other Boost libraries on that can’t
>>> upgrade to C++11 at this time.  And I’d bet there’s other users in
>>> the same boat.
>>
>> Can't they stick with older versions of BGL? People didn't seem to need
>> the fixes in the recent releases for the last couple of years, because
>> develop didn't get merged to master - they were effectively using an
>> old version with not much more than a version number change. They would
>> only be forced to use a newer BGL because of the bundling of BGL with
>> other Boost libraries that they might want to upgrade.
>
> Right, some of our projects are using develop for this very reason.
>
>> But this is a general Boost issue, I guess, and I don't know of any
>> guidelines. I think Boost has to drop support for older compilers at
>> some point so the Boost code can move forward with clean code. I've
>> found that things like variadic templates and decltype(auto) can
>> massively simplify generic code.
>
> Agreed that c++11 and 14 offers much, but I’d really hate to lose a functioning capability like BGL c++98 without understanding the impact to existing users (perhaps a poll is in order).  On the other hand, requiring legacy support risks alienating developers like yourself who want to move Boost forward.
>
> Just curious, but do you envision supporting the legacy API in the new BGL, or will users have to upgrade their code to use the new BGL?  Could both API versions exist in a single code base to facilitate migration from the old APIs to the new, assuming the APIs break (e.g. could we use namespaces to manage different API versions in the same code base to allow incremental adoption)?

You could support both a C++98 version and a C++11 version of your 
library using the Cxx_dual library. But since practically no one showed 
an interest in my Cxx_dual library I want to repeat here that the 
situation where any library, not just Graph, wants to support both a 
C++98 version and a C++11 version of the library with much of the same 
set of code is the main purpose of the Cxx_dual library.