Feedback submissions from the Boost User mailing list

Boris Kolpackov

• What are the biggest problems with using Boost.Graph?

While I don't use Boost.Graph myself, I've observed on several occasions the "surprise" (to put it politely) that build2 users express at the fact that Boost.Graph depends on Boost.Regex (which in turn pulls in heavy- weight stuff like ICU). While there might be valid reasons why a graph library would require regex, you may wan to consider at least making this dependency optional.

---

Anne van de Graaf

Hi Jeremy,

Please find below my response to your user survey. I hope you will find this helpful.

Dear Boost.Graph users,

I'd like to know how you use Boost.Graph. If you know someone that uses Boost.Graph but is not on this mailing list, please forward this survey to them. The purpose of this survey is to help prioritize work on the areas of Boost.Graph that will have the most benefit to the 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?

RHEL 8 and Windows 10/11.

• Which toolchains do you use?

To build our software we use Microsoft’s Visual Studio on Windows and the Intel compiler on Linux. Occasionally, we also build it using Clang and GCC with the intent to detect problems that are not reported by the Intel compiler. Furthermore, we use CMake as our build system generator and CLion as our primary IDE.

• What is the minimum C++ standard that you require support for? (e.g. 03, 11, 14, etc)

---

At present we are using C++17 in production, but so far we haven’t had any difficulties with the standard that is currently being used by Boost.Graph (03?)

Which features of Boost.Graph are you using?

It is mostly basic operations: DFS, BFS, connected components and so on. Nothing fancy here.

• Which features do you think Boost.Graph is missing?

For how we use Boost.Graph now, what is provided is sufficient.

• What are the biggest problems with using Boost.Graph?

We find the documentation not particularly easy to read or search. In particular for users who haven’t used Boost.Graph before, we would say the learning curve is quite steep.

Purely out of curiosity:

• What do you use it for?

We have several usages for it. For instance, we have a graph to keep track of collision detection results (in terms of model parts that clash). We sometimes also use it to capture the boundary representation (B-rep) of model parts (in terms of bodies, shells, loops, faces, edges, … and how these relate to each other).

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

Since we use it in some core components (e.g. collision detection), it is quite critical to us.

Thanks!

Jeremy

---

Keith Bennett

OS: Linux, Android Toolchains: GCC primarily, sometimes LLVM Minimum standard: C++14 Features used: astar_search.hpp Features missing: parallel capabilities, eg for SIMD or threading

Biggest problems: astar_search() takes too much time to initialize all vertices (in a 2048x2048x40 matrix) even though we only need to initialize vertices when they are added to the open set. We ensure our data's initialization state is identical to a default-constructed object, then guarantee that the vertex initialization is done when the vertex is first added to the open set, and of course A* ensures that vertices aren't used until they're added to the open set (eg, when they're first discovered). To make resizing containers quicker, we ensure that our default-constructed objects are trivially-constructible so that resizing the underlying containers to match the matrix size does not require invoking expensive constructors which effectively reduces the initialization requirements to just resizing the containers correctly and setting the non-zero start-point state and end-point state.

Use case: DroneUp uses the graph library, coupled with types from boost geometry, to find flight paths for drones. Criticality: The graph library is not a critical component. A-star search algorithms are well studied and we could write our own implementation if necessary.