You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Likely blocked until issue #375 is implemented. See PR #373 for additional discussion.
Currently calling 'DynamicMemoryWriter::GetReader' provides access to data within DynamicMemoryWriter without transferring ownership.
Currently you should never attempt to clear DynamicMemoryWriter's internal stored data for future writes in case a Reader is still referencing the content. This can be avoided procedurally by always creating a new instance of DynamicMemoryWriter after GetReader is called for future dynamic memory reads. Some discussion if the procedural approach is actually more appropriate than adding a clear type concept to DynamicMemoryWriter.
I did try to add a Clear function to DynamicMemoryWriter before understanding the relationship of shared data between the Reader and Writer although that may not be in line with how others would intuitively try to use DynamicMemoryWriter.
Example Clear command for future consideration:
// Clear all currently set memoryvoidDynamicMemoryWriter::Clear() {
SeekBeginning();
streamBuffer.clear();
}
The text was updated successfully, but these errors were encountered:
To add a bit of detail, it is possible to switch back and forth between writing or clearing and reading, just that you always want to create a new reader object after a write or clear operation. This is similar how updates to a container can invalidate iterators traversing the container.
Likely blocked until issue #375 is implemented. See PR #373 for additional discussion.
Currently calling 'DynamicMemoryWriter::GetReader' provides access to data within DynamicMemoryWriter without transferring ownership.
Currently you should never attempt to clear DynamicMemoryWriter's internal stored data for future writes in case a Reader is still referencing the content. This can be avoided procedurally by always creating a new instance of DynamicMemoryWriter after GetReader is called for future dynamic memory reads. Some discussion if the procedural approach is actually more appropriate than adding a clear type concept to DynamicMemoryWriter.
I did try to add a Clear function to DynamicMemoryWriter before understanding the relationship of shared data between the Reader and Writer although that may not be in line with how others would intuitively try to use DynamicMemoryWriter.
Example Clear command for future consideration:
The text was updated successfully, but these errors were encountered: