The depth of recursion is controlled at compile time. The runtime calls
are presumably optimized away by inlining. You would have to look at the
generated code and/or run some tests to see if there is any abstraction
penalty.

In any case, that is an implementation detail, as indicated by being in
namespace detail. It can be replaced with something else if need be.

> More importantly, is it intentional that stream input
> and output only consider ostream and istream (no wide versions, no
> templates, etc.)?

Yep, that needs to be fixed. I suspect the current version reflects
compiler problems cica 1999. I've added a "TODO" comment to the code in
case so it won't be forgotten in case I don't get to it right away.

> * (minor) the example omits fclose()

It was omitted for brevity. I've now added it.

> * though the Wikipedia article seems to be, at the time I'm writing,
> in a decent state, it might easily degrade in the future (I've
> experience this myself; no ranting :)); OTOH we can't include it into
> the boost files, due to the Wikipedia license. It might be worth
> writing something ourselves, at least in the long run, or link to a
> specific version of it, with a word of caution that any newer versions
> have not been verified by the boost members.

Yes, reference to the Wikipedia in docs is something we need to discuss.
The articles are often extremely well written and authoritative, and it
save a lot of work (and then later maintenance) to link to them. But as
you say, we have no way to know if an article might degrade in the future.

My current feeling is that the advantages of linking to a well-written
Wikipedia entry outweigh the disadvantages, but it is an open question
that other Boosters need to think about.