[Spirit][karma] Generating Pascal string like output
Hi all, While I had no trouble getting the parsing part for this to work, I'm stuck on the generator part. Specifically, I'm stuck on getting the size into the output. The goal is a rule that takes a std::vector<byte> and outputs it in such a way that it is preceded by its size (in a custom encoding) and padded by zeroes to align on a four byte boundary. I want to reuse this rule in several other rules and prefer to break it up into smaller pieces. A minimalistic example of what I have come up with so far is attached. What I can't seem figure out how to get at and store the vector's size in pascal_string_size_. There also seem to be problems with refering to the stored size_ in pascal_string_payload_ and pascal_string_padding_ that I don't understand. Note that the signed/unsigned distinction is on purpose. I am aware of the side effects of assigning to size_ and that that is not threadsafe. Any help would be appreciated. Thanks in advance, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
2012/1/23 Olaf Meeuwissen
Hi all,
While I had no trouble getting the parsing part for this to work, I'm stuck on the generator part. Specifically, I'm stuck on getting the size into the output.
The goal is a rule that takes a std::vector<byte> and outputs it in such a way that it is preceded by its size (in a custom encoding) and padded by zeroes to align on a four byte boundary.
I want to reuse this rule in several other rules and prefer to break it up into smaller pieces. A minimalistic example of what I have come up with so far is attached. What I can't seem figure out how to get at and store the vector's size in pascal_string_size_. There also seem to be problems with refering to the stored size_ in pascal_string_payload_ and pascal_string_padding_ that I don't understand.
o Use phoenix::size to extrac the size o Use karma::embed(*) to feed in the size o Use local variable to store the size o Use inherited attribute to pass the size Full code attached. =footnotes= (*) A component made by me, you can find it here: https://github.com/jamboree/boost-jamboree-spirit. As an alternative, you can search "no_attr" on Spirit ML.
TONGARI
2012/1/23 Olaf Meeuwissen
Hi all,
While I had no trouble getting the parsing part for this to work, I'm stuck on the generator part. Specifically, I'm stuck on getting the size into the output.
The goal is a rule that takes a std::vector<byte> and outputs it in such a way that it is preceded by its size (in a custom encoding) and padded by zeroes to align on a four byte boundary.
I want to reuse this rule in several other rules and prefer to break it up into smaller pieces. A minimalistic example of what I have come up with so far is attached. What I can't seem figure out how to get at and store the vector's size in pascal_string_size_. There also seem to be problems with refering to the stored size_ in pascal_string_payload_ and pascal_string_padding_ that I don't understand.
o Use phoenix::size to extrac the size o Use karma::embed(*) to feed in the size o Use local variable to store the size o Use inherited attribute to pass the size
Full code attached.
=footnotes= (*) A component made by me, you can find it here: https://github.com/jamboree/ boost-jamboree-spirit. As an alternative, you can search "no_attr" on Spirit ML.
Hmm, karma::embed seems to require Boost > 1.46.1. At this point, that is not an option for me :-( $ git clone https://github.com/jamboree/boost-jamboree-spirit boost-jamboree-spirit $ g++ -Iboost-jamboree-spirit -o pascal-string pascal-string.cpp In file included from /usr/include/boost/spirit/home/support/make_component.hpp:17:0, from /usr/include/boost/spirit/home/support/meta_compiler.hpp:18, from /usr/include/boost/spirit/home/support/terminal.hpp:18, from boost-jamboree-spirit/boost/spirit/home/support/common_terminals.hpp:15, from /usr/include/boost/spirit/home/karma/char/char.hpp:14, from /usr/include/boost/spirit/home/karma/char.hpp:13, from /usr/include/boost/spirit/home/karma.hpp:13, from /usr/include/boost/spirit/include/karma.hpp:16, from pascal-string.cpp:5: boost-jamboree-spirit/boost/spirit/home/support/modify.hpp:15:93: fatal error: boost/spirit/include/phoenix_limits.hpp: No such file or directory The phoenix::size and inherited attribute where two helpful cluebats, though. With those (and fixing some of the stupidities in my original code) I've been able to come close but I always miss the first byte in the vector. Any ideas why and how to fix that? Note, I am "stuck" with Boost 1.46.1 for the time being. Thanks in advance -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
2012/1/23 Olaf Meeuwissen
The phoenix::size and inherited attribute where two helpful cluebats, though. With those (and fixing some of the stupidities in my original code) I've been able to come close but I always miss the first byte in the vector. Any ideas why and how to fix that?
That's why you need no_attribute[] if you cannot have karma::embed. Get this: http://boost.2283326.n4.nabble.com/attachment/3228512/1/no_attribute_directi... Used like: no_attribute[pascal_string_size_[ _1 = size (_val) ]] HTH
TONGARI
2012/1/23 Olaf Meeuwissen
[...]
The phoenix::size and inherited attribute where two helpful cluebats, though. With those (and fixing some of the stupidities in my original code) I've been able to come close but I always miss the first byte in the vector. Any ideas why and how to fix that?
That's why you need no_attribute[] if you cannot have karma::embed.
Get this: http://boost.2283326.n4.nabble.com/attachment/3228512/1/no_attribute_directi...
Used like:
no_attribute[pascal_string_size_[ _1 = size (_val) ]]
Together with a using custom_generator::no_attribute; that does the trick nicely indeed and works fine with Boost 1.46.1. For reference purposes, the full working example code attached. The code assumes that no_attribute_directive.hpp is in the same directory (or that a suitable include search path directive is given on the command-line).
HTH
Thanks! -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
participants (2)
-
Olaf Meeuwissen -
TONGARI