InputStream::readType <> template specializations


It would be great if we had this:

template <class T>
T InputStream::readType ();

These would be inline specializations that call the existing virtuals. For example:

template <>
T InputStream::readType <char> () { return this->readByte(); }

Also we would want the BigEndian versions too.

This would come in very handy if you have a typedef corresponding to the type of value you want to read, especially when it is a template parameter in your own class.

I can add this, Jules do you want it?


(Pretty sure I once tried to do that, but had compiler issues. That was probably back in the days of VC6 though!)

Yes, it’s a nice idea, will have a look at that!


Great! Well, just remember that every point of call will have to explicitly mention the type. Like:

FileOffset offset = stream->readType <FileOffset> ();

But that’s kind of the point.


You know - I think this will break in VC2005, which unfortunately people still use… IIRC it can’t handle template specialisation for member functions (?)


You could #ifdef it so the member functions are only available for later versions.

And/or you can provide a flat specialized template function:

template <class T>
T readTypeFromInputStream (InputStream& stream);


I just wasted a few hours getting bit by a bug.

I have this line:

keyRecord->valSize = stream.readIntBigEndian ();

Where valSize is std::size_t. Works great in Windows, but on my Ubuntu system std::size_t is a 64 bit unsigned value and this blows up, in a subtle way. If we had the template specialization as I described in my post this wouldn’t have happened. And if I explicitly provided the template argument, the compiler would have warned me about differently sized integer assignment.

Jules! juce_core is starting to show signs of disrepair! This is exactly why I made beast a hard fork. I can’t wait for these fixes!


Well it depends, if you plan to have your stream cross platform I strongly suggest you to use int32_t and stuff like that.