Remove strprintf printing for {fmt}.

[thorstenhater]

Use libfmt in more place.

[brenthuisman]

Is the remainder still used anywhere? It is difficult to kill that usage too?

[brenthuisman]

Tests I see, for to_string. What's wrong with std::to_string()?

[thorstenhater]

Glad you asked :D. util::to_string uses ADL (=argument dependent lookup) to select
to_string if present in namespace global or arb. If not it'll try to use << via std::stringstream.
std::to_string does not. This is why many classes in Arbor produce a friend << but do not
specialise to_string.

[brenthuisman]

Hmm, this is all a bit implicit. We should document that, for instance, all Arbor objects implement a public operator<< (as per #952). Maybe operator<< isn't really what we want, I suppose often you want to have the string output, so we could say that all Arbor objects also implement as_string() and that it has the same output as operator<<. What do you think?

[thorstenhater]

I just learned that bit, so yes, a bit hidden. We can add something like this to our devdocs:

Arbor classes should implement << for debugging and user interface purposes.

Should be a should since it might never be needed and can be retrofitted easily.
I'd separate both concerns from this PR though, which is purely swapping out the substrate.

Regarding stream ./. strings:

• Strings do allocate memory (repeatedly!), thus recursively stringifiing classes leads to potentially bad blowup, while streaming data out just needs a subset of the memory.
• The memory concern will be especially bad for arrays/containers.
• Streams have the issue of indirection via stringstream which util::to_string packages for you.

So, despite the slight convenience, I prefer the << way.

[brenthuisman]

Adding that line to docs would be good.

I meant a potential as_string() in addition to operator<< for the reasons you list.

util::to_string isn't great, because it's not quite the same as std::to_string (meant for numeric values only), so a bit confusing.

[thorstenhater]

So, if the output should (MUST!) be the same, we end up with as_string(t) = (stringstream{} << t).str()
which is what util::to_string does anyhow. Also util::to_string falls back to std::to_string where
available (hence the ADL dance). See here

https://gcc.godbolt.org/z/r8KMEzYcj

• Alice provides to_string and <<
• Bob has just <<
• double has std::to_string.

Thus, everybody will just be repeating util::to_string anyhow.

[brenthuisman]

Sometimes inheritance from a base class is nice.

/ducks

[thorstenhater]

Yeeees .... but (std::)to_string is standalone function and not a member or class.

[brenthuisman]

Yeeees ... but .print() could just be an inherited method containing the string construction from << once and for all, without the separate-but-not-really function in util.

[brenthuisman]

OK

[thorstenhater]

Nice that you like this, but this is really not nearly done.

[brenthuisman]

Then mark it draft, I thought we had agreed to do that?

[thorstenhater]

Closing as it diverged too much!