On Monday, February 2, 2026, Jason McKesson wrote:

>
> The question of whether `substr` should be a `const` function is a
> "yes/no" question. One of those answers is correct. Your code uses the
> other answer.
>


I pondered for a moment when writing that function whether 'substr' should
be const or not.

At first I was thinking it would be good if a TermString would never be
const, as though we were able to write a constructor as follows:

   MyClass::MyClass(void) const(false) { . . . }

As TermString is non-owning, really all of its members can be const (and
they are). But then I though hmmmm... maybe a non-const TermString can
alter the referred buffer, and a const TermString cannot alter the referred
buffer. Given that substr can return an object that can be used to alter
the underlying buffer, I figured make it non-const. I hadn't put a huge
deal of thought into it though.

By the way I realise the destructor of a const TermString can alter the
buffer but really it's only restoring it back to the way it was.

When I decide to mark a member function as either const or non-const, I
take into account more than just the editing of the member variables, I
also consider a few other things.

Anyway we are in disagreement Jason about whether my TermString class is
really a bad idea. So long as only one thread is using the referred buffer,
it's perfectly fine to pluck the null terminator and move it around for a
moment, then put it back where it was. I would definitely use this strategy
to optimise a program that extensively uses long null-terminated strings
that frequently need to be substr'ed.