Areas of concern

Have I missed some important technical requirement when inheriting std::streambuf and std::ostream?

This is not the correct way to go about creating a custom stream.

I can’t even begin to guess what kind of problems you’ll run into dual-inheriting from both std::streambuf and std::ostream, because it’s just such a bizarre idea. Certainly, a lot of things will be very weird.

The correct way to “do something custom” with streamed data is to create a custom stream buffer (and then, optionally, a new stream type that uses that stream buffer by default). Streams are really just thin wrappers around stream buffers. Streams are the formatting layer; stream buffers are where the business happens (even if the business, in your case, is just counting). You are not changing the way formatting is done (you want the formatting to be done normally, and then you want to count the characters that result), therefore you shouldn’t be doing anything in the stream layer.

You don’t even really need to create a new stream type at all, because you can just use the buffer in an extant stream. But making a custom stream makes things more ergonomic.

So you should have something like this:

class counting_streambuf final : public std::streambuf { auto overflow(int_type ci = traits_type::eof()) -> int_type override { ++count; return traits_type::not_eof(ci); } public: // For practical purposes, you're going to want streams and stream buffers // to be movable and swappable. So that means you need the move // constructor, move assignment operator, and swap. counting_streambuf() = default; counting_streambuf(counting_streambuf&&) = default; auto operator=(counting_streambuf&&) -> counting_streambuf& = default; auto swap(counting_streambuf& rhs) -> void { std::streambuf::swap(rhs); std::ranges::swap(count, rhs.count); } std::size_t count = 0; }; // You don't *need* this stream class. You could just do: // auto buf = counting_streambuf{}; // auto os = std::ostream{&buf}; // os << "foo"; // std::cout << buf.count; // should print 3 // // But the stream class is much nicer: // auto os = counting_ostream{}; // os << "foo"; // std::cout << os.count(); // should print 3 class counting_ostream : public std::ostream { counting_streambuf _buf; public: // As with the stream buffer, you want the stream to be movable and // swappable. // // Unfortunately, we can't default the constructors, because we need to // make sure the address of the buffer is passed to the base class. counting_ostream() : std::ostream{&_buf} {} counting_ostream(counting_ostream&& rhs) : std::ostream{std::move(rhs)}, _buf{std::move(rhs._buf)} { set_rdbuf(&_buf); } auto operator=(counting_ostream&& rhs) -> counting_ostream& = default; auto swap(counting_ostream& rhs) -> void { std::ostream::swap(rhs); _buf.swap(rhs._buf); } // Defining this is a tactical choice to block access to // std::ios_base::rdbuf()... both overloads. // Note we can't use "override" because we're changing the return type. // // We don't *need* to do this, but by doing it we make it harder to // replace the buffer, and we have it return a correctly-typed pointer. auto rdbuf() const -> counting_streambuf* { return const_cast<counting_streambuf*>(&_buf); } auto count() const noexcept { return _buf.count; } }; 

Should there be additional constructors?

I don’t see why.

std::ostringstream has constructors for:

1. Setting the mode. But that’s irrelevant for your use case. Your only “mode” is output. Appending versus truncating is meaningless. Seeking is meaningless. Binary versus text is also meaningless.
2. Setting the initial text content. Again, irrelevant for your use case.

Are there unforeseen issues, including potential performance problems, in overriding overflow this way?

This works (as your tests show), but it is going to be wildly inefficient in practice.

Suppose I have a few thousand characters of data that I want to write to this stream. The natural way would be to do os.write(data, size). This will work just fine… but consider how it works. Each single character of those thousands of characters will be counted… one… at… a… time.

And, each character will trigger multiple virtual calls to be counted. You can take some steps to make this less excruciating. For example, you could make the stream buffer final, so that the calls should be de-virtualized in the stream. Still, you are counting each character one-by-one.

But… you were literally told how many characters are in the data. It was right there in the call: os.write(data, size).

Consider also overriding .xsputn(). The standard allows you to not call .overflow() for each character, so you could just add the new count to the existing count and be done with it. That way, instead of thousands upon thousands of calls to .overflow(), each incrementing the count by one, you can do it all in one fell swoop.

My class is a streambuf, albeit privately, in addition to being an ostream. That raises the potential for ambiguities that would not be encountered when using some other ostream derived class.

That’s an understatement.

Keeping the stream buffer base private probably protects against most problems… but whenever you have the choice composition is much better than private inheritance. In this case, there is literally no benefit to private inheritance.

It is my understanding that a std::ofstream opened in text mode on Windows will turn LF into CRLF and hence would produce a longer file than this counter reports. For now at least, that's fine.

Okay, but for the record, you are massively underestimating the complexity here.

For starters, if your ultimate goal is to estimate the size of a file after a bunch of stuff is streamed into it… this ain’t gonna work. You’ve already identified that the way Windows transforms newlines is one problem… but you know, that’s not the only translation Windows does in text mode. So even if you checked for newlines and added one for each… your count could still be wrong. And that’s just on Windows. Other platforms may have other nasty surprises up that alley.

But there’s more.

Because you’re also not taking the locale into account, nor the character traits. It is quite possible for someone to imbue a locale with a character transformation. In that situation, simply counting the characters you’re given won’t suffice. You’d have to do a codecvt transformation first, and count the result.

My machine’s locale is en_CA.utf8; Canadian English, UTF-8. But someone else’s might be ja_JP.SJIS. When writing the same string to files in each locale, you might end up with very different results, including different sizes.

There is no way to solve all of these issues. The only portable solution is to straight-up write the file, then query its size (but even that is fraught, for various complex reasons).

So if that’s your end goal… you ain’t gonna get there.

If all you want is to just count the number of characters conceptually put into a buffer after formatting… then sure, this will work. If you want the count after the transformations done by a particular buffer (like std::filebuf)… then no, that’s impossible (unless the buffer helpfully gives you that information, or puts the result somewhere where you can then count after the fact… like std::filebuf does by putting it in a file that you can then inspect).

Comments on code

#include <cstddef> // size_t 

That’s std::size_t. The std:: is not optional.

Naked size_t “works” on most platforms for historical reasons. But that will very likely change in the near future, as modules become the norm.

 virtual std::streambuf::int_type overflow( std::streambuf::int_type c) override 

Use either virtual or override… not both.

I’m not going to bother critiquing the test code because… well, it’s test code. But I will say that you should use a proper testing library, rather than trying to roll your own.