# Boost Geometry LOL

Warning! Some information on this page is older than 5 years now. I keep it for reference, but it probably doesn't reflect my current knowledge and beliefs.

# Boost Geometry LOL

Tue
06
May 2014

Many programmers I follow on Twitter made fun recently of this page: Boost Geometry - Design Rationale. I agree with them - it's ridiculous how sophisticated a simple geometric distance function can become if you want to make it generic using C++ metaprogramming. There are many developers who like such tricks, but I'm not one of them.

Of course I know and appreciate that C++ is so powerful you can write such generic code and that all the complexity is solved in compile time so run-time performance is good and not affected by this. But on the other hand, generic programming in C++ has its flaws: it's hard to learn, the code is long and complex, hard to write, debug, read and understand. When you make a mistake, error messages are cryptic, which is inevitable with so many levels of indirection.

So here is what I thought about this: If all these traits and other helper, boilerplate code was not needed and if compile-time metaprogramming was imperative and iteration-based like the main language itself, not functional and recursion-based, then a dimension-agnostic distance function could look like as simple as this:

`struct vec2 { float x, y; }struct vec3 { float x, y, z };declare components of vec2 as { x, y };declare components of vec3 as { x, y, z };float distance(a, b){    float dist = 0;    foreach(c in a.components)        dist += (b.c - a.c) * (b.c - a.c);    return sqrt(dist);}`

But because it doesn't, I will stick with 2D, 3D and 4D vectors of floats :)