StringBuf niceties

[stellar-aria]

Pared down from #3196 after having it pointed out to me by @sapphire-arches that alloca would not do what I wanted the way I was using it...

[github-actions]

Test Results

106 tests  ±0   106 ✅ ±0   0s ⏱️ ±0s
 16 suites ±0     0 💤 ±0 
 16 files   ±0     0 ❌ ±0 

Results for commit 1c47d5a. ± Comparison against base commit 598cd8e.

[nikodemus]

Why both? All the std stuff tends to .size() and the deluge specials tend to .getLength() or .getNumWhatevs(), so .lenght() seems a bit inconsistent?

Not asking changes, just wondering.

[stellar-aria]

it's conformance to the string interface, which has length() because of strlen and size() to act as a standard container

[nikodemus]

Pared down from #3196 after having it pointed out to me by @sapphire-arches that alloca would not do what I wanted the way I was using it...

I wonder, if we had something like:

class StackStringBase {
    virtual char* buf() = 0;
    virtual size_t capacitu() = 0;
    ...
}:

template <int SZ>
class StackString final : public StackStringBase {
protected:
    inline char* buf() final { return buf_; }
    inline size_t capacity() final { return SZ; }
private:
    char buf_[SZ];
};

How much extra crap per allocated size would we get? Could we force the size to a power of 2 to keep tha down to something sensible?

[stellar-aria]

in-line definitions are always inline linkage, but we may get some benefit from making them constexpr if possible. I don't think there are constexpr definitions of the c-string stuff, but there are for std::string_view. there may be some benefit to rewriting these as constexpr since then the compiler could reason about and catch out-of-bounds errors at compile time