Menu
▾
▴
spirit-devel — Spirit Development
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(101) |
Mar
(126) |
Apr
(262) |
May
(72) |
Jun
(76) |
Jul
(82) |
Aug
(92) |
Sep
(73) |
Oct
(70) |
Nov
(160) |
Dec
(107) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(95) |
Feb
(123) |
Mar
(24) |
Apr
(24) |
May
(133) |
Jun
(256) |
Jul
(108) |
Aug
(40) |
Sep
(112) |
Oct
(25) |
Nov
(69) |
Dec
(87) |
| 2005 |
Jan
(35) |
Feb
(38) |
Mar
(6) |
Apr
(1) |
May
(2) |
Jun
(12) |
Jul
(27) |
Aug
|
Sep
(16) |
Oct
(23) |
Nov
(22) |
Dec
(4) |
| 2006 |
Jan
(3) |
Feb
(12) |
Mar
(41) |
Apr
(122) |
May
(101) |
Jun
(37) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(21) |
Nov
(89) |
Dec
(12) |
| 2007 |
Jan
(19) |
Feb
(48) |
Mar
(30) |
Apr
(52) |
May
(31) |
Jun
(30) |
Jul
(6) |
Aug
(16) |
Sep
(16) |
Oct
(2) |
Nov
(4) |
Dec
|
| 2008 |
Jan
(26) |
Feb
(29) |
Mar
(6) |
Apr
(11) |
May
(5) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(86) |
Nov
(34) |
Dec
(33) |
| 2009 |
Jan
(59) |
Feb
(35) |
Mar
(73) |
Apr
(17) |
May
(15) |
Jun
(20) |
Jul
(9) |
Aug
(24) |
Sep
(11) |
Oct
(14) |
Nov
(18) |
Dec
(4) |
| 2010 |
Jan
(5) |
Feb
(2) |
Mar
(12) |
Apr
(9) |
May
(9) |
Jun
(4) |
Jul
(5) |
Aug
|
Sep
(2) |
Oct
|
Nov
(17) |
Dec
(27) |
| 2011 |
Jan
(32) |
Feb
(14) |
Mar
(11) |
Apr
(7) |
May
(5) |
Jun
|
Jul
(5) |
Aug
(2) |
Sep
(2) |
Oct
(29) |
Nov
(4) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(11) |
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(3) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
|
Dec
(2) |
| 2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Pablo E. C. <pab...@gm...> - 2023-09-30 10:35:17
|
*[Boost.Asio] suggested to not be useful for a dedicated networking synchronous implementation where the Operating System is just a gateway* Dear Sirs: 1. I am a C++ Developer. Neither a Boost.Asio developer expert, nor a networking expert. 2. I have now the opportunity to develop a networking application from scratch, which requires interaction with an already existing application. 3. The already existing application seems to have been developed entirely in C language, with Linux-based networking header files (source code is not yet available to me). 4. My first understanding (or, more precisely, my assumption) is that each and every networking solution that can be implemented in C language can also be implemented in C++, using Boost.Asio. 5. However, reviewing again the Boost.Asio documentation, I am prone to understand that "Asio" might be an acronym for: "ASinchronous Input-Output". If this is correct, maybe, synchronous implementations might be out of the scope of Boost.Asio. 6. Since the application I have to develop needs to interact with an already existing application, I also need to discuss my solution with external stakeholders who are experts on that already existing application. 7. Now, even though I have the entire decision to choose the development tools for this new application (my managers are "networking" architects; not software architects; so, they rely entirely on my own decision), I need to provide a precise fundament for my election. 8. Starting on my assumption posted in # 4, I want to develop a modern C++ networking robust application, using Boost.Asio and rejecting a C solution, if possible; of course. 9. As my managers are not software experts, they are not able to provide precise business requirements to me, valuable to making the correct decision. 10. Instead, to know even the business requirements of the new application, it seems that I need to rely on the external stakeholders (mentioned in # 6). 11. I presented my intention of using Boost.Asio to one of those external stakeholders and received the following response from him: > About using Boost.Asio library: > 1) Following our meeting, I did a quick dive into the documentation provided on https://www.boost.org/doc/libs/1_83_0/doc/html/boost_asio/overview.html. > 2) I don’t have really some experience with Boost; but it seems to me that the networking part of this library [Boost.Asio] is fully oriented towards building an application server, i.e. allowing agents/clients to connect to the machine running Boost.Asio and allowing the program to process a result in an asynchronous way, and then return a result (e.g. by responding to the same network socket). Boost.Asio might be useful to build e.g. an HTTP server or a REST API server. > 3) Boost.Asio seems to rely on the networking capabilities of the OS ["operating system"] (e.g. Sockets) to get the data from the received packets, manage TCP connections handshakes, opening, and closing (which implies packet copy between kernel land and user land, impairing global performance). > 4) In those cases, Boost.Asio seems to manage communications from a client and intended for the server running the program. > 5) Instead, the application you want to build is actually quite different from that behaviour, as the machine will not be the “destination” of those packets, but just a gateway. That means that the packets received on the NIC ["network interface controller"] shall not be fully interpreted by the OS, since the OS is not the recipient of the packet. > 6) Moreover, you cannot start an asynchronous operation per packet found on the wire, as this will overload the system. > 7) So the "packet acquisition" / "thread dispatching" for the traffic management of your application seems actually not be manageable by Boost.Asio library. > 8) As a consequence, my view is that you will have to manage the "packet acquisition" / "thread dispatching" / "per thread packet processing" in a dedicated synchronous architecture (as built in our code samples). And then, the result of the DPI ["deep packet inspection"] analysis can be a "starting point event" (or allow to launch an "initiating function") for further asynchronous mechanism run by Boost.Asio to perform operations based on DPI results (and containing the specific logic of your application). > 9) As indicated in the beginning, I’m not a Boost.Asio expert, so please tell me if my understanding is wrong. 12. First of all, I want to clarify that I arrived to know all the content of the quoted email via that email and not before. That is: even the requirements of the "dedicated synchronous architecture" were provided to me in that email, "as if I was aware of them before that email". 13. Now, as you can understand, I cannot start a long development path ending at the middle of it saying: "We made a wrong assumption. We cannot use Boost.Asio. We need to turn back on our own steps and start all over again with a different approach". This would be unacceptable. 14. And it would be more unacceptable with the previous quoted email coming from a person that, even he is not a Boost.Asio expert, he is an expert on his own already existing application and seems to be the referent, so far, for my own requirements. 15. Even though we are at a very early stage (where I have not even access to the existing source code, as mentioned), a response on this topic is expected from my side. 16. Consequently, given the corresponding context, I am presenting now my questions: A. Is it correct my assumption that: each and every networking solution that can be implemented in C language can also be implemented in C++, using Boost.Asio? B. Or, is it correct my assumption that synchronous implementations might be out of scope of Boost.Asio? C. If question A. is correct, then, is it possible to use Boost.Asio for a dedicated networking synchronous architecture and implementation where the Operating System is just a gateway (as described in the quoted email)? D. Or the suggested opinion of the quoted stakeholder is correct? E. In case the quoted stakeholder is not correct on his assumption, do we have enough available documentation about Boost.Asio to implement a solution with the main topics described in question C.? F. Or, in case the quoted stakeholder is correct on his assumption: are you aware of an advisible library on top of which I might be able to develop the requested solution using modern C++, to avoid relying on a C solution? In advance, I appreciate very much your answers, help, and precise advice! Pablo Esteban Camacho C & C++ Developer pab...@gm... pab...@ya... https://www.linkedin.com/in/pablo-esteban-camacho/ |
|
From: Bhavit S. <bha...@gm...> - 2019-11-28 01:25:21
|
Hi, I'm interested to learn how spirit x3 is implemented. Are there any design docs which document the implementation details of the project as I am really eager to understand how exactly the parser is implemented. Hence, I want to look at its architecture, and the various design choices. Can anyone guide me regarding the same? Regards Bhavit Sharma |
|
From: Larry E. <cpp...@su...> - 2017-01-23 01:11:47
|
The x3 line: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x3/operator/kleene.hpp#L8 is: #if !defined(SPIRIT_KLEENE_JANUARY_07_2007_0818AM) and the qi line: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/qi/operator/kleene.hpp#L8 is: #if !defined(SPIRIT_KLEENE_JANUARY_07_2007_0818AM) Wouldn't it be better if these two were different? -regards, Larry |
|
From: Larry E. <cpp...@su...> - 2016-12-17 07:46:00
|
On 12/16/2016 11:55 AM, Larry Evans wrote: > In the parse_rhs_main function here: > > https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x3/nonterminal/detail/rule.hpp#L204 > > there's a flag, is_default_parse_rule, calculated earlier in the > function. Why couldn't this flag be passed as an argument instead? > Then, here: > > https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x3/nonterminal/rule.hpp#L162 > > it would be passed as false, and the default value of true could be > added to the rule_definition::parse function here: > > https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x3/nonterminal/rule.hpp#L58 > > This would be clearer because there would be no need for the calculation > in the earlier part of parse_rhs_main, and, since it's being passed > as false when called from the BOOST_SPIRIT_DEFINE macro, the correctness > of the value would be obvious in this case. > > Is there any downside to this? > Yes. Tried this and the default parse_rule static_assert fires even though it will never be called at runtime :( Sorry for noise. -Larry |
|
From: Larry E. <cpp...@su...> - 2016-12-16 16:55:24
|
In the parse_rhs_main function here: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x3/nonterminal/detail/rule.hpp#L204 there's a flag, is_default_parse_rule, calculated earlier in the function. Why couldn't this flag be passed as an argument instead? Then, here: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x3/nonterminal/rule.hpp#L162 it would be passed as false, and the default value of true could be added to the rule_definition::parse function here: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x3/nonterminal/rule.hpp#L58 This would be clearer because there would be no need for the calculation in the earlier part of parse_rhs_main, and, since it's being passed as false when called from the BOOST_SPIRIT_DEFINE macro, the correctness of the value would be obvious in this case. Is there any downside to this? -regards, Larry |
|
From: Larry E. <cpp...@su...> - 2016-09-22 13:51:54
|
On 09/08/2016 01:48 AM, Larry Evans wrote: > Attached is a .txt file containing the reason for the question in the > Subject. I've used an attachment instead of putting reasons in line > to avoid any reformatting the some mail programs might impose. > Is there no one else interested in this? Are the knowlegeable people too busy ATM to answer? Is the question unclear? Any feedback is welcome. -regards, Larry |
|
From: Damien B. <dam...@le...> - 2016-09-14 08:51:24
|
Hi Spirit developers , I've found an issue in Boost.Spirit.Qi when parsing a Variant with the bitwise-or operator, if I add the compile flag -DNDEBUG, a simple qi rule is not able to initialize a variant anymore with the parsed data. I don't know if this issue already exists, I searched on the trac but couldn't find anything. > typedef boost::variant<int, bool, std::string> frame; > > rule<Iterator, frame()> r = > int_ > | bool_ > | as_string[*char_] > ; The code to reproduce the bug is here : https://github.com/daminetreg/bug-boost-spirit-qi-ndebug/blob/master/ndebug_compilation.cpp If I parse the texts, in order : "this is a string", "42", "true", then I get : Compiled*without -DNDEBUG,* it parses correctly : http://melpon.org/wandbox/permlink/y3ueDkxbJYsYn7vs > $ ./without_ndebug > NSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE this is a string > i 42 > b 1 Once compiled *with -DNDEBUG*, it doesn't parse anything anymore and let the variant default-initialized: http://melpon.org/wandbox/permlink/cgu20wphStlrJoMQ > $ ./with_ndebug > i 0 > i 0 > i 0 I can confirm the bug is not in Boost.Variant but somewhere else, because I can reproduce it exactly, using another Variant type (i.e. MapBox.Variant) : https://github.com/sauter-hq/boost-spirit-mapbox-variant. I think it's not compiler related, because different versions of clang and gcc appears to produce the same result. Cheers, -- Damien Buhl |
|
From: Larry E. <cpp...@su...> - 2016-09-08 06:49:09
|
Attached is a .txt file containing the reason for the question in the Subject. I've used an attachment instead of putting reasons in line to avoid any reformatting the some mail programs might impose. -regards, Larry |
|
From: Larry E. <cpp...@su...> - 2016-08-25 18:57:54
|
On 07/31/2016 03:23 PM, Larry Evans wrote: > Because unused appears nowhere else in the function body, > I was wondering What's the purpose of: > > https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x3/nonterminal/rule.hpp#L163 > > ? Never mind. It's *obviously* there: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x3/nonterminal/rule.hpp#L165 I don't know how I missed that :( |
|
From: Larry E. <cpp...@su...> - 2016-08-25 18:48:29
|
On 08/24/2016 05:47 PM, Mikael Asplund wrote: > If you take a look at the master branch (which is in the released X3), you'll notice that it is... > > https://github.com/boostorg/spirit/blob/master/include/boost/spirit/home/x3/nonterminal/rule.hpp#L164 > > /Mikael So, why does x3-devel no longer do that? They must have some reason for the change, unless the change was unintended. > > > -----Original Message----- > From: Larry Evans [mailto:cpp...@su...] > Sent: Wednesday, August 24, 2016 11:25 > To: spi...@li... > Subject: [Spirit-devel] [x3_devel] why not static ... def_ in specialized parse_rule? > > The code here: > > https://github.com/boostorg/spirit/blob/x3-devel/include/boost/spirit/home/x3/nonterminal/rule.hpp#L167 > > recalculates the same const value each time the function is entered. > Why not make this static to avoid the recalculation? > > ------------------------------------------------------------------------------ > _______________________________________________ > Spirit-devel mailing list > Spi...@li... > https://lists.sourceforge.net/lists/listinfo/spirit-devel > > ------------------------------------------------------------------------------ > |
|
From: Mikael A. <ka...@yd...> - 2016-08-24 23:02:54
|
If you take a look at the master branch (which is in the released X3), you'll notice that it is... https://github.com/boostorg/spirit/blob/master/include/boost/spirit/home/x3/nonterminal/rule.hpp#L164 /Mikael -----Original Message----- From: Larry Evans [mailto:cpp...@su...] Sent: Wednesday, August 24, 2016 11:25 To: spi...@li... Subject: [Spirit-devel] [x3_devel] why not static ... def_ in specialized parse_rule? The code here: https://github.com/boostorg/spirit/blob/x3-devel/include/boost/spirit/home/x3/nonterminal/rule.hpp#L167 recalculates the same const value each time the function is entered. Why not make this static to avoid the recalculation? ------------------------------------------------------------------------------ _______________________________________________ Spirit-devel mailing list Spi...@li... https://lists.sourceforge.net/lists/listinfo/spirit-devel |
|
From: Larry E. <cpp...@su...> - 2016-08-24 09:24:44
|
The code here: https://github.com/boostorg/spirit/blob/x3-devel/include/boost/spirit/home/x3/nonterminal/rule.hpp#L167 recalculates the same const value each time the function is entered. Why not make this static to avoid the recalculation? |
|
From: Larry E. <cpp...@su...> - 2016-07-31 20:23:46
|
Because unused appears nowhere else in the function body, I was wondering What's the purpose of: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x3/nonterminal/rule.hpp#L163 ? |
|
From: Romain N. <rom...@op...> - 2015-05-15 17:23:47
|
With powerpc target and uClibc toolchain the spirit library doesn't
build properly due to an invalid field access.
"bits" field is intended only for internal use in
include/boost/math/special_functions/sign.hpp not from
include/boost/spirit/home/support/detail/sign.hpp.
This lead to the following build failure:
In file included from ./boost/spirit/home/qi/numeric/detail/real_impl.hpp:22:0,
from ./boost/spirit/home/qi/numeric/real.hpp:21,
from ./boost/spirit/home/qi/numeric.hpp:17,
from ./boost/spirit/include/qi_core.hpp:23,
from libs/log/src/default_filter_factory.cpp:21:
./boost/spirit/home/support/detail/sign.hpp: In instantiation of 'T boost::spirit::detail::changesign(T) [with T = long double]':
./boost/spirit/home/qi/numeric/detail/real_impl.hpp:94:50: required from here
./boost/spirit/home/support/detail/sign.hpp:60:36: error:
no type named 'bits' in 'traits_type {aka struct boost::math::detail::fp_traits_non_native<long double, boost::math::detail::extended_double_precision>}'
typename traits_type::bits a;
Simply call (boost::math::changesign)(x) from
include/boost/spirit/home/support/detail/sign.hpp to fixes this.
Fixes:
http://autobuild.buildroot.net/results/be1/be1069e8528d299f487f431f7e2d793413ccbab8/build-end.log
Signed-off-by: Romain Naour <rom...@op...>
---
include/boost/spirit/home/support/detail/sign.hpp | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/include/boost/spirit/home/support/detail/sign.hpp b/include/boost/spirit/home/support/detail/sign.hpp
index 7c1bfb0..2a64e6a 100644
--- a/include/boost/spirit/home/support/detail/sign.hpp
+++ b/include/boost/spirit/home/support/detail/sign.hpp
@@ -55,13 +55,7 @@ namespace boost { namespace spirit { namespace detail
#if defined(BOOST_MATH_USE_STD_FPCLASSIFY) && !defined(BOOST_MATH_DISABLE_STD_FPCLASSIFY)
return -x;
#else
- typedef typename math::detail::fp_traits<T>::type traits_type;
-
- typename traits_type::bits a;
- traits_type::get_bits(x, a);
- a ^= traits_type::sign;
- traits_type::set_bits(x, a);
- return x;
+ return (boost::math::changesign)(x);
#endif
}
#endif
--
1.9.3
|
|
From: Nikita K. <nok...@gm...> - 2015-04-28 22:44:15
|
Take a look at utree. You can find info about it here: 1) http://www.boost.org/doc/libs/1_58_0/libs/spirit/doc/html/spirit/support/utree.html 2) http://boost-spirit.com/home/2011/06/12/ast-construction-with-the-universal-tree/ 2015-04-29 1:30 GMT+03:00 YiQing Yang <yi...@ob...>: > Hi, > > > > I need to create a parser for a SQL like query language. The end result > after parsing needs to be an expression tree with operators and operands to > describe the query using our own expression tree library. > > > > It seems to me that I can't take advantage of the convenient features > provided by Semantic Action to do this, as the children nodes will be > created earlier than the parent node if the nodes creation is executed by > the semantic actions, but the expression tree has to be built from top > down. Looks like I should use the Parser tree or AST tree to accomplish > this. > > > > But it seems that the Parser tree is only available in Spirit Classic. Is there parser tree api available with the Qi parser grammar? > > > > Thanks, > > > > Yiqing > > > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Spirit-devel mailing list > Spi...@li... > https://lists.sourceforge.net/lists/listinfo/spirit-devel > > |
|
From: YiQing Y. <yi...@ob...> - 2015-04-28 22:30:14
|
Hi, I need to create a parser for a SQL like query language. The end result after parsing needs to be an expression tree with operators and operands to describe the query using our own expression tree library. It seems to me that I can't take advantage of the convenient features provided by Semantic Action to do this, as the children nodes will be created earlier than the parent node if the nodes creation is executed by the semantic actions, but the expression tree has to be built from top down. Looks like I should use the Parser tree or AST tree to accomplish this. But it seems that the Parser tree is only available in Spirit Classic. Is there parser tree api available with the Qi parser grammar? Thanks, Yiqing |
|
From: Nikita K. <nok...@gm...> - 2015-02-13 19:46:37
|
Reason of using [_1] is simplicity (I just want to enable semantic actions
for showing bug while having minimal code). Replace _1 with whatever you
want (_1 *= 2 for example), but it will not change type of underlying lazy
parser attribute from unused_type (as semantic action disables attribute
propagation for it). As for me all test cases should have same effect, but
for now any directive with lazy arguments yields no result if semantic
action presented.
Test case can be altered to show bug for any directive (if it uses
use_lazy_directive enabler)
/***********************************************************
*******************/
#include <boost/spirit/include/phoenix_core.hpp>
#include <boost/spirit/include/qi.hpp>
#include <boost/spirit/repository/include/qi_distinct.hpp>
namespace qi = boost::spirit::qi;
template <typename T>
void test(const T& rule)
{
const std::string in = "str";
boost::optional<std::string> out;
std::string::const_iterator iter = in.begin();
const std::string::const_iterator end = in.end();
const bool r = qi::parse(iter, end, rule, out);
BOOST_ASSERT(r && iter == end);
std::cout << (out ? "OK" : "FAIL") << std::endl;
}
int main()
{
using qi::_1;
using boost::phoenix::val;
using boost::spirit::repository::qi::distinct;
using qi::alnum;
// Lazy
Semantic
test(distinct(alnum) [qi::string("str")]); // OK No No
test(distinct(alnum) [qi::string("str")[_1]]); // OK No Yes
test(distinct(val(alnum))[qi::string("str")]); // OK Yes No
test(distinct(val(alnum))[qi::string("str")[_1]]); // FAIL Yes Yes
return 0;
}
/***********************************************************
*******************/
The expression int_[_1] creates an integer parser with an attached semantic
> action that does nothing, so its not exactly clear to me what you are
> trying to do. Did you mean to do a push_back(ref(vector), _1) or something?
>
> Lee
>
|
|
From: Lee C. <fo...@le...> - 2015-02-13 16:37:55
|
On Fri, Feb 13, 2015 at 7:05 AM, Nikita Kniazev <nok...@gm...> wrote:
> I hit problem with attributes propagation when using semantic actions,
> even with using enforcing operator %=.
> Following test case shows inconsistent in behavior of directives with lazy
> parameters vs normal.
>
> /******************************************************************************/
>
> #include <boost/spirit/include/phoenix_core.hpp>
>
> #include <boost/spirit/include/qi.hpp>
>
>
> namespace qi = boost::spirit::qi;
>
>
> template <typename T>
>
> void test(const T& rule)
>
> {
>
> const std::string in = "123";
>
> std::vector<int> out;
>
>
> std::string::const_iterator iter = in.begin();
>
> const std::string::const_iterator end = in.end();
>
>
> const bool r = qi::parse(iter, end, rule, out);
>
>
> std::cout << out.size() << std::endl;
>
>
> BOOST_ASSERT(r && iter == end);
>
> }
>
>
> int main()
>
> {
>
> using qi::int_;
>
> using qi::_1;
>
> using boost::phoenix::val;
>
> // Lazy Semantic
>
> test(qi::repeat(1)[int_]); // OK No No
>
> test(qi::repeat(1)[int_[_1]]); // OK No Yes
>
> test(qi::repeat(val(1))[int_]); // OK Yes No
>
> test(qi::repeat(val(1))[int_[_1]]); // FAIL Yes Yes
>
>
> return 0;
>
> }
>
> /******************************************************************************/
>
>
> I'm not sure, but as for me this is a bug (which interfere me at using my
> own custom directive).
>
The expression int_[_1] creates an integer parser with an attached semantic
action that does nothing, so its not exactly clear to me what you are
trying to do. Did you mean to do a push_back(ref(vector), _1) or something?
Lee
|
|
From: Nikita K. <nok...@gm...> - 2015-02-13 12:05:11
|
I hit problem with attributes propagation when using semantic actions, even
with using enforcing operator %=.
Following test case shows inconsistent in behavior of directives with lazy
parameters vs normal.
/******************************************************************************/
#include <boost/spirit/include/phoenix_core.hpp>
#include <boost/spirit/include/qi.hpp>
namespace qi = boost::spirit::qi;
template <typename T>
void test(const T& rule)
{
const std::string in = "123";
std::vector<int> out;
std::string::const_iterator iter = in.begin();
const std::string::const_iterator end = in.end();
const bool r = qi::parse(iter, end, rule, out);
std::cout << out.size() << std::endl;
BOOST_ASSERT(r && iter == end);
}
int main()
{
using qi::int_;
using qi::_1;
using boost::phoenix::val;
// Lazy Semantic
test(qi::repeat(1)[int_]); // OK No No
test(qi::repeat(1)[int_[_1]]); // OK No Yes
test(qi::repeat(val(1))[int_]); // OK Yes No
test(qi::repeat(val(1))[int_[_1]]); // FAIL Yes Yes
return 0;
}
/******************************************************************************/
I'm not sure, but as for me this is a bug (which interfere me at using my
own custom directive).
|
|
From: SF M. E. <el...@us...> - 2013-10-25 11:00:51
|
Hello, Does the attached source file work on your software development or test system eventually? http://sourceforge.net/mailarchive/message.php?msg_id=31535238 How can an error message like the following be resolved here? /usr/local/include/boost/spirit/home/qi/detail/parse_auto.hpp:186:50: error: ‘call’ is not a member of ‘boost::spirit::qi::detail::phrase_parse_impl<my_grammar<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, std::map<std::basic_string<char>, std::basic_string<char> > >, void>’ Regards, Markus |
|
From: Eric N. <er...@bo...> - 2013-02-17 18:28:42
|
Thought some sympathetic soul here might be able to clear up this user's confusion(?) and earn themselves some (boost.)karma points. http://stackoverflow.com/questions/14911337/evaluating-result-of-boostphoenixinsert Eric |
|
From: Eric N. <er...@bo...> - 2012-12-29 22:26:43
|
http://stackoverflow.com/questions/14063880/why-does-this-proto-phoenix-toy-example-crash Any insights? -- Eric Niebler BoostPro Computing http://www.boostpro.com |
|
From: Alexandre H. <ale...@gm...> - 2012-11-28 16:15:08
|
Hello, Consider the following code (http://www.boost.org/doc/libs/1_52_0/libs/spirit/example/qi/mini_xml1.cpp modified): /*****************************************************************************************************/ #include <string> #include <boost/spirit/include/phoenix_operator.hpp> #include <boost/spirit/include/qi.hpp> namespace ascii = boost::spirit::ascii; namespace qi = boost::spirit::qi; namespace spirit = boost::spirit; template <typename Iterator> struct parser : qi::grammar<Iterator, void(), qi::locals<std::string>, ascii::space_type> { qi::rule<Iterator, void(), qi::locals<std::string>, ascii::space_type> r_xml; qi::rule<Iterator, std::string(), ascii::space_type> r_start; qi::rule<Iterator, void(std::string), ascii::space_type> r_end; parser() : parser::base_type(r_xml) { using ascii::char_; using ascii::string; using qi::lexeme; using qi::lit; using namespace qi::labels; r_start %= '<' >> !lit('/') >> lexeme[+(char_ - '>')] >> '>'; r_end = "</" >> string(_r1) >> '>'; r_xml = r_start[_a = _1] >> r_end(_a); } }; int main() { const std::string storage("<foo></foo>"); std::string::const_iterator iter = storage.begin(); const std::string::const_iterator end = storage.end(); const bool r = qi::phrase_parse(iter, end, parser<std::string::const_iterator>(), ascii::space); return !(r && iter == end); } /*****************************************************************************************************/ When I try to compile this code with clang 4.1 (Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)) and Boost 1.52, it fails with the message: /opt/local/include/boost/spirit/home/qi/auxiliary/lazy.hpp:96:80: error: no type named 'type' in 'boost::result_of<boost::phoenix::actor<boost::phoenix::composite<boost::phoenix::detail::function_eval<1>, boost::fusion::vector<boost::phoenix::value<boost::spirit::terminal<boost::spirit::tag::char_code<boost::spirit::tag::string, boost::spirit::char_encoding::ascii>>>, boost::spirit::attribute<1>, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_>>> (boost::spirit::unused_type, boost::spirit::context<boost::fusion::cons<boost::spirit::unused_type &, boost::fusion::cons<std::__1::basic_string<char>, boost::fusion::nil>>, boost::fusion::vector0<void>>)>' typename boost::result_of<Function(unused_type, Context)>::type ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ When I saw this message, I thought of the note related to the Boost 1.52 revision (http://www.boost.org/users/news/a_special_note_for_boost_1_52_0_and_higher.html) which warns about the change of boost::result_of. Thus, I tried with Boost 1.51, but it also fails, though with a different error message (/usr/bin/../lib/c++/v1/list:212:9: error: field has incomplete type 'boost::spirit::info'). Also, this problem seems related to the inherited attribute passed to the r_end rule. Whenever I remove anything related to this attribute, it compiles. Finally, I should notice that it compiles with g++ 4.7. So, is this a problem with Spirit or clang? And, whatever causes the problem, is there any possible workaround (keeping the inherited attribute)? Regards, -- Alexandre Hamez |
|
From: Hartmut K. <hk...@bo...> - 2012-08-28 18:47:20
|
Please go ahead. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > -----Original Message----- > From: Daniel James [mailto:dn...@gm...] > Sent: Tuesday, August 28, 2012 1:05 PM > To: Spirit Development > Subject: [Spirit-devel] Minor fix for classic tests > > Hi, > > I was about to ask to check in a small fix for some classic spirit tests > which were failing, but it looks like I've already checked it in to trunk. > I think I accidentally committed it with some other changes for 1.52 from > git, so sorry about that. It's: > > https://svn.boost.org/trac/boost/changeset/79653/ > > The test results look okay, so can I merge to release? > > thanks, > > Daniel > > -------------------------------------------------------------------------- > ---- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Spirit-devel mailing list > Spi...@li... > https://lists.sourceforge.net/lists/listinfo/spirit-devel |
|
From: Daniel J. <dn...@gm...> - 2012-08-28 18:05:37
|
Hi, I was about to ask to check in a small fix for some classic spirit tests which were failing, but it looks like I've already checked it in to trunk. I think I accidentally committed it with some other changes for 1.52 from git, so sorry about that. It's: https://svn.boost.org/trac/boost/changeset/79653/ The test results look okay, so can I merge to release? thanks, Daniel |
6 messages has been excluded from this view by a project administrator.
