>> Consider abstracting encode/decode
> Not sure I understand.
I found this very handy for LTKC[PP].
I'll use encode as an easy example.
The generated, per-class encoder operates on
an encoderStream. So (paraphrasing for clarity)
you might find this in the generated code:
ROSpec::encode(EncoderStream *pEncoderStream)
{
pEncoderStream->put_u32(m_ROSpecID, "ROSpecID");
}
The binary encoder:
put_u32 (llrp_u32_t value, char *pName)
{
put_byte(value>>24);
put_byte(value>>16);
put_byte(value>>8);
put_byte(value>>0);
}
The XML pretty-printer
put_u32(llrp_u32_t value, char *pName)
{
printf("<%s>%d</%s>\n", pName, value, pName);
}
Just a good ol' pretty printer:
put_u32(llrp_u32_t value, char *pName)
{
printf("%-20s : %d\n", pName, value);
}
It allows the generated "encoder" to be leveraged a lot of ways.
Consider an XML DOM tree. It's too complicated to write
a few line example. But I can easily imaging an encoderStream
that knows how to insert things into a DOM tree.
The decoder is more complicated but can be similarly abstracted.
I have some thinkertoys (not finished) that leverage this
abstraction with some nice benefits.
Regards,
-gww
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
