Inheriting from basic_iostream and streambuf

Hello!

I am writing a library for an embedded system where I want to provide the user with an std::basic_iostream interface to some peripheral (let's say an UART).

The straightforward way to do this is to derive from std::streambuf, and wrap it with a std::basic_iostream.

The problem is I also want to provide an asynchronous IO interface, which basic_iostream doesn't support, and the user can no longer (easily) get to my class with the basic_iostream wrapper.

How would you design this?

I can have my class inherit from both iostream and streambuf, and pass "this" as the streambuf to iostream ctor, but that feels dirty...

Thanks

Can you show some example code?

It is not normally advised to inherit from the iostream class. The istream and ostream classes are really not designed to be a base class. See this link for a little more information.

By the way your example (an UART) does not usually require an asynchronous input stream. Realize that UART stands for Universal Asynchronous Receiver-Transmitter.

Quote:

---

Originally Posted by jimblumberg

It is not normally advised to inherit from the iostream class.

---

He's saying he wants to inherit from basic_streambuf and then "wrap" that in a basic_iostream by passing his streambuf object to basic_iostream's constructor. I'm assuming a little, though, but that's all that makes sense.

Quote:

---

Can you show some example code?

---

I am still in the early planning stages so unfortunately not.

Quote:

---

Originally Posted by jimblumberg

It is not normally advised to inherit from the iostream class. The istream and ostream classes are really not designed to be a base class. See this link for a little more information.

By the way your example (an UART) does not usually require an asynchronous input stream. Realize that UART stands for Universal Asynchronous Receiver-Transmitter.

---

Yeah, it's looking like providing a streambuf for the user to wrap in her own iostream is a better way to go.

By async IO I mean the user needs to be able to check that some data is available in either the iostream buffer or streambuf buffer (in this case, UART receive FIFO) before reading, so reads don't block. Though I just found readsome() in istream, which, although very basic, should support my use case. I should probably just implement streambuf then.

As it turned out, I still had to derive from both streambuf and iostream, because readsome() is the only non-blocking call supported by the iostream interface, and it's seriously inadequate. There really needs to be something like readsome() but doesn't extract data. streambuf even provides in_avail(). Not sure why iostream doesn't expose that.

The class ended up being something like this:

Code:

---

class MySerial : public std::iostream, public std::streambuf {
 public:
  MySerial() : std::iostream(this) {}

 protected:
  // overriding functions for streambuf
}

---

It seems to be working perfectly fine, and I can provide my own non-blocking interface alongside.

Quote:

---

Originally Posted by cyberfish

As it turned out, I still had to derive from both streambuf and iostream, because readsome() is the only non-blocking call supported by the iostream interface, and it's seriously inadequate. There really needs to be something like readsome() but doesn't extract data. streambuf even provides in_avail(). Not sure why iostream doesn't expose that.

The class ended up being something like this:

Code:

---

class MySerial : public std::iostream, public std::streambuf {
 public:
  MySerial() : std::iostream(this) {}

 protected:
  // overriding functions for streambuf
}

---

It seems to be working perfectly fine, and I can provide my own non-blocking interface alongside.

---

Yeah C++ streams can be a real headache. (Badly designed, IMHO). Good to know that a reasonable inheritance-based approach is actually feasible.

Quote:

---

Originally Posted by Sir Galahad

Yeah C++ streams can be a real headache. (Badly designed, IMHO). Good to know that a reasonable inheritance-based approach is actually feasible.

---

Yeah definitely. I was reading an article on tips on how to use iostreams, before realizing it was actually written in the early 1990s before standardization! And they have stayed more or less the same since then!

It was a truly innovative design for its time (abstract and generic data sources and sinks), but really starting to show its age.