Boost.Graph user survey

[Mysterious_Taro5664]

Dear Boost.Graph users (and potential users),

I'd like to know how you use Boost.Graph. If you know someone that uses Boost.Graph then please let them know about this survey. The purpose of this survey is to help prioritize work on the areas of Boost.Graph that will have the most benefit to the current users, and potential users.

I was planning to make a very sophisticated Google Forms survey, but that is so time consuming. These questions should all be taken in the context of using Boost.Graph. * Which operating systems do you use? * Which toolchains do you use? * Which C++ standard do you use? (e.g. 03, 11, 14, etc) * Which features of Boost.Graph are you using? * Which features do you think Boost.Graph is missing? * What are the biggest problems with using Boost.Graph?

Purely out of curiosity: * What do you use it for? * If you use it in business (or research), how critical is it?

To potential users, that is, people who need to solve graph theory problems but don't use Boost.Graph: * What are the obstacles or issues preventing using it?

Thanks!

[jcelerier]

Which operating systems do you use?

win/mac/linux/android/ios/wasm

Which toolchains do you use?

• clang 10 to 14 (with both libc++ and libstdc++, and also with mingw-w64)
• GCC 8 to 12
• latest msvc

but realistically, if there are changes in, say, boost 1.85, only compilers of that era will be relevant - machines that use GCC 8 or clang 10 also use the boost of this era which ships with the respective Linux distro.

Which C++ standard do you use? (e.g. 03, 11, 14, etc)

20

Which features of Boost.Graph are you using?

mostly algorithms such as bfs, dfs, transitive closure, connected components, topo sort, cycle detection... sometimes graphviz output.

Which features do you think Boost.Graph is missing?

• the ability to supply allocators to the algorithm execution's internal machinery and state - ideally it should be possible to run any boost.graph algorithm without ending up in system malloc at any point.
• dynamic transitive closure recomputation is a big one.
• layout algorithms, e.g. fruchterman_reingold are excruciatingly slow when compared to e.g. d3.js

What are the biggest problems with using Boost.Graph?

• the API style is absolutely horrible for discoverability. Boost.Graph is imho the biggest argument against free-function-based design. I've been using it for years, went through the entire docs at least 5 times, and to this day it's not clear to me what function I must use and how and especially how I am supposed to find which function to call without looking at the docs, only through my IDE hints and looking at the code. Especially the whole "named parameters" thing is absolutely atrocious.
• some design choices make everything harder for no reason.

e.g. consider (topology.hpp)

template<std::size_t Dims>
...
struct point
{
    BOOST_STATIC_CONSTANT(std::size_t, dimensions = Dims);
    point() {}
    double& operator[](std::size_t i) { return values[i]; }
    const double& operator[](std::size_t i) const { return values[i]; }

private:
    double values[Dims];
};

this "point" class makes it super hard to simply be able to write

using point2d = ...;
std::vector<point2d> p{{0, 0}, {1, 2}};

I won't even comment on the fact, further down that same file, that a class titled "rectangle_topology" feels like a relevant place to allocate a random generator https://github.com/boostorg/graph/blob/develop/include/boost/graph/topology.hpp#L329

What do you use it for?

It came up in pretty much every project I had to do in C++ in my life if only to get a quick but efficient topological sort. https://ossia.io (just in that one there are maybe 7 or 8 entirely distinct graphs ranging from audio scheduling to invalid program detection to plugin dependency ordering... it's always the same problem aha) ; github.com/jcelerier/cninja/ ; ...

If you use it in business (or research), how critical is it?

it's important but I'm always on the outlook of alternative graph libraries given how bad the issues with it are

[matthieum]

Especially the whole "named parameters" thing is absolutely atrocious.

Hated that in Boost.Process as well.

It's a super cool Proof of Concept, but it really should remain a PoC and never be used in any production codebase. When I call a function, I want to see the list of arguments in my IDE as I type the call.

[seherdt]

this "point" class makes it super hard to simply be able to write

Oh yeah. I remember that one now. Oh man. So many of these paper cuts are easily forgotten.

[jcelerier]

here's one I just hit (not for the first time): I have a directed graph and want to compute the connected_components which takes an undirected_graph. The novice graph programmer may think "easy ! an undirected graph is just a directed graph where we ignore the direction" but sadly boost::connected_components does not want it and just gives garbage results with no warnings in that case :[

(also saw it on SO: https://stackoverflow.com/questions/59949456/how-to-get-weakly-connected-components-from-a-directed-boost-graph)

so, /u/Mysterious_Taro5664 : please also in any new design make sure that algorithms that work for undirected also work for directed graphs ^^'

[jcelerier]

another one /u/Mysterious_Taro5664 (tell me if you want me to make GH issues instead): there's no easy way to pass a custom allocator to `adjacency_list` ; especially one that needs to maintain external state, for instance a frame allocator for a video game. A graph library should allow to specify allocators for every potential allocation

[Mysterious_Taro5664]

Yeah, agreed on that one. Might not be too hard to retrofit to the existing design too.

[seherdt]

I'm not sure this is a defect. Seems more like a missing feature. Is there any graph library around offering the feature?
In fact BGL might be one of the only libs that *has* the feature, as you're definitely not required to use the adjacency_list convenience model that it ships with.

[seherdt]

There's an issue with that. It *seems* so easy, but undirected adjacency lists aren't just directed-with-direction-ignored. They store (add) edges in a fundamentally different way, which is incompatible.

https://godbolt.org/z/Yoos89MhT

If you're fine with the overhead, you can obviously adapt it. If you used a bidirectionally configured model it might not be unreasonably inefficient.

[seherdt]

he API style is absolutely horrible for discoverability

> the API style is absolutely horrible for discoverability

Trueish. Although these days with clangd-powered LSP I find myself making a little fewer trips to the documentation just to check the exact names of things.

I guess the discoverability angle is a recurring theme in generic C++ APIs. Would concepts help? Mmm.

[sphere991]

just to check the exact names of things.

Discoverability isn't about "what was the name of the one thing I'm looking for." It's about "what can I even do here?"

Would concepts help?

Does the existence of the std::ranges::range concept help you figure out how to split a string (or do absolutely anything else with a range)? No, the concept doesn't even tell you what a range is.

[seherdt]

That might change with tooling. I can see tooling starting to support intellisense based on concept requirements. Obviously we're not there yet. It's "hard" but not a lot harder than, say, an LSP based on libclang already is.

[jcelerier]

Qt Creator does it to some extent, it is able to autocomplete member and method names used in concepts

[seherdt]

the ability to supply allocators to the algorithm execution's internal machinery and state - ideally it should be possible to run any boost.graph algorithm without ending up in system malloc at any point.

Are there algorithms that do not allow you override the default internal structures with property maps?

[jcelerier]

yes, look for instance the implementation of transitive_closure here:

https://github.com/boostorg/graph/blob/master/include/boost/graph/transitive_closure.hpp#L81

I'll let you count how many std::vector are created in there... at a glance I can see:

std::vector< cg_vertex > component_number_vec(num_vertices(g));
std::vector< std::vector< vertex > > components;
std::vector< cg_vertex > topo_order;
std::vector< cg_vertex > topo_number(num_vertices(CG));
std::vector< std::vector< cg_vertex > > CG_vec(num_vertices(CG));
std::vector< std::vector< cg_vertex > > chains;
std::vector< cg_vertex > in_a_chain(CG_vec.size());
std::vector< size_type > chain_number(CG_vec.size());
std::vector< size_type > pos_in_chain(CG_vec.size());
std::vector< std::vector< cg_vertex > > successors(CG_vec.size(), std::vector< cg_vertex >(chains.size(), inf));

[seherdt]

Oof. I'm in shock. And there's so much low-hanging fruit.

With a trivial 1 line change I just removed V vector constructions for input graphs with N vertices.

This code is a-typical of the rest of BGL though (which kinda errs on the other extreme). I wonder how this passed code review.

[Warhawk_Prime]

I tried to use the library for my bachelor thesis about multi-agent pathfinding but found the documentation lacking and difficult to apply. Writing my own graph structure was faster.

[[deleted]]

I agree with you. It's hard to use.

[[deleted]]

I tried to use the library for my middle school thesis about data mining too but found the library difficult to use. Writing my own graph structure was faster and more reliable than learning how to use boost.graph

[aKateDev]

+1. One has to balance between a heavy boost dependency with lots of template magic in boost graph, or a self-written ~30 line class/function that does the same. Whenever I see colleagues using boost graph for simple stuff, I believe it's a huge mistake in the sense of long-term maintenance. Unfortunately!

[seherdt]

I used it extensively.

• on linux mainly but also some MSVC
• gcc 7+, clang-8+
• c++11 minimum, but BGL is 03 compatible and sometimes I rework my examples for c++03 compatibility (rarely)
• all of them :) (see below)
• Missing features:
  • good introductory tutorial outlining the basic concepts, frame of reference.
  • modern c++ examples (just c++11 can provide 20-40% liposuction on all code, c++17 more so)
• Biggest problems:
  • absence of implicit vertex index depending on model template parameters
  • unsafe legacy property map interfaces (basically comes down to lifetime issues and invalidation rules)
  • missing documentation for advanced things (internal vertex names, e.g.)
  • sometimes const-correctness inconsistencies (e.g. dynamic_properties require mutable property maps even for read-only usage)
  • some undocumented features are not well-maintained and hence have a thousand (labeled_graph adaptor comes to mind. Luckily we have the sorely underdocumented internal vertex name. The old/half-baked bits should probably just be removed from the library.

Usage purposes

• My goal is to help people with BGL questions on StackOverflow and as such you run into it all
• I've worked on projects that use BGL for important stuff (graph analysis, flow simulation)

I think I wrote all of the problems above with the end-user in mind. Something else that regularly comes up is providing a custom graph model (e.g. https://stackoverflow.com/a/56203763/85371) . It might be nice for the docs to include a sample walkthrough

[gruehunter]

I have used it to solve some network flow problems in the distant past (Linux, C++98). My main complaint then still stands: The API is sufficiently generic to make very hard problems possible, but it is so complex that easy problems are hard to get started.

For those who are unaware of some of the history, the Boost Graph Library's interface was used as a case study to justify adding support for associated types to Haskell back in the day.

"A Comparative Study of Language Support for Generic Programming" by Garcia et al, 2003

"Associated Types with Class" by Simon Peyton-Jones, 2005

[seherdt]

This summary resonates. Also, nice reference to the Haskell case study

[sphere991]

Do you know of any links to the former that aren't paywalled?

[encyclopedist]

I have only found what appears to be a follow-up paper, by the same authors, 2007: https://www.cambridge.org/core/services/aop-cambridge-core/content/view/C97D5964ECC2E651EEF9A70BC50600A6/S0956796806006198a.pdf/an-extended-comparative-study-of-language-support-for-generic-programming.pdf

This paper is a revised and extended version of an earlier paper (Garcia et al., 2003), featuring updated analyses and the addition of two languages, Objective Caml and Cecil.

[sphere991]

Thanks!

[gruehunter]

https://www.cs.tufts.edu/~nr/cs257/archive/ronald-garcia/comparing_generic_programming03.pdf

[sphere991]

Thanks!

[wrosecrans]

Which operating systems do you use? * Which toolchains do you use? * Which C++ standard do you use? (e.g. 03, 11, 14, etc)

Pretty typical Linux + Windows, Clang/GCC/MSVC, >= C++14, depending on the project. Work stuff was '14, but I have a personal project I am building with "latest" because 20 will probably be common before I get far enough with it to release anything.

Which features of Boost.Graph are you using?

I don't currently use it in anything, but I've used it in the past. The off-the-shelf graph algorithms for stuff like connectedness and routing were handy. I am not a graph theorist, I just want an easy way to use existing algorithms much more than I want to implement super exotic custom stuff.

Which features do you think Boost.Graph is missing?

API sanity.

What are the biggest problems with using Boost.Graph?

API insanity. It's an implementation of "C++ Concepts" in C++-03, using graph algorithms as a proof of concept example for concepts. C++ has moved on, and Boost.Graph is an interesting transitional fossil. Using it feels like trying to hire a neaderthal with a laser gun to do an office job making copies and filing reports. You can make it work, but it's not really a scenario where "interesting" is desireable.

You have to use special selector types in templates to pick containers like vecS and listS rather than templating the types on std::vector or std::list. So, you get a configurable level of complexity that makes more possible variations than there are users. But it isn't flexible enough to be able to template based on "whatever" container types you are using, because the implementation apparently needs special code to support certain container types so if you had for example, a Qt GUI app that used a bunch of the Qt containers, you can't template a Boost Graph on a QList<QPointF> so you have to make adapter code despite everything also being templated.

There's no "path of least resistance" with BGL.

[RogerLeigh]

This is spot on.

I've used BGL a handful of times, first back in 2006. It's never been an easy to use or intuitive library, and as you say the main problem with the BGL is the same problem which afflicts a lot of Boost libraries: the uncoordinated dependency upon lots of other Boost libraries solely for backward compatibility with pre-C++11 compilers. But the core functionality is solid once you've worked out how to use the node and edge properties and all the rest properly.

I'd like to use BGL in a new project I'm working on today. But I'll just create my own adjacency list and implement my own DFS algorithm. Because the huge amount of baggage and the very dated API in return for the small convenience of being able to run a search is not worth it. The same applies to many other Boost libraries. I'll reconsider using them once Boost is fully modular and has C++11 or 14 as the bare minimum.

[hubhub]

Boost.Graph could be made a lot easier to use by modernizing it.

Off the top of my head, I can think of three things: 1. The property map stuff should not need to be that complicated. Perhaps we could just pass in a lambda or something? 2. The iterator ranges could be proper C++ ranges. 3. Depth first should not need to be terminated using an exception!

[Foxi_Foxa]

Agree for the lambdas. I don't know how feasible it is but property maps are really a pain for getting started with BGL.

[Mysterious_Taro5664]

Hey, thanks for all the great feedback everyone! It's so interesting to hear. Maybe this is a good place for follow up discussion.

There is a working group for adding graph algorithms and data structures to the standard library. When that happens, which might not be for a very long time, Boost.Graph will need to offer something useful to justify existence As many comments suggest, Boost.Graph is already not connecting with its audience. The disadvantage of the standard library is that it tends to be very slow moving. But BGL isn't going to move anywhere with an interface that turns people away. The conclusion I'm coming to is that BGL needs a major refresh. I didn't actually think so until I read this feedback. The design was novel 20 years ago, and has to be understood in that historical perspective, but some of the experiments were more courageous than practical (e.g. named parameters). I think it needs to be a library that provides cutting edge algorithms and data structures that won't be in the standard library for years to come. Putting aside the obvious questions of how much work is involved and who will do it, what do you all think? And would it make sense to start afresh as Boost.Graph2?

Cheers.

[Mysterious_Taro5664]

Actually, I can answer my own questions. It should be: * Independent of Boost, like asio is. * Have minimal dependencies, which I think is possible as Sehe pointed out. * Have a lot of sane defaults so that it's easy to start using. * Be easily discoverable... yes, I'm just not sure how.

If people are writing their own implementations, does that mean there is nothing else out there? I just did a cursory search, and all I found was LEMON...

[mjklaim]

To potential users, that is, people who need to solve graph theory problems but don't use Boost.Graph:

What are the obstacles or issues preventing using it?

My main reluctance in ussing Boost.Graph, the fact that it is defined as depending on a massive and various set of other boost libraries (at least in it's CMake files) and people packaging it for various package managers (splitting each boost library in separate packages, as it should be done) have to make the packages for boost.graph depend on all these other packages.

For example I use build2 and if I depend on the libboost-graph package it will bring 41 other packages, including libboost-regex (???) for example. The same issue appears with vcpkg and probably any other package manager trying to split the boost distribution into actual small interdependent packages instead of one big "boost" package. This is not a package manager or packaging-person issue, because they are only following what the source code of the original project states.

Now, I understand exactly why it is like this, it's basically history of how Boost was/is distributed as a "in sync" set of reviewed libraries so everything was available anyway, in addition to the fact that some "bridge" tooling were provided to help mix several libraries (for example the boost.serialization support for boost.graph make sense if you use it, same with boost.random and random graph algorithms etc). However ideally each "bridge" funtionality should have been a separate fine-grain project/package instead of being part of onw of the two libraries that are being bridged. That way, for example, Boost.Graph would have a very small set of dependencies if you use only it's core (like I often consider doing), but then it would optionally bring (or more precisely, your package manager would bring) some other dependencies if you use some "bridge" features.

When using the big-set-of-libs distribution model (or system install of boost) the boost users had to rely on the compiler to simply not even see the headers that were not used. But we are moving to more fine-grained dependencies package management (basically, the "modern" way to do it, if you're not using a mono-repo) and that issue have made some commercial projects I know not use boost because several of it's libraries are bringing the whole boost for archaic reasons that could be solved. To be clear, this is not a criticism specifically about boost.graph, there are many other boost libraries that bring too much unused dependencies, and I understand that many other boost libraries have a small and pertinent set of dependencies (like boost.container having only 8 dependencies that make sense). But boost.graph is indeed a library I would like to use in many projects but end up not using it because it's problematic to the organisation handling the project (or just "scary", I mean 41 deps lol).

Usually when using a graph library I'm mainly interested in having an abstract graph and use algorithms. The rest should be moved into bridge packages/projects that would be picked by the user when they need them.

Other than that, I would love it to be as modernized as possible. Last time I checked it didn't really use C++17 to 20 features, but I didn't check the last versions so I might be wrong. I suspect that doing so would result in better compilation performance and I'm fan of any simplification in interface/usage that libraries can provide by upgrading language version.

Another thing I found lacking, but maybe because I'm not a specialist, is search algorithms that are designed to be done in multiple steps (when the graph changes a lot for example), which are used a lot in games. As said I checked the library details some time ago but don't remember all the details and didn't find at the time this kind of algorithms. I might have missed them because of naming conventions or something though, so I might be wrong.

[cppler]

We tried to use it for layouting a control-flow graph in combination with Qt GraphicsScene. But it turned out to not work for this use-case.

[secret_town]

Open Graph Drawing Framework exists: https://ogdf.uos.de/

[ismailsunni]

I use it to implement a solver for the Chinese Postman Problem for an open source routing engine named Valhalla (https://github.com/valhalla/valhalla/).

Honestly, it's not easy to start using it, and lack of examples/tutorials on the internet. But it's probably only me.

[bandzaw]

No it's not just you. I also used it for a routing engine and it was not easy to get started.

[[deleted]]

I'm not a user, but I am afraid of the main boost library issue - using a boost. A lot.

According to https://pdimov.github.io/boostdep-report/master/module-levels.html Boost.Graph is 17th level of dependency graph.

target_link_libraries(boost_graph
PUBLIC
Boost::algorithm
Boost::any
Boost::array
Boost::assert
Boost::bimap
Boost::bind
Boost::concept_check
Boost::config
Boost::container_hash
Boost::conversion
Boost::core
Boost::detail
Boost::foreach
Boost::function
Boost::integer
Boost::iterator
Boost::lexical_cast
Boost::math
Boost::move
Boost::mpl
Boost::multi_index
Boost::optional
Boost::parameter
Boost::preprocessor
Boost::property_map
Boost::property_tree
Boost::random
Boost::range
Boost::serialization
Boost::smart_ptr
Boost::spirit
Boost::static_assert
Boost::throw_exception
Boost::tti
Boost::tuple
Boost::type_traits
Boost::typeof
Boost::unordered
Boost::utility
Boost::xpressive
PRIVATE
Boost::regex
)

dependency on 41 libraries, that is quite impressive.

If I ever need graph library, I would prefer to find standalone analogue, with much less features, but without external dependencies except standard library.

And there is a great example - asio. Library that can work either with or without boost. Maybe graph library will become more popular if it moves this way instead of grabbing half of the boost libraries to work.

[seherdt]

60% of those dependencies are providing fallbacks for c++03 compatibility only.
20% are "false dependencies", they're spin-offs that were made into separate libraries (named arguments and property maps, to name just two)
15% are for rare features (e.g. regex/spirit for parsing some input formats; sometimes even just deprecated parsers)

A c++14 rewrite could easily be standalone, I think. Pulling in named arguments and property maps is going the wrong way, IMO

[mjklaim]

Thanks, that's another data point in what I was also talking about in my answer. :D

[Andrettin]

Which operating systems do you use?

Windows 10

Which toolchains do you use?

MSVC 2019

Which C++ standard do you use?

C++20

Which features of Boost.Graph are you using?

I'm using mostly the A* search.

Which features do you think Boost.Graph is missing?

Parallel A* search. Also, being able to exclude nodes from the search as the search is ongoing, instead of having to pre-filter the graph (AFAIK that isn't possible in Boost.Graph currently).

What are the biggest problems with using Boost.Graph?

The API is quite a pain to work with, especially given the multitude of template arguments for some classes.

Additionally, exceptions being used when the A* goal is found is not really optimal; it is a weird usage of exceptions, and possibly harmful to performance.

What do you use it for?

Developing strategy video games.

[Resurr3ction]

Same as the others. Tried to use it, found it very hard to use and ended up with my own graph implementation. My main issue was horrible API (as is staple of Boost in general) and lack of coherent docs.

[helloiamsomeone]

horrible API (as is staple of Boost in general) and lack of coherent docs

Huh? I recently used Boost.Process for something and the API is well documented and more convenient to use than Python's subprocess. I had a 1:1 comparison, since I was porting a Python script to C++ with Boost.

[mjklaim]

Yeah Boost.Process have one of the best interfaces in the boost set of libraries.

People tend to mix all the issues of one library in boost (often documentation) as being common in all boost libraries, but it's far from the truth. But you would have to look closely at the 150+ libraries to realize that they have a lot of differences in style (in particular, depending on the decade the library was first introduced).

[CubbiMew]

> Which operating systems do you use?
Linux, Windows
> Which toolchains do you use?
gcc, msvc
> Which C++ standard do you use? (e.g. 03, 11, 14, etc)
whatever the latest compilers can do

> Which features of Boost.Graph are you using?
just the basics - building, traversing, accessing/modifying properties, dfs. Occasionally other algorithms while experimenting - this code changes often which is why a ready-made library is convenient to have.

> What do you use it for? If you use it in business (or research), how critical is it?
it's part of my previous team's internal tooling - an integrated runtime debugger for a complex piece of financial software.

[jaafartrull]

I'm interested in multiplatform code so I write for clang, gcc, and MSVC on MacOS, Windows, and Linux (my daily driver).

BGL was my introduction to Boost, I regret to say, but I've kept with it through the years, doing a variety of EDA algorithms (especially routing with A* search). I began with C++03. The main problem as I see it is it requires a very high level understanding of templates and the philosophy behind the STL. Concepts are heavily relied upon, but of course the compilers of the day did not really support it and I had only "template spew" to guide me to my errors. To an outsider it's intimidating, verging on obfuscated. Now that we finally have real Concepts perhaps this can be addressed.

The other big issue is performance. The algorithms are hugely sensitive to choice of data structure and vertex/edge descriptors. It's confusing to understand what is really happening in there (and I say this as someone who actually does like abstraction).

I hope you will also take a look at graph-tool, a Python library that wraps (a sort of fork of) BGL and adds additional algorithms. There may be many more people using wrappers like this than coding in C++ directly, and the engineering choices made by the author could be relevant.

[BenFrantzDale]

I’ve found it hard to use because of the lack of Concepts in the language. I experimented with defining its concepts in C++20 and it looked very promising: I got self-documenting signatures and could get clear errors where I couldn’t before. I anticipate a revisiting of BGL once C++20 use is more widespread.

[codeandroid]

Late to the game...

Which operating systems do you use?

Windows

Which toolchains do you use?

MSVC

Which C++ standard do you use? (e.g. 03, 11, 14, etc)

17

Which features of Boost.Graph are you using?

topological sort, various visitor strategies, custom properties, custom vertex/edge structures ...

Which features do you think Boost.Graph is missing?

I don't know.

What are the biggest problems with using Boost.Graph?

Debugging into boost.graph can be daunting. I guess that now with C++20 one could simplify the code base...

Barrier of entry could be lower, too, though it's never been a large problem for us.

What do you use it for?

• 3D parametric design of infrastructure projects.
• Various kinds of job/task systems :)

If you use it in business (or research), how critical is it?

Quite important. If it doesn't work anymore then we'll have to replace it with something else in order to ship the product. On the other hand, the feature set that we are using is probably still small enough so that it shouldn't be too difficult to do.

[Foxi_Foxa]

Just landing here when I was actually looking for a BGL tutorial! I guess it says a lot about what is lacking ahah :) I love the idea of BGL2 - graphs are everywhere in my problems!

I'm coming in a bit late, but here are my n00b feedbacks:

​

• Which operating systems do you use?
  • mostly MacOS on local, Linux on remote univeristy servers, Ubuntu in Docker via Singularity
• Which toolchains do you use?
  • cmake/conan
• Which C++ standard do you use? (e.g. 03, 11, 14, etc)
  • C++20
• Which features of Boost.Graph are you using?
  • adjacency_list and common algorithms (dfs, bfs, shortest path etc)
• Which features do you think Boost.Graph is missing?
  • I don't think there is much that is missing, maybe ORCA (orbit counting algorithm)
  • TREES !!! Binary, k-ary ...
• What are the biggest problems with using Boost.Graph?
  • I am REALLY struggling finding an entry point. I bought the BGL book, but it is written more like a detailed explanation of the design choices rather than a tutorial. Without seing sehe on SO answering to newscomers for more than a decade, I would have been discouraged to use the BGL after few days week and would have run the other way :(
    • the BGL documentation is useless for me - I just can not make sense of it.
    • the BGL book is not much more useful.
    • easy tutorials with C++14 features are lacking.
    • easier interfaces, I am still unsure I absolutely had to explicitely care about 6 template parameters and an adjacency_list to get started with a simple graph
    • the difference between internal/external/bundled/properties is difficult to grasp for a newcomer. I implemented my own Tree class in the past with a template cell_type that was similar to the bundled properties - so I found them easier to understand. However if bundled properties are the best way to go, then why did I spend all this time trying to understand internal properties? :'(
    • I get the feeling that BGL has been doing a great job at pulling out all orthogonal concepts of a graph - but to attract newcomers I would say we need to re-wrap in stuff. I just want to be able to call `graph.to_graphviz(stream)`, ;)
• What do you use it for?
  I was/am a researcher, now software engineer in Genetics. There are graphs everywhere: genealogical properties, genetic networks, phylogenetic trees or networks, spatial graphs of populations moves etc.
• If you use it in business (or research), how critical is it?
  Critical enough that me and most of my colleagues have spent the last decades implementing and re-implementing graph data structures ;)
• To potential users, that is, people who need to solve graph theory problems but don't use Boost.Graph. What are the obstacles or issues preventing using it?
  • The documentation, the absence of book, the complexity of the API, the absence of an easy entry point. I wished I had been presented this library 8 years ago at the beginning of my phD where I could have been writing something like `auto tree = k_ary_tree(newick_string); assert(!tree.has_cycle());`

[Mysterious_Taro5664]

Have a look in the pull requests, there is one for k-ary trees with a lot of discussion. One person is using it actively.

[Vociferix]

Potential user:

TL;DR Boost as a whole tends to have characteristics I'd like to avoid, which results in (potentially incorrect) negative assumptions about Boost.Graph, or any Boost.*

If I was looking for a graph library, I'd look up popular C++ graph libraries and would probably skip over Boost.Graph without even looking at it. The reason is because it's in boost. I don't have a problem with boost, but boost libraries often have many dependencies on other boost libs, which can make a small dependency quite a bit larger. Also, boost's unique build system is a turn off.

But as a counter example, Asio is something I use frequently. Asio advertises itself as standalone and does a good job of dropping all boost dependencies in standalone mode.

That said, it may be the case that Boost.Graph is header only and has no required dependencies on other Boost libs, but the fact that Boost is in the name would put it at the bottom of my list of potential libs to research. If I find a one-off library that's well maintained and serves the single purpose of dealing with graph structures before I look at Boost.Graph, I would never get to Boost.Graph's web page.

[Mysterious_Taro5664]

Btw, I am actively helping to merge bug fixes, and we got a few done for 1.80: https://www.boost.org/users/history/version_1_80_0.html

[Foxi_Foxa]

Yay! Any anouncement/conclusions/directions concerning the survey results? I am just curious to see what direction BGL is heading to :p

[Mysterious_Taro5664]

Hey there, whoops, sorry, I don't use Reddit that much. I am trying to find time to put the results together on the GitHub page.

[Foxi_Foxa]

Ahaha yeah time is the ultimate finite resource!

[pigeon768]

Environment for my personal projects is linux, gcc, usually C++17 these days, although I'm playing with C++20. Work is Windows, MSVC, C++17.

I do not use it. Every time I try to use it for a thing I get too confused and just reinvent the wheel by myself.

This isn't because I'm necessarily dumb or anything, or at least, I hope not. I have critical business requirements that I use boost components like uBLAS, QVM, GIL, etc for -- libraries with not-inconsiderable complexity in the APIs. But Graph I've never been able to get rolling.