using namespace linalg::ostream_overloads sometimes does not work.

[mirmik]

using namespace linalg::ostream_overloads sometimes does not work as planed.
For example doctest library(https://github.com/onqtam/doctest) does not found operator defined like this.

It might be a good idea to change it in the documentation for this way:

#include "linalg.h"
namespace linalg { using linalg::ostream_overloads::operator <<; }

It works better because c++ adl mechanism lookup function in argument`s namespaces first. So, in other places it can ignore overloaded operator for various reasons.

(In fact, it's not entirely clear to me why the overloads are generally hidden. )

Thanks for your work.

[sgorsten]

w.r.t. why the operators are hidden:

linalg.h was born because I and five-ish of my peers were all in the habit of writing some sort of new "vecmath.h" type header for every project we started, and they were usually about ~80% compatible with one another by default, but just different enough to make code sharing hard. I wanted to see if I could come up with something that would be good enough that we'd all just use it and stop bikeshedding, and it kinda worked for that purpose.

In a few of these codebases, cout << float3{1,2,3} would print something like <1,2,3> or (1 2 3), etc., and I settled on {1,2,3} as a halfways decent pretty-print, because it prints the same text that would be required to initialize the float3 via an expression of literals in your source code.

However, a few of these codebases defined cout << float3{1,2,3} to print 1 2 3, with an equivalent cin >> v that allowed you to use the ostream/istream overloads for extremely basic serialization to and from text files (you can kinda half-ass an OBJ loader this way, for instance).

I wanted to permit users to define their own overloads in the global namespace if they had a preference, but still provide an easy alternative that they could opt into if they wanted. This required placing my versions of the overloads in a different namespace than linalg, so that you could bring them into scope manually but they wouldn't bind tighter than something a user had defined themselves.

As you've discovered, this was not a particularly excellent design choice, and the ostream operator breaks frequently enough that I've seen a number of users just give up and define their own overloads in their respective namespaces.

I don't have much time to maintain this library these days, but I might tweak the documentation over the weekend to recommend your fix.