Yes that "assimilate" function was exactly what I was looking for. With this mechanism it is possible to create proper CElement derived objects without knowing the exact type at time of creation.
But now I stumbled on the next challenge: Fields. Is there a similar mechanism to add fields to parameters anonymously and then "assimilate" those fields afterwards? Or will I have to use the specific get/set methods in the derived CParameter classes? //Klaus _____ From: Gordon Waidhofer [mailto:[email protected]] Sent: 11. december 2009 22:48 To: LLRP Toolkit Development List Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti binary f ormat The AllList holds parameters to aid deallocations, and to hold subparameters during frame->internal conversion. The AllList plays no role in internal->frame conversion. During frame->internal conversion, all subparameters in the frame are placed on the all list. Then an "assimilate" function places the subparameters on the proper, specific member variables (like m_pROSpec). If a subparameter is not recognized and, hence, there is no specific member to place it on, the subparameter is still properly deallocated because it is on the AllList. Order of subparameters is important for conformance. That's when the internal->frame conversion is done by a function that uses the specific members rather than the AllList. There is no constraint on order for things being in the AllList. In short, XML->internal for CPP would be nice. But because CPP has to work with both Linux/Unix and Windows platforms, and because native XML infrastructure is so radically different between the two, we've never had the time to work through all the concerns. Hope this helps. Regards, -gww _____ From: Klaus Holst Jacobsen [mailto:[email protected]] Sent: Thursday, December 10, 2009 12:00 AM To: LLRP Toolkit Development List Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti binary f ormat Hey Thanks for all the very quick responses. Sounds like a good idea with perl and binary representation. I have however not yet given up the thought of having cpp encode from xml directly. On thing that struck me as kind of odd though is the following. Each CElement has a list of parameters (m_listAllSubParameters), but at the same time e.g. the CADD_ROSPEC message has a member variable (m_pROSpec) holding the contained ROSpec parameter. But why not simply hold the ROSpec parameter of CADD_ROSPEC in the Celement::m_listAllSubParameters instead of having a dedicated member variable. This would make it so much easier to parse from XML to objects without having to know the identity of the object you're parsing right now in order to use special set methods. Or said in other words: What would happen if I added a CROSpec parameter to a CADD_ROSPEC message using Celement::addSubParameterToAllList(...) instead of CAD_ROSPEC::setROSpec(...) and then parsed that to binary and sent it to a reader? //Klaus -----Original Message----- From: John R. Hogerhuis [mailto:[email protected] <mailto:[email protected]> ] Sent: 10. december 2009 01:10 To: LLRP Toolkit Development List Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti binary f ormat On Wed, Dec 9, 2009 at 3:53 PM, Paul Dietrich <[email protected]> wrote: > As an alternate to Johns idea, it may be possible to store your configurations in their binary format. > Excellent idea... as an extension of that concept, if you need to edit LTK-XML interactively, LTK-Perl script could be used from the command line as an intermediary for converting to/from binary format. So if you edit LTK-XML with a text editor, you can compile it to binary with Perl. Then LTK-CPP will allow you to manipulate the binary form. Similarly you can take binary, use Perl to convert to XML, then edit it. -- John. ---------------------------------------------------------------------------- -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev <http://p.sf.net/sfu/google-dev2dev> _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel <https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel>
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
