Re: [boost] Graph Algorithms

Subject: Re: [boost] Graph Algorithms
From: mike.dev_at_[hidden]
Date: 2019-02-23 10:48:16

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Marc Glisse via Boost
> Sent: Friday, February 22, 2019 8:24 PM
> 
> On Wed, 20 Feb 2019, Vinnie Falco via Boost wrote:
> 
> > On Wed, Feb 20, 2019 at 10:00 AM Siddhartha Sen via Boost
> > <boost_at_[hidden]> wrote:
> >> Is there any interest in a library containing graph algorithms? Also, I am
> >> unable to find the list of maintainers of the respective libraries. Any
> >> information on that would be appreciated.
> >
> > I've heard from a couple of folks that they would really like a
> > "modern C++" version of BGL. Something that uses everything in C++11
> > to streamline the interface and get better performance.
> 
> Better performance and C++xy may be rather unrelated for boost.graph. I am
> affected by issues #142 and #143, which do not require any recent C++. 

Better Performance may also mean better compile time performance.
I don't know if this is a problem with BGL specifically, but think the 
number one complain I get about boost libraries are their compile time impact. 
Number two is that I have to include half of boost (with all the baggage that 
entails) even if I only need one specific library. Both of those factors can 
be reduced by using newer standards.

@Vinne: You are arguing, as if implementation complexity doesn't affect 
the users, but time spent by the maintainer on working around a limitation 
in an outdated standard is time not spent on developing new features, fixing 
other bugs or work on design and performance improvements. Especially when 
the maintainer has only little time to work on the library that is an 
important trade off. 

Also Consider the following: If you start a new project now that will anyway 
need some time to gain a significant user base and which you want to support 
in a backwards compatible fashion for 5+ years: Should your main concern 
really be the current landscape or rather the environment during the lifetime
the project.

That being said: If the goal is to improve BGL and not to write a BGL v2, then
I agree, that switching to c++17 is probably not useful or realistic.

Best
Mike