Encode strings as base64
#include "ToBase64.h" // string, experimental/string_view


Best practice in C and C++ is to "#include what you use" in every file. Admittedly, in this case there is no possible way someone could refactor "ToBase64.h" to omit one of those headers, because both of those types are used in the signature of the single function that is the raison d'etre of the header. But still — I'd list #include &lt;string&gt; and #include &lt;std/experimental/string_view&gt; in "ToBase64.cc" as well as in "ToBase64.h".



using std::length_error; // stdexcept
using std::string; // string
using std::experimental::string_view; // experimental/string_view
using std::uint8_t; // cinttypes


In general, using declarations are frowned upon; although again in this case it's harmless. using declarations in header files are the really bad thing. In "ToBase64.cc", you could just as well get away with

using namespace std;


so I'm not sure why you're spending four lines to say basically the same thing. (And the comments aren't adding anything. Kill them.)



string to_base64(const string_view input)


I'm not sure what the best practice is with string_view: take it by value or by const reference? I'll assume by value is fine, since the whole point of string_view is that it's cheap to copy. But in general, taking things by const value is weird. It doesn't change the function's signature — i.e.

string to_base64(const string_view input);
string to_base64(string_view input);


redeclare the same function — so generally we'd like to omit the redundant const.

Man, so far I've commented on every single line of the code "well, this line is weird, but I guess it's harmless in this context..." ;p  Don't worry, the line after this one looks great!



static constexpr smells redundant; is it actually any different from constexpr?



The expression len &gt; output.max_size() / 4 * 3 - 4 has too many operators in too unfamiliar an order for my puny brain. I guess you're saying "suppose I base64-decoded a 0xffffffff-character string... how many characters would the decoding have? If the given plaintext has more characters than that, then let's report that the encoding failed. Except minus four for some reason."

In practice, std::string::max_size() will be on the order of 2^63 or 2^64 — so astronomically large that your algebraic expression is physically incapable of ever being false. (Logically capable, yes. Physically capable, no; no computer in the world will ever have that much memory, or enough time to initialize it if it did.) So I'd say it's better to keep the code simple and omit that check. As a bonus, this lets you kill off the temporary variable len.

If your machine is actually running out of memory, the output.reserve on the next line will throw bad_alloc anyway.

Just kidding — it'll return successfully and then you'll get oomkilled at random, later.



auto remainder{ 0 };
uint8_t leftover{ 0 };


This seems fine to me, but I'm surprised that you're following neither the "Almost Always Auto zealot" pattern of

auto remainder = 0;
auto leftover = uint8_t(0);


nor the "I'm a normal person" pattern of

int remainder = 0;
uint8_t leftover = 0;


I guess your pattern is the one that allows the most use of Uniform Initialization, though.



switch ((remainder %= 3)++)


Please don't.



output += "==";
// ...
output += '=';


This is correct, but strikes me as a refactoring typo waiting to happen. In Python, Javascript, Perl, Bash, etc., string literals can be delimited with either ' or "; but in C++, "==" is a string and '==' is a multi-character character constant with implementation-defined value (15677 on all sane platforms).

output += "==\n";
// ...
output += '=\n';  // oops


Admittedly the above code generates two warnings on both GCC and Clang, and it's a hugely unlikely refactoring anyway; but still, if this were my code, I'd use "double quotes" in both cases.



Other than all these nitpicks, it looks very clean and certainly correct!