gmane.comp.parsers.spirit.devel

Feature request - attribute type should not bealtered for terminal rules

Vitaly Budovski — 2012-05-10T07:00:21

Hi all,

I've discussed this with Joel on IRC, but am posting this to the list
so others can comment.
Currently code such as this results in unexpected behaviour (for me).

#define BOOST_SPIRIT_ACTIONS_ALLOW_ATTR_COMPAT

int result;
parse(first, last, word[_val = if_else_(_1 > 1000u, -1, 5)], result);

This results in a warning about comparison between signed and unsigned
types (_1 > 1000u).
This is because the attribute type is converted to int to match the
type of the result variable, even though the type returned by word is
unsigned.

I would like to request a change in the behaviour for terminal rules,
if possible, so that this no-longer occurs. The type of _1 would now
be unsigned, and the comparison would happen without warnings. The two
possible branches output a type that is compatible with the type of
the output variable and so it succeeds.

The code below, however, should result in a warning or error:

int result;
parse(first, last, dword, result); // Difference in sign

or

unsigned result;
parse(first, last, qword, result); // Might overflow

Is this feasible?


Regards,

Vitaly

------------------------------------------------------------------------------
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] get_script method

Keshav Krity — 2012-05-05T06:39:09

I am trying to get the script name for a given Unicode value. This is the method I am calling.

http://www.boost.org/doc/libs/1_49_0/boost/spirit/home/support/char_encoding/unicode/query.hpp

inline properties::script get_script(::boost::uint32_t ch)
{
     return static_cast<properties::script>(detail::script_lookup(ch) & 0x3F);
}


enum script

{

.

.

.

common = 92,

unknown = 93

}



This api is not returning "common" script for characters such as space. The reason being the & operation with 0x3F. It restricts the return value to the range 0-63. Thus the values in the enum "script" greater that 63 will never be returned.

I fail to understand the logic behind this. Can somebody please explain the behavior, why the values are being restricted to top 64 only?

Thanks

------------------------------------------------------------------------------
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
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

RFC: Add support for parsing binary integers of userspecified lengths

Vitaly Budovski — 2012-05-01T11:22:54

Hi,

See the attached patch. Please not that it doesn't currently work
unless BOOST_SPIRIT_NO_PREDEFINED_TERMINALS is defined.
Can anyone suggest how I might fix this?


Regards,

Vitaly
------------------------------------------------------------------------------
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
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Keywords parser msvc 9.0 patch

teajay — 2012-04-09T18:34:47

Hello,

Here's a patch which fixes the issues I found with the last patch with 
msvc 9.0.

I also pushed the modifications on the ryppl git mirror of boost.

Regards,
Thomas Bernard
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Fields of type lex::char_

Ryan Molden — 2011-11-07T17:03:56

Sorry if this is duplicated, I originally sent it two days ago but I never
saw it appear back in my inbox as a list message (I actually haven't seen
*any* messages to this list yet...is it still active?), nor have I seen any
follow-up, so I thought I would send it again in case I hadn't been
properly registered as one allowed to send mail when I sent it the first
time.

I am having some problems having fields on my lexer of type lex::char_,
specifically I get the following errors in Visual Studio 2010 SP1 with
Boost 1.47

C2146: syntax error : missing ';' before identifier 'simple'
C2886: 'boost::spirit::standard::char_' : symbol cannot be used in a member
using-declaration
C4430: missing type specifier - int assumed. Note: C++ does not support
default-int
C2146: syntax error : missing ';' before identifier 'simple'
C2886: 'boost::spirit::standard::char_' : symbol cannot be used in a member
using-declaration
C4430: missing type specifier - int assumed. Note: C++ does not support
default-int

This is with the following simplified repro

#include <boost/spirit/include/lex_lexertl.hpp>

namespace lex = boost::spirit::lex;

template <typename Lexer>
struct lexer : lex::lexer<Lexer>
{
    lexer()
    {
        simple = lex::char_('.');
        this->self += simple;

        //This works, but I need/want to store the char_ object so I can
later reference its token ID from the parser level:
        //this->self += lex::char_('.');
        //
        //as does this (though in my real lexer I have LOTS of token_defs
and as I add more the compile time gets worse and worse):
        //
        //this->self += lex::token_def<>('.');
    }
    lex::char_ simple;
};

struct token_processor
{
    template <typename Token>
    bool operator()(Token const& t) const
    {
        return true;
    }
};

int main(int argc, char**argv[])
{
    std::string str (".");
    char const* first = str.c_str();
    char const* last = &first[str.size()];

     lexer<lex::lexertl::actor_lexer<> > l;
    bool r = lex::tokenize(first, last, l, token_processor());

    return 0;
}

Is this a Visual Studio 'issue' or something I am doing wrong?

Ryan
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Missing documentation file.

Daniel James — 2011-11-02T08:50:45

Hi,

The spirit repository doc build is failing at the moment, it looks
like 'libs/spirit/repository/doc/what_s_new.qbk' is missing in trunk.

------------------------------------------------------------------------------
RSA&#174; Conference 2012
Save $700 by Nov 18
Register now&#33;
http://p.sf.net/sfu/rsa-sfdev2dev1

Patch for qi::seek[] doc

TONGARI — 2011-10-27T16:18:33

Hi list,

There's an issue I overlooked in qi::seek[], in conjunction with sequence
(i.e. a >> b) and skipping.

Consequently, I decided to change my seek.cpp example, adding one note to
the doc that guides the users to deal with the case.

The complexity section is also modified, I hope I get it right this time.


Thanks!
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning< at >Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

[website] Please fix the link to nabble.

TONGARI — 2011-10-26T18:19:23

Hi,

The nabble link in the support page:
http://boost-spirit.com/home/feedback-and-support/

is dead (http://old.nabble.com/The-Spirit-Parser-Library-f3430.html).

Please change to
http://boost.2283326.n4.nabble.com/The-Spirit-Parser-Library-f2672581.html

Thanks.
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning< at >Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Strange behaviour of boost::spirit::get_current_line

Скуратович Сергей — 2011-10-26T08:47:04

Hello.

When content in range [current, upper_bound) contains multiple lines, get_current_line(lower_bound, current, upper_bound) returns iterator range, which includes all lines after current excluding last. Is this behaviour correct? I think,
the returning of only one current line is more expecting behaviour. The patch for that behaviour is attached.

Thanks.------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning< at >Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

Move generated spirit docs to the sandbox

Daniel James — 2011-10-16T09:53:05

Hi,

I removed the fusion docs from trunk a while back, and replaced them
with a redirect to the sourceforge sandbox. I think we agreed to do
this for spirit as well, but I didn't at the time as I hadn't set up
the index yet, but I set that up a little while ago, you can see the
documentation at:

http://boost-sandbox.sourceforge.net/libs/spirit/doc/html/index.html

So, is it okay to go ahead with this? I haven't noticed any comments
on the fusion change. Obviously, I'll make sure they're included
correctly in the beta (which should happen automatically).

Daniel

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct

Proposal for qi::seek[] directive, next step?

TONGARI — 2011-09-28T20:03:38

Hi,

In the thread:
http://boost.2283326.n4.nabble.com/Proposal-for-qi-seek-directive-td3830251.html

I've proposed this directive, and I'd like to know your opinions.
Though Thomas Bernard had provided another interesting idea, I'm not
proposing that ATM.

If you consider to accept this component, please let me know and tell me the
next step to take (e.g. submission).


Thanks.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel

New feature in Spirit.Lex

Julien Peeters — 2011-08-07T13:19:45

Hi readers,

Sorry for people who will receive this email twice, but I didn't know 
where is the best place to post this email.

Yesturday I've started using Spirit.Lex for building a simple 
source-code comment separator. For a given source file, the scanner 
would seperate code from comments matching a special start pattern (here 
"/*>"). Previously I wrote it using OCamllex, which is a very brillant 
lexer from the OCaml toolset.

Indeed, writing such a comment separator with OCamllex is very easy 
thanks to a specific feature that I would call "multi-context" lexer (I 
don't know the real name of this feature). But it is quiet hard to 
implement is using Spirit, at least using my current knowlegde of it. As 
much I understand, implementing it using Spirit would required to use a 
state variable to select the context in witch the lexer is in when it 
consumes some token. However, this not prevent from matching (and 
consuming) tokens that do not belong to the context.

Finally, I aim to use Spirit.Lex because OCamllex has some limitations. 
In particular, it does not allow dynamic addition of patterns, like Flex 
if I am not wrong. Then, one lexer must be generated for each comment 
patterns (e.g. when adding support for other languages than C/C++).

So as to illustrate my words, here is a code sample of what I did using 
OCamllex:

 >>> START OF SAMPLE CODE

{
   type expr = Code of string | SpecialComment of string

   let buffer = Buffer.create 32
}

let blank        = [' ' '\013' '\009' '\012']
let nl           = ['\010']
let not_nl       = [^ '\010']
let blank_nl     = [' ' '\013' '\009' '\012' '\010']
let not_blank_nl = [^ ' ' '\013' '\009' '\012' '\010']

rule main state = parse
   | blank* "/*>" blank_nl* "*/"
       {
         main state lexbuf
       }

   | blank* "/*>" blank_nl*
       {
         let state2 =
           if Buffer.length buffer > 0 then begin
             let code = Code (Buffer.contents buffer) in
             let _ = Buffer.reset buffer in
               code :: state
           end else
             state
         in
         let state3 = (special_comment lexbuf) :: state2 in
           main state3 lexbuf
       }

   | _ as c
       {
         Buffer.add_char buffer c;
         main state lexbuf
       }

   | eof
       {
         if Buffer.length buffer > 0 then
           let code = Buffer.contents buffer in
             Buffer.reset buffer;
             (Code code)::state
         else
           state
       }

and special_comment = parse
   | "*/" nl+
       {
         let com = SpecialComment (Buffer.contents buffer) in
           Buffer.reset buffer;
           com
       }

   | nl nl+ blank_nl*
       {
         Buffer.add_string buffer "\n\n";
         special_comment lexbuf
       }

   | blank_nl+
       {
         Buffer.add_char buffer ' ';
         special_comment lexbuf
       }

   | not_blank_nl as c
       {
         Buffer.add_char buffer c;
         special_comment lexbuf
       }

{
   let main () =
     let lexbuf = Lexing.from_channel stdin in
     let result = main [] lexbuf in
       List.iter
         ( fun item ->
             match item with
               | Code str -> Printf.fprintf stdout "<code>%s</code>" str
               | SpecialComment str -> Printf.fprintf stderr 
"<special>%s</special>" str )
         result

   let _ = main ()
}

<<< END OF SAMPLE CODE

There are two rules: main and special_comment. The lexer starts in the 
main rule when it is first called. When the pattern "/*>" is matched, 
the lexer switches in the special_comment rule and returns when the 
pattern "*/" is matched.

The purpose of this post is to ask to the Spirit developers if the 
current implementation allows such a "multi-context" construct. If it's 
the case I would appreciate any help for that. If it's not, I would 
consider starting and/or participating to the implementation of this 
feature if you consider it's relevant. However, I would need some help 
at the beginning because I am new to Spirit.Lex internals.

In terms of implementation, I think it is like building as many macro 
states as there are rule in the semantic of Ocamllex. Each macro state 
is itself a state machine in the semantic of Spirit.Lex. Then, semantic 
actions of the lexer can allow to jump (or switch) between macro states.

Feel free to ask any question if I was not clear enough or if you are 
not familiar with OCaml/OCamllex syntax ans semantics.

Best regards,

Julien.

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1

[Spirit Devel] TRUNK IS BROKEN

Robert Nelson — 2011-05-21T23:56:27

I just updated to trunk and I believe that an update to proto is
causing serious problems

Thanks
--Robert Nelson

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay

[Spirit Devel] bug in karma_rule.hpp

Robert Nelson — 2011-05-07T00:52:39

To reduce compiler includes, I attempted to use karma_rule.hpp instead
of the the full blown karma.hpp

The following minimal program fails to compile on boost trunk:

#include <boost/spirit/include/karma_rule.hpp>

int main()
{
}

Thanks
--Robert Nelson

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd

mini-xml

Michael Roper — 2011-04-19T04:51:17

I am trying to extend the Mini-XML example that is in the Spirit::Qi
documentation. I am having trouble with parsing elements with
attributes. The grammar and the rule declarations follow.

            text = lexeme[+(char_ - '<')        [_val += _1]];
            node = (xml | text)                 [_val = _1];


    Name  = NameStartChar *(NameChar);
    NameStartChar = qi::char_("a-zA-Z_");
    Digit = qi::char_("0-9");

    NameChar      = (NameStartChar | '-' | '.' | ':' | Digit);


            start_tag =
                    '<'
            >>  Name
    >>  *(wspc >> attribute)
    >> -wspc
    >> '>';

    wspc = ('\r'|'\t'|'\n'|' ');

    attribute = Name >> '=' >> AttValue;

    AttValue = "'" >> -Name >> "'";

            end_tag =
                    "</"
                >>  string(_r1)
                >>  '>'
            ;

            xml =
                    start_tag                   [at_c<0>(_val) = _1]
                >>  *node                       [push_back(at_c<1>(_val), _1)]
                >>  end_tag(at_c<0>(_val))
            ;
        }



      qi::rule<Iterator, mini_xml(), ascii::space_type> xml;
      qi::rule<Iterator, mini_xml_node(), ascii::space_type> node;
      qi::rule<Iterator, std::string(), ascii::space_type> text;
      qi::rule<Iterator, std::string(), ascii::space_type> start_tag;
      qi::rule<Iterator, void(std::string), ascii::space_type> end_tag;
      qi::rule<Iterator, std::string()> Name;
      qi::rule<Iterator, std::string()> NameStartChar;
      qi::rule<Iterator, std::string()> Digit;
      qi::rule<Iterator, std::string()> NameChar;
      qi::rule<Iterator, std::string()> wspc;
      qi::rule<Iterator, std::string()> attribute;
      qi::rule<Iterator, std::string()> AttValue;



Thanks very much for your time,
Michael.

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev

spirit grammar graphs

Gordon Woodhull — 2011-03-30T22:26:11

Hi Spirit Developers,

I am working on the MPL.Graph paper & talk for BoostCon. I want to say a little bit about Spirit grammar rules, because I think it's a good example of a compile-time graph that many people are familiar with.

So I'd like to summarize how type erasure and object references are used in Spirit to produce a graph when expressions only allow us trees.

I will write/say something like this: (needs editing but is this basically correct?)

Spirit generates a compile-time graph of function objects calling each other by tying together nodes of expression trees by common rule references. The rules use type erasure to make it easy to construct the objects without having to specify insanely complicated types; type erasure is used as a substitute for C++0x "auto". The technique also allows rule objects to remain uninitialized so they can be referred to before they are defined.

Next, I was going to ask a simple question about type erasure, but I found the answer in the Spirit Rationale. So I'll ask a more complex question. :-)

Since type erasure blocks inlining, isn't there some kind of type unerasure that can bring it back? Or would that require templated virtual functions?

Obviously I have an ulterior motive: if it is possible, then I want to be able to build compile-time graphs using the same nice syntax Spirit uses. If it's not possible, then I want to see if Spirit could use compile-time graphs to solve the same problem with greater efficiency (and perhaps better clarity).

Thanks,
Gordon

------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

Fusion.Graph?

Gordon Woodhull — 2011-03-30T22:26:13

Hi Fusion Developers,

I am posting to the Spirit list since I think all Fusion developers are Spirit developers.  Please let me know if I have missed someon.

Can I hear some ayes or nays from the Fusion authors for calling a proposed library for simple heterogeneous graph data structures Fusion.Graph?  

I think this name provides the easiest way to explain what the library does: it produces a network of heterogeneous objects which contain pointers or containers of pointers to other objects in the network.  I am not convinced that this is the only way heterogenous graphs could be implemented, but I think it is the simplest.

There is a rudimentary implementation of it available in the metagraph area of the sandbox, which is less than 100 lines because it a very straightforward application of Fusion maps and STL containers.  I have started to implement a version of the BGL graph concepts for this data structure.  It will grow with whatever graph algorithms are appropriate, but the class of heterogenous graph algorithms hasn't really been defined yet.*  

I expect to have something ready for review in the next year, after MPL.Graph.

The Metagraph that I occasionally mutter about, is one level of abstraction above this.  Fusion.Graph is the implementation class for that one, which cleans up the picture by overlaying patterns.

Does this sound like a good idea, or should I find another moniker to describe this work-in-progress?

Thanks,
Gordon

* Note for example that a full depth first search of a Fusion.Graph iterates for each node on a fusion container of pointers and containers of pointers, recursing on each pointer to another node of a different type.
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf

Spirit Attribute Transform Breaks in Darwin gcc-4.2.1

Dean Michael Berris — 2011-03-28T20:03:28

Hi Everyone,

Has anybody been developing on Darwin with the gcc-4.2.1 compiler? I
ask because I tried building cpp-netlib on darwin and just now I find
out that Spirit gets confused with the transformation extension point,
similar to the bug I reported last time. I'm running the regression
test suite now but it would be good to know if there's a known issue
with the platform I'm using at the moment.

Thanks and I hope to hear from you soon!

SPIRIT_VERSION 0x205 -- Should be 0x2050?

Dean Michael Berris — 2011-03-27T03:27:45

Good day guys, I just checked out the latest Spirit from trunk and I
have code that switches on SPIRIT_VERSION >= 0x2030, which breaks
because the latest version is less than the older version. Should the
version be 0x2050?

Attribute compatibility and Alternatives

Joel de Guzman — 2011-02-19T03:17:57

Hi,

This code: http://tinyurl.com/65vjrgg demonstrates the calculator
automatically generating without decorations and with no semantic
actions; just pure attribute propagation.

I will not bother going into the details of how this example works
now, since I do intend to do a couple of tutorials touching on
this. So, please don't worry if this post does not make sense to
you yet. At the very least, let me just say that this *IS* important.
This post is targeting mostly the advanced users and the developers.

Various new features made this possible. Hartmut's recent work that
unifies handling of sequences and loops (e.g. kleene) clearly helped
in achieving this. At that point, I thought about modernizing the
calc-ast example to see how we've come so far in terms of attribute
handling: and all its magic!

At first try, it almost worked! Except for one remaining problem:
Alternatives still do not respect attribute compatibility. So,
I took the challenge and now we have attribute compatibility on
alternatives (also see my recent post on Attribute compatibility
and semantic actions). With this define:

     BOOST_SPIRIT_ALTERNATIVES_ALLOW_ATTR_COMPAT

Your alternatives can now allow attribute compatibility. Previously,
alternatives always(!) synthesize the expected attributes of its
nodes. With the new code, the new calc-ast example (link above)
works like a charm without any tricks and workarounds.

*Warning: more hard-core notes ahead*

It's not perfect though, and I doubt it will ever be. Here's why:
Given an alternative expression:

     a | b | c

with the expected attributes A, B and C, the expected attribute is:

     variant<A, B, C>

However, as much as we love attribute compatibility, we want to use
attributes Ac, Bc and Cc which are compatible with A, B and C
respectively. Hence, we want to pass in a compatible attribute of:

     variant<Ac, Bc, Cc>

Easy, just do a one-to-one correspondence with the variant types
and the expected types, you say? No! Often, the types in the variant
do not correspond that easily. Consider this:

     int_ | char_('x') | char('y')

and this variant:

     variant<int, char>

That variant should very well be compatible! So the tricky part here
is in determining which of the variant type corresponds to the
alternative node.

The initial idea was to have a trait that answers the question: is
component, C, compatible with attribute A? But that is a very tricky
answer. Such a trait will have to capture every detail of how Spirit
deals with attribute compatibility in terms of traits. Difficult!
And thinking about it more, it's not even usable. Here's why:
consider the code above. Here, the char_ parser *can* and will accept
an int! IOTW, char_ is compatible with int!

So, my solution is to simplify with a stricter trait:

     ///////////////////////////////////////////////////////////////////////////
     // Find out if T can be a substitute for Expected attribute
     ///////////////////////////////////////////////////////////////////////////
     template <typename T, typename Expected, typename Enable = void>
     struct is_substitute;

This trait returns true_ if T is a substitute with Expected (attribute).
Right now, it has to be

1) an exact match T == Expected
2) An optional with type T that is a substitute with another optional
    with Expected (attribute).
3) Both T and Expected are fusion sequences with the same number of
    elements and with element types of T that are substitutes for the
    target Expected element types.

So far, this has worked with the example, but might need to be refined
and expanded to handle more cases (e.g. std containers?).

Anyway, this has already been longer than I intended to write, so I'll
end now. Comments, suggestion please!

Regards,

iter_pos parser in repository is broken.

Robert Nelson — 2011-02-14T19:22:17

Due to the recent change of the BOOST_SPIRIT_TERMINAL macro, all
custom parsers that previously worked are now broken.

Attached is a very simple program demonstrating this problem.  I think
the macro should be changed back if at all possible as it breaks all
custom parsers.  In any case, please at least fix the iter_pos parser
so we have a working example of a custom parser.

Thanks
--Robert Nelson
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb_______________________________________________
Spirit-devel mailing list
Spirit-devel< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spirit-devel