Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Would you consider expanding asIBinaryStream to include something like the below 2 functions:
class asIBinaryStream
{
public:
virtual void Read(void *ptr, asUINT size) = 0;
virtual void Write(const void *ptr, asUINT size) = 0;
// NEW FUNCTIONS
virtual void FinishedRead() {}
virtual void FinishedWrite() {}
public:
virtual ~asIBinaryStream() {}
};
Thanks for your consideration.
I might, but to what purpose would you want me to include this?
When the LoadByteCode or SaveByteCode method returns the engine won't use the stream any further, so the application can easily determine when the engine is done with the stream anyway. What would the benefit be of the engine first explicitly calling FinishedRead or FinishedWrite on the stream just before returning?
Separation of concerns, I suppose.. I shouldn't have to manually manage something this low level where if I potentially forget to reset the instance between reads I've either got a buffer overrun or an assert/exception (depending on how I've dealt with the buffer access). If the script engine has an internal way to tell the concrete instance (of the binary stream) that it's finished, then from an external perspective that instance will always be in a consistent state.
It's just a better-encapsulated system if it 'takes care of itself'.
Normally I would agree, but in this case the engine is not the one to open the stream in the first place, so you're not achieving the encapsulated system anyway. The application is responsible for making sure the stream starts from the right position, so I don't see why it shouldn't be responsible for making sure the stream is also finished properly. :)
