<div dir="ltr"><div>Hello everyone,<br>I had this idea and I think you may be interested in it, so I decided to sign up in the mailing discussion and send this mail.<br><br>The idea is to make a collection of generalized functions for geometry (and possibly cartography) algorithms; trying to detach the algorithms from the data structure.<br>I know it can be hard to imagine so I did this very trivial example:<br><br>inline constexpr auto supernaive_add_points(auto&& pointA, auto&& pointB) {<br>    return pointA + pointB;<br>}<br><br>This is probably the most naive approach. This will require the points to have the operator+ overloaded. In this theoretical case, whoever did the operator+ would had actually done all the work. So an actual addition could look something like this:<br><br>template<typename Point><br>inline constexpr Point naive_add_points(auto&& pointA, auto&& pointB) {<br>    // Both points actually need the x() and y() getter; otherwise an error will be thrown by the compiler (this are parts of the requirements to execute this function).<br>    // The x and y types are deduced automatically so they may be a float, an integer or even a custom type with overridden operator+. x and y may actually have different types.<br>    auto x = pointA.x() + pointB.x();<br>    auto y = pointA.y() + pointB.y();<br><br>    // We make the object resulting of the addition and return it. If there isn't an exact mach C++ will try to find an alternative.<br>    return Point(x, y);<br>}<br><br>This function requires both points to have the getters `x()` and `y()`, and Point to have a constructor compatible with the returned types. This is a little bit more mature but still very naive since the return type is a template argument. In reality, you would try to deduce its return type with some template tricks.<br><br>It would be possible to use any data structure as long as your class has the functions requirements. It would NOT use an interface (or in C++ terms, a pure virtual class) to get the functions; this would allow the developers to use any class that already met the requirements.<br><br>So let me list all the pros, cons and things to keep in mind that I can came up with about this approach:<br><br>Pros:<br> - 0 overhead approach.<br> - Very portable between projects.<br> - Separates algorithm from data structure.<br> - If you don't use an algorithm, it won't exist in your binary (because it uses templates and/or auto, it is not fully defined until it's called).<br> - Can have multiple implementations simultaneously and let the developer choose the best one for their needs.<br> - Everyone can add a new algorithm or implementation.<br> - Adding a new algorithm or implementation will not break all the existing code nor any project using it.<br> - It would be really easy to add a new algorithm or implementation, and it wouldn't break any code.<br> - Requires modern C++.<br><br>Cons:<br> - Required modern C++.<br> - Need to rewrite code.<br> - It cannot be exported to a dynamic library by itself: you'll need a data structure and a C binding.<br> - Developers must know the difference between implementations.<br> - Documentation has to be really clear to prevent misunderstandings, specially each implementation's requirements.<br> - May need to rewrite an implementation changing just a little part.<br><br>To keep in mind:<br> - Requiring modern C++ have its own pros and cons. With C++11 would be enough but later versions can have more features.<br> - You need to be consistent with the requirements (to be as useful as possible).<br> - You can use perfect forwarding in the C bound functions to call your functions (to make a dynamic library).<br> - Having a "main" function that defaults to an implementation could help the developers to choose one.<br> - Anyone can copy an algorithm implementation without the need to make changes, without adding the entire project as dependency.<br><br>Thank you for reading,<br>Martí Angelats i Ribera<br><br></div>PS: This mail ended up being a longer mail than I initially expected. Sorry for that.<br></div>