|
|
Home » U++ Library support » U++ Core » PROPOSAL: small / usefull Stream iface extension
PROPOSAL: small / usefull Stream iface extension [message #27952] |
Wed, 11 August 2010 23:39 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
hi all,
when implementing own, nontrivial protocols using stream, one sometimes (like i am now) in trouble, needing to access the underlying buffer directly, without always triggering a complete copy.. and also beeing able to skip read/write things.
thus here some very small but usefull functions. it would be really cool to have them there. otherwise please comment why not and how could i circumvent this need, without copying over and over.. (imagine having to put packets there that have some data, over which to calculate crc..etc).
Stream.h:85
byte * Base() { return buffer; }
byte * Head() { return ptr; }
void SkipRead(dword size = 1) { ptr += min((dword)(uintptr_t)(rdlim - ptr), size); }
void SkipWrite(dword size = 1){ ptr += min((dword)(uintptr_t)(wrlim - ptr), size); }
Head is the most important for me..
SkipRead makes sense as well (ignoring stuff, without need of dummy-copying just to advance ptr)
SkipWrite is kind of just for symetrical completeness, but might be usefull somewhere..
[Updated on: Wed, 11 August 2010 23:47] Report message to a moderator
|
|
|
|
|
|
Re: PROPOSAL: small / usefull Stream iface extension [message #28004 is a reply to message #28002] |
Fri, 13 August 2010 10:07 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
Quote: |
Sorry, but this is poorly defined...
|
thats why i'm asking people who know better
would Peek return the underlying buffer? at ptr position?
then i'm fine with it and can tweak around with Seek ofcorse. indeed, Peek is quite a usefull function, anyway. in fact i prefer it, it keeps the API understandable, not too implementation bound, but usage bound. good idea.
SkipRead / SkipWrite are only helpers, and are not that much nessesary actually, neither my second post. one could would workaround it sth like
Peek would need to deferentiate wrlim and rdlim right?
why const btw?
const byte * Peek(int size);
my point is solely driven by avoiding unwanted memcpy, thats why accessing buffer directly to perform tweaked read /write (some special communication protocol)
[Updated on: Fri, 13 August 2010 10:16] Report message to a moderator
|
|
|
|
Re: PROPOSAL: small / usefull Stream iface extension [message #28008 is a reply to message #28004] |
Fri, 13 August 2010 10:29 |
|
mirek
Messages: 14105 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Fri, 13 August 2010 04:07 |
Quote: |
Sorry, but this is poorly defined...
|
thats why i'm asking people who know better
would Peek return the underlying buffer? at ptr position?
then i'm fine with it and can tweak around with Seek ofcorse. indeed, Peek is quite a usefull function, anyway. in fact i prefer it, it keeps the API understandable, not too implementation bound, but usage bound. good idea.
SkipRead / SkipWrite are only helpers, and are not that much nessesary actually, neither my second post. one could would workaround it sth like
|
Which is in the interface as SeekCur.
Quote: |
Peek would need to deferentiate wrlim and rdlim right?
why const btw?
const byte * Peek(int size);
|
Sure, only read variant.
|
|
|
Re: PROPOSAL: small / usefull Stream iface extension [message #28009 is a reply to message #28006] |
Fri, 13 August 2010 10:30 |
|
mirek
Messages: 14105 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Fri, 13 August 2010 04:23 | another proposal, maybe this one's better...
const byte * Peek(int size = 1) { if(size <= 0) return NULL; if(ptr + size <= rdlim) return ptr; return NULL; }
byte * Head(int size = 1) { if(size <= 0) return NULL; if(ptr + size <= wrlim) return ptr; return NULL; }
|
For some reasons, write variant sounds somewhat dangerous to me...
Have to think about this one...
Well, in any case, it should advance the ptr...
[Updated on: Fri, 13 August 2010 10:31] Report message to a moderator
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Nov 01 01:39:26 CET 2024
Total time taken to generate the page: 0.03149 seconds
|
|
|