MemoryBlock request

[haydxn]

As usual, bit of an odd one (though really, requests are only ever for odd things, as you think of everything!)

SHORT VERSION: would it be possible to add functionality for a MemoryBlock to not own it’s data? It would likely require a flag, but one which is not ever available for misuse; a MemoryBlock could return a const MemoryBlock object which describes a subset of the data it contains.

WHY: I’m making an app which communicates with other software, so naturally there are messages being passed about. When I recieve a message (in a memory block), I process the header to decide what to do next, and then I’d like to pass on what’s left of the message elsewhere for handling. I’d like to trim the header off, but as it stands I have to either (1) drop to void* and size parameter passing, or (2) make an unnecessary copy to a new memory block. What I’d like to do is say myBlock.getSubBlock(offset,size) [where size could be -1 to use the remaining data], and be given a const object I can pass to functions whilst i’m still within the lifetime of the source block.

Does this sound reasonable?

[jules]

hmm… don’t really like the idea too much. MemoryBlock is a really simple class, and that’d involve making it much more complex, and you’d have to consider what happens when you resize one of these blocks, plus the danger of deleting/changing its source while you’re using it.

There might be a good design that’d let you do this, but it doesn’t feel like cramming it into the existing memoryblock class would be the way to go. Maybe a MemoryBlockSubsection class?

Alternatively, why not pass a MemoryInputStream - I think that can refer to static data or own its own copy already.

[haydxn]

I’ll have a look at memoryinputstream though I like the idea of having a single object that simply refers to existing data from a memoryblock, where the user is aware that it depends on another instance (because that is what it is- a subsection of an existing block). I first thought of a subsection class, but figured it’d involve duplicating many of the functions already in memoryblock (the const ones), and as the non-const functions couldn’t be used anyway, it seemed sensible enough to just have the functionality within memoryblock.
I’ll probably just knock up my own subsection class, it’s definitely safer than trying to hack it into memoryblock, plus there is an obvious implicit caution from the naming, rather than hoping the user reads the function docs.
Cheers for helping me brainstorm

[haydxn]

tbh, MemoryInputStream (and MemoryOutputStream for the other way) seem to be more logical for what i want to do anyway

One puny request though; any chance of a MemoryInputStream constructor taking a MemoryBlock parameter? “Just for fun, like.” [the output stream has one].

Thanks again

[jules]

Yep, good idea.