This topic is 1511 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

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 FinishedWrite() {}

public:
virtual ~asIBinaryStream() {}
};


Share on other sites

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?

Share on other sites

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'.

Edited by iraxef

Share on other sites

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. :)

1. 1
2. 2
Rutin
19
3. 3
khawk
15
4. 4
5. 5
A4L
13

• 13
• 26
• 10
• 11
• 44
• Forum Statistics

• Total Topics
633743
• Total Posts
3013644
×