>> operator, fusion vector, and default constructible attributes

classic Classic list List threaded Threaded
21 messages Options
12
MM
Reply | Threaded
Open this post in threaded view
|

>> operator, fusion vector, and default constructible attributes

MM
Hi,

Part of my rule is a sequence operator of:

start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val = pnx::construct( _3, _2, _1) ];

grmr1's attribute is T1(), where T1 is _not_ default constructible.

Using grmr1 alone in 
qi::parse( begin,end, grmr1(), attributeref ) 
works perfectly.

However the above start_ fails to compile, and somewhere in the compile error output,
g++ 4.8.3 c++11 says that fusion vector3 fails to default construct T1 and T2 and T3

Is there a way to work around this?

Regards,

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
MM
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

MM
On 24 September 2014 18:15, MM <[hidden email]> wrote:
Hi,

Part of my rule is a sequence operator of:

start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val = pnx::construct( _3, _2, _1) ];

grmr1's attribute is T1(), where T1 is _not_ default constructible.

Using grmr1 alone in 
qi::parse( begin,end, grmr1(), attributeref ) 
works perfectly.

However the above start_ fails to compile, and somewhere in the compile error output,
g++ 4.8.3 c++11 says that fusion vector3 fails to default construct T1 and T2 and T3

Is there a way to work around this?

Regards,

A snippet from the compile error is below. T0 T1 and T2 are in my case not default c'tible.

/usr/include/boost/fusion/container/vector/detail/preprocessed/vector10.hpp: 262:19
  required from 'boost::fusion::vector3<T0,T1,T2>::vector3() 
/usr/include/boost/utility/value_init.hpp:78:12   required from boost::initialized<T>::wrapper::wrapper() 
...
/usr/include/boost/spirit/home/support/attributes.hpp:: 974:66:
 required from 'static Attribute boost::spirit::traits::make_attribute<Attribute, ActualAttribute>::call(boost::spirit::unused_type) [ with 
  Attribute = fusion::vector3<T0,T1,T2>
  ActualAttribute- const spirit::unused_type]

I do not control these types T0, T1, T2 so I can't add default ctors to them.

MM


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

Joel de Guzman
In reply to this post by MM
On 9/25/14, 1:15 AM, MM wrote:

> Hi,
>
> Part of my rule is a sequence operator of:
>
>     start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val = pnx::construct( _3, _2, _1) ];
>
>
> grmr1's attribute is T1(), where T1 is _not_ default constructible.
>
> Using grmr1 alone in
>
>     qi::parse( begin,end, grmr1(), attributeref )
>
> works perfectly.
>
> However the above start_ fails to compile, and somewhere in the compile error output,
> g++ 4.8.3 c++11 says that fusion vector3 fails to default construct T1 and T2 and T3
>
> Is there a way to work around this?

Sorry no. Rule attributes are required to be default constructible
because they are created in the stack in each non-terminal *before*
calling the RHS of the rule.

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
MM
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

MM
On 25 September 2014 09:51, Joel de Guzman <[hidden email]> wrote:
On 9/25/14, 1:15 AM, MM wrote:
> Hi,
>
> Part of my rule is a sequence operator of:
>
>     start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val = pnx::construct( _3, _2, _1) ];
>
>
> grmr1's attribute is T1(), where T1 is _not_ default constructible.
>
> Using grmr1 alone in
>
>     qi::parse( begin,end, grmr1(), attributeref )
>
> works perfectly.
>
> However the above start_ fails to compile, and somewhere in the compile error output,
> g++ 4.8.3 c++11 says that fusion vector3 fails to default construct T1 and T2 and T3
>
> Is there a way to work around this?

Sorry no. Rule attributes are required to be default constructible
because they are created in the stack in each non-terminal *before*
calling the RHS of the rule.

Regards,
--
Joel de Guzman

Can I use  boost::optional<T> instead of T as attribute of grmr, to work around this, where I would have a trivial semantic action like this

grmr1opt whose synthetized attribute is boost::optional<T>
grmr1 whose synthetized attribute is boost::optional<T>

grmr1opt = grmr1 [ _val = _1 ];
...
start_ = ( grmr1opt  >> grmr2opt  >> grmr3opt  ) [ _val = pnx::construct( *_3, *_2, *_1) ];

or something like this?

MM

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

Joel de Guzman
On 9/25/14, 5:14 PM, MM wrote:

> On 25 September 2014 09:51, Joel de Guzman <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 9/25/14, 1:15 AM, MM wrote:
>      > Hi,
>      >
>      > Part of my rule is a sequence operator of:
>      >
>      >     start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val = pnx::construct( _3, _2, _1) ];
>      >
>      >
>      > grmr1's attribute is T1(), where T1 is _not_ default constructible.
>      >
>      > Using grmr1 alone in
>      >
>      >     qi::parse( begin,end, grmr1(), attributeref )
>      >
>      > works perfectly.
>      >
>      > However the above start_ fails to compile, and somewhere in the compile error output,
>      > g++ 4.8.3 c++11 says that fusion vector3 fails to default construct T1 and T2 and T3
>      >
>      > Is there a way to work around this?
>
>     Sorry no. Rule attributes are required to be default constructible
>     because they are created in the stack in each non-terminal *before*
>     calling the RHS of the rule.
>
>     Regards,
>     --
>     Joel de Guzman
>
>
> Can I use  boost::optional<T> instead of T as attribute of grmr, to work around this,
> where I would have a trivial semantic action like this
>
> grmr1opt whose synthetized attribute is boost::optional<T>
> grmr1 whose synthetized attribute is boost::optional<T>
>
>     grmr1opt = grmr1 [ _val = _1 ];
>     ...
>     start_ = ( grmr1opt  >> grmr2opt  >> grmr3opt  ) [ _val = pnx::construct( *_3, *_2,
>     *_1) ];
>
>
> or something like this?

I think so, yes.

Regards,
--
Joel de Guzman
http://www.ciere.com
http://boost-spirit.com
http://www.cycfi.com/


------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
MM
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

MM
In reply to this post by MM
On 25 September 2014 11:03, Joel de Guzman <[hidden email]> wrote:
On 9/25/14, 5:14 PM, MM wrote:
> On 25 September 2014 09:51, Joel de Guzman <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 9/25/14, 1:15 AM, MM wrote:
>      > Hi,
>      >
>      > Part of my rule is a sequence operator of:
>      >
>      >     start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val = pnx::construct( _3, _2, _1) ];
>      >
>      >
>      > grmr1's attribute is T1(), where T1 is _not_ default constructible.
>      >
>      > Using grmr1 alone in
>      >
>      >     qi::parse( begin,end, grmr1(), attributeref )
>      >
>      > works perfectly.
>      >
>      > However the above start_ fails to compile, and somewhere in the compile error output,
>      > g++ 4.8.3 c++11 says that fusion vector3 fails to default construct T1 and T2 and T3
>      >
>      > Is there a way to work around this?
>
>     Sorry no. Rule attributes are required to be default constructible
>     because they are created in the stack in each non-terminal *before*
>     calling the RHS of the rule.

>
> Can I use  boost::optional<T> instead of T as attribute of grmr, to work around this,
> where I would have a trivial semantic action like this
>
> grmr1opt whose synthetized attribute is boost::optional<T>
> grmr1 whose synthetized attribute is boost::optional<T>
>
>     grmr1opt = grmr1 [ _val = _1 ];
>     ...
>     start_ = ( grmr1opt  >> grmr2opt  >> grmr3opt  ) [ _val = pnx::construct( *_3, *_2,
>     *_1) ];
>
>
> or something like this?

I think so, yes.

Regards,
--
Joel de Guzman


Unfortunately, even just in 
grmr1opt = grmr1 [ _val = _1 ]
 the attrib of _1 requires to be default constructible. 

The same sort of compile error happens with value_init which tries to default construct the attrib of _1 (which is T), the attrib of _val being compatible with boost::optional<T>

Parsing grmr1 with qi::parse, passing an existing instance of T, succeeds.

I would have thought    _val = _1     is lazily equivalent to calling      boost::optional<T>::operator( const T& )
 
I have tried with these 2:
grmr1opt = grmr1 [ _val = pnx::construct<T>(_1) ]
and
grmr1opt = grmr1 [ _val = pnx::ref(_1) ]

Both bark for the same reason....

MM

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
MM
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

MM
On 25 September 2014 15:55, MM <[hidden email]> wrote:
On 25 September 2014 11:03, Joel de Guzman <[hidden email]> wrote:
On 9/25/14, 5:14 PM, MM wrote:
> On 25 September 2014 09:51, Joel de Guzman <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 9/25/14, 1:15 AM, MM wrote:
>      > Hi,
>      >
>      > Part of my rule is a sequence operator of:
>      >
>      >     start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val = pnx::construct( _3, _2, _1) ];
>      >
>      >
>      > grmr1's attribute is T1(), where T1 is _not_ default constructible.
>      >
>      > Using grmr1 alone in
>      >
>      >     qi::parse( begin,end, grmr1(), attributeref )
>      >
>      > works perfectly.
>      >
>      > However the above start_ fails to compile, and somewhere in the compile error output,
>      > g++ 4.8.3 c++11 says that fusion vector3 fails to default construct T1 and T2 and T3
>      >
>      > Is there a way to work around this?
>
>     Sorry no. Rule attributes are required to be default constructible
>     because they are created in the stack in each non-terminal *before*
>     calling the RHS of the rule.

>
> Can I use  boost::optional<T> instead of T as attribute of grmr, to work around this,
> where I would have a trivial semantic action like this
>
> grmr1opt whose synthetized attribute is boost::optional<T>
> grmr1 whose synthetized attribute is boost::optional<T>
>
>     grmr1opt = grmr1 [ _val = _1 ];
>     ...
>     start_ = ( grmr1opt  >> grmr2opt  >> grmr3opt  ) [ _val = pnx::construct( *_3, *_2,
>     *_1) ];
>
>
> or something like this?

I think so, yes.

Regards,
--
Joel de Guzman


Unfortunately, even just in 
grmr1opt = grmr1 [ _val = _1 ]
 the attrib of _1 requires to be default constructible. 

The same sort of compile error happens with value_init which tries to default construct the attrib of _1 (which is T), the attrib of _val being compatible with boost::optional<T>

Parsing grmr1 with qi::parse, passing an existing instance of T, succeeds.

I would have thought    _val = _1     is lazily equivalent to calling      boost::optional<T>::operator( const T& )
 
I have tried with these 2:
grmr1opt = grmr1 [ _val = pnx::construct<T>(_1) ]
and
grmr1opt = grmr1 [ _val = pnx::ref(_1) ]

Both bark for the same reason....

MM

I have been told to use the customization point transform_attribute. 
I can't quite see which would be the exposed and the transformed type.
Can it help to work around no default ctor of T?

Regards,

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

cppljevans
On 09/25/2014 06:30 PM, MM wrote:

> On 25 September 2014 15:55, MM <[hidden email]> wrote:
>
>> On 25 September 2014 11:03, Joel de Guzman <[hidden email]> wrote:
>>
>>> On 9/25/14, 5:14 PM, MM wrote:
>>>> On 25 September 2014 09:51, Joel de Guzman <[hidden email] <mailto:
>>> [hidden email]>> wrote:
>>>>
>>>>     On 9/25/14, 1:15 AM, MM wrote:
>>>>      > Hi,
>>>>      >
>>>>      > Part of my rule is a sequence operator of:
>>>>      >
>>>>      >     start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val =
>>> pnx::construct( _3, _2, _1) ];
>>>>      >
>>>>      >
>>>>      > grmr1's attribute is T1(), where T1 is _not_ default
>>> constructible.
>>>>      >
>>>>      > Using grmr1 alone in
>>>>      >
>>>>      >     qi::parse( begin,end, grmr1(), attributeref )
>>>>      >
>>>>      > works perfectly.
>>>>      >
>>>>      > However the above start_ fails to compile, and somewhere in the
>>> compile error output,
>>>>      > g++ 4.8.3 c++11 says that fusion vector3 fails to default
>>> construct T1 and T2 and T3
>>>>      >
>>>>      > Is there a way to work around this?
>>>>
>>>>     Sorry no. Rule attributes are required to be default constructible
>>>>     because they are created in the stack in each non-terminal *before*
>>>>     calling the RHS of the rule.
>>>
>>>>
>>>> Can I use  boost::optional<T> instead of T as attribute of grmr, to
>>> work around this,
>>>> where I would have a trivial semantic action like this
>>>>
>>>> grmr1opt whose synthetized attribute is boost::optional<T>
>>>> grmr1 whose synthetized attribute is boost::optional<T>
>>>>
>>>>     grmr1opt = grmr1 [ _val = _1 ];
>>>>     ...
>>>>     start_ = ( grmr1opt  >> grmr2opt  >> grmr3opt  ) [ _val =
>>> pnx::construct( *_3, *_2,
>>>>     *_1) ];
>>>>
>>>>
>>>> or something like this?
>>>
>>> I think so, yes.
>>>
>>> Regards,
>>> --
>>> Joel de Guzman
>>>
>>>
>> Unfortunately, even just in
>>
>>> grmr1opt = grmr1 [ _val = _1 ]
>>
>>  the attrib of _1 requires to be default constructible.
>>
>> The same sort of compile error happens with value_init which tries to
>> default construct the attrib of _1 (which is T), the attrib of _val being
>> compatible with boost::optional<T>
>>
>> Parsing grmr1 with qi::parse, passing an existing instance of T, succeeds.
>>
>> I would have thought    _val = _1     is lazily equivalent to calling
>>  boost::optional<T>::operator( const T& )
>>
>> I have tried with these 2:
>>
>>> grmr1opt = grmr1 [ _val = pnx::construct<T>(_1) ]
>>
>> and
>>
>>> grmr1opt = grmr1 [ _val = pnx::ref(_1) ]
>>
>>
>> Both bark for the same reason....
>>
>> MM
>>
>
> I have been told to use the customization point transform_attribute.
> I can't quite see which would be the exposed and the transformed type.
> Can it help to work around no default ctor of T?
>
> Regards,

Can you post the code somehow?




------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
MM
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

MM
On 26 September 2014 14:20, Larry Evans <[hidden email]> wrote:
On 09/25/2014 06:30 PM, MM wrote:
> On 25 September 2014 15:55, MM <[hidden email]> wrote:
>
>> On 25 September 2014 11:03, Joel de Guzman <[hidden email]> wrote:
>>
>>> On 9/25/14, 5:14 PM, MM wrote:
>>>> On 25 September 2014 09:51, Joel de Guzman <[hidden email] <mailto:
>>> [hidden email]>> wrote:
>>>>
>>>>     On 9/25/14, 1:15 AM, MM wrote:
>>>>      > Hi,
>>>>      >
>>>>      > Part of my rule is a sequence operator of:
>>>>      >
>>>>      >     start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val =
>>> pnx::construct( _3, _2, _1) ];
>>>>      >
>>>>      >
>>>>      > grmr1's attribute is T1(), where T1 is _not_ default
>>> constructible.
>>>>      >
>>>>      > Using grmr1 alone in
>>>>      >
>>>>      >     qi::parse( begin,end, grmr1(), attributeref )
>>>>      >
>>>>      > works perfectly.
>>>>      >
>>>>      > However the above start_ fails to compile, and somewhere in the
>>> compile error output,
>>>>      > g++ 4.8.3 c++11 says that fusion vector3 fails to default
>>> construct T1 and T2 and T3
>>>>      >
>>>>      > Is there a way to work around this?
>>>>
>>>>     Sorry no. Rule attributes are required to be default constructible
>>>>     because they are created in the stack in each non-terminal *before*
>>>>     calling the RHS of the rule.
>>>
>>>>
>>>> Can I use  boost::optional<T> instead of T as attribute of grmr, to
>>> work around this,
>>>> where I would have a trivial semantic action like this
>>>>
>>>> grmr1opt whose synthetized attribute is boost::optional<T>
>>>> grmr1 whose synthetized attribute is boost::optional<T>
>>>>
>>>>     grmr1opt = grmr1 [ _val = _1 ];
>>>>     ...
>>>>     start_ = ( grmr1opt  >> grmr2opt  >> grmr3opt  ) [ _val =
>>> pnx::construct( *_3, *_2,
>>>>     *_1) ];
>>>>
>>>>
>>>> or something like this?
>>>
>>> I think so, yes.
>>>
>>> Regards,
>>> --
>>> Joel de Guzman
>>>
>>>
>> Unfortunately, even just in
>>
>>> grmr1opt = grmr1 [ _val = _1 ]
>>
>>  the attrib of _1 requires to be default constructible.
>>
>> The same sort of compile error happens with value_init which tries to
>> default construct the attrib of _1 (which is T), the attrib of _val being
>> compatible with boost::optional<T>
>>
>> Parsing grmr1 with qi::parse, passing an existing instance of T, succeeds.
>>
>> I would have thought    _val = _1     is lazily equivalent to calling
>>  boost::optional<T>::operator( const T& )
>>
>> I have tried with these 2:
>>
>>> grmr1opt = grmr1 [ _val = pnx::construct<T>(_1) ]
>>
>> and
>>
>>> grmr1opt = grmr1 [ _val = pnx::ref(_1) ]
>>
>>
>> Both bark for the same reason....
>>
>> MM
>>
>
> I have been told to use the customization point transform_attribute.
> I can't quite see which would be the exposed and the transformed type.
> Can it help to work around no default ctor of T?
>
> Regards,

Can you post the code somehow?



The 3 grammars for day, month and year can be used to qis::parse( begin,end,  greg_day_<>(), ...a ref to a greg_day );

But the grammar for date fails to compile because the _1 , _2 and _3 (greg_day, month, date types don't have a def ctor.

I have tried to use optional, and play with pnx::ref, played with attr_cast and transform_attribute.... no success

g++4.8.3 / c++11/ SPIRIT_USE_PHOENIXv3 

MM

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

cppljevans
On 09/26/2014 08:48 AM, MM wrote:

> On 26 September 2014 14:20, Larry Evans <[hidden email]> wrote:
>
>> On 09/25/2014 06:30 PM, MM wrote:
>>> On 25 September 2014 15:55, MM <[hidden email]> wrote:
>>>
>>>> On 25 September 2014 11:03, Joel de Guzman <[hidden email]> wrote:
>>>>
>>>>> On 9/25/14, 5:14 PM, MM wrote:
>>>>>> On 25 September 2014 09:51, Joel de Guzman <[hidden email] <mailto:
>>>>> [hidden email]>> wrote:
>>>>>>
>>>>>>     On 9/25/14, 1:15 AM, MM wrote:
>>>>>>      > Hi,
>>>>>>      >
>>>>>>      > Part of my rule is a sequence operator of:
>>>>>>      >
>>>>>>      >     start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val =
>>>>> pnx::construct( _3, _2, _1) ];
>>>>>>      >
>>>>>>      >
>>>>>>      > grmr1's attribute is T1(), where T1 is _not_ default
>>>>> constructible.
>>>>>>      >
>>>>>>      > Using grmr1 alone in
>>>>>>      >
>>>>>>      >     qi::parse( begin,end, grmr1(), attributeref )
>>>>>>      >
>>>>>>      > works perfectly.
>>>>>>      >
>>>>>>      > However the above start_ fails to compile, and somewhere in the
>>>>> compile error output,
>>>>>>      > g++ 4.8.3 c++11 says that fusion vector3 fails to default
>>>>> construct T1 and T2 and T3
>>>>>>      >
>>>>>>      > Is there a way to work around this?
>>>>>>
>>>>>>     Sorry no. Rule attributes are required to be default constructible
>>>>>>     because they are created in the stack in each non-terminal
>> *before*
>>>>>>     calling the RHS of the rule.
>>>>>
>>>>>>
>>>>>> Can I use  boost::optional<T> instead of T as attribute of grmr, to
>>>>> work around this,
>>>>>> where I would have a trivial semantic action like this
>>>>>>
>>>>>> grmr1opt whose synthetized attribute is boost::optional<T>
>>>>>> grmr1 whose synthetized attribute is boost::optional<T>
>>>>>>
>>>>>>     grmr1opt = grmr1 [ _val = _1 ];
>>>>>>     ...
>>>>>>     start_ = ( grmr1opt  >> grmr2opt  >> grmr3opt  ) [ _val =
>>>>> pnx::construct( *_3, *_2,
>>>>>>     *_1) ];
>>>>>>
>>>>>>
>>>>>> or something like this?
>>>>>
>>>>> I think so, yes.
>>>>>
>>>>> Regards,
>>>>> --
>>>>> Joel de Guzman
>>>>>
>>>>>
>>>> Unfortunately, even just in
>>>>
>>>>> grmr1opt = grmr1 [ _val = _1 ]
>>>>
>>>>  the attrib of _1 requires to be default constructible.
>>>>
>>>> The same sort of compile error happens with value_init which tries to
>>>> default construct the attrib of _1 (which is T), the attrib of _val
>> being
>>>> compatible with boost::optional<T>
>>>>
>>>> Parsing grmr1 with qi::parse, passing an existing instance of T,
>> succeeds.
>>>>
>>>> I would have thought    _val = _1     is lazily equivalent to calling
>>>>  boost::optional<T>::operator( const T& )
>>>>
>>>> I have tried with these 2:
>>>>
>>>>> grmr1opt = grmr1 [ _val = pnx::construct<T>(_1) ]
>>>>
>>>> and
>>>>
>>>>> grmr1opt = grmr1 [ _val = pnx::ref(_1) ]
>>>>
>>>>
>>>> Both bark for the same reason....
>>>>
>>>> MM
>>>>
>>>
>>> I have been told to use the customization point transform_attribute.
>>> I can't quite see which would be the exposed and the transformed type.
>>> Can it help to work around no default ctor of T?
>>>
>>> Regards,
>>
>> Can you post the code somehow?
>>
>>
> http://codepad.org/3kQzYt4E
>
> The 3 grammars for day, month and year can be used to qis::parse(
> begin,end,  greg_day_<>(), ...a ref to a greg_day );
>
> But the grammar for date fails to compile because the _1 , _2 and _3
> (greg_day, month, date types don't have a def ctor.

I assume you mean by greg_day, month, date, you mean the member
variables:

  greg_day_<Iterator> date_<Iterator>::day_rule_;
  greg_month_<Iterator> date_<Iterator>::month_rule_;
  greg_year_<Iterator> ydate_<Iterator>::ear_rule_;

Which can't be constructed because their attributes:

  gregorian::greg_day
  gregorian::greg_month
  gregorian::greg_year

cannot be default constructed.
>
> I have tried to use optional,

So you've tried chaning the attributes to:

  boost::optional<gregorian::greg_day>
  boost::optional<gregorian::greg_month>
  boost::optional<gregorian::greg_year>

and it still failed to commpile?  Based on:

  boost::optional<const Resource> resource_;
  .
  .
  .
  optional's default constructor creates an uninitialized optional.
  No  call to Resource's default constructor is attempted.

from:


http://www.boost.org/doc/libs/master/libs/optional/doc/html/boost_optional/quick_start/optional_data_members.html

I would have expected all to compile since, "No call to Resource's
default constructor is attempted" means, in your case,
"No call to greg_day, greg_month, or greg_year's default
constructors are attempted".

In that case, I'm stumped.

> and play with pnx::ref, played with attr_cast
> and transform_attribute.... no success
>
> g++4.8.3 / c++11/ SPIRIT_USE_PHOENIXv3
>
> MM
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Spirit-general mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/spirit-general
>



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
MM
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

MM
On 26 September 2014 15:34, Larry Evans <[hidden email]> wrote:
On 09/26/2014 08:48 AM, MM wrote:
> On 26 September 2014 14:20, Larry Evans <[hidden email]> wrote:
>
>> On 09/25/2014 06:30 PM, MM wrote:
>>> On 25 September 2014 15:55, MM <[hidden email]> wrote:
>>>
>>>> On 25 September 2014 11:03, Joel de Guzman <[hidden email]> wrote:
>>>>
>>>>> On 9/25/14, 5:14 PM, MM wrote:
>>>>>> On 25 September 2014 09:51, Joel de Guzman <[hidden email] <mailto:
>>>>> [hidden email]>> wrote:
>>>>>>
>>>>>>     On 9/25/14, 1:15 AM, MM wrote:
>>>>>>      > Hi,
>>>>>>      >
>>>>>>      > Part of my rule is a sequence operator of:
>>>>>>      >
>>>>>>      >     start_ = ( grmr1 >> grmr2 >> grmr3 ) [ _val =
>>>>> pnx::construct( _3, _2, _1) ];
>>>>>>      >
>>>>>>      >
>>>>>>      > grmr1's attribute is T1(), where T1 is _not_ default
>>>>> constructible.
>>>>>>      >
>>>>>>      > Using grmr1 alone in
>>>>>>      >
>>>>>>      >     qi::parse( begin,end, grmr1(), attributeref )
>>>>>>      >
>>>>>>      > works perfectly.
>>>>>>      >
>>>>>>      > However the above start_ fails to compile, and somewhere in the
>>>>> compile error output,
>>>>>>      > g++ 4.8.3 c++11 says that fusion vector3 fails to default
>>>>> construct T1 and T2 and T3
>>>>>>      >
>>>>>>      > Is there a way to work around this?
>>>>>>
>>>>>>     Sorry no. Rule attributes are required to be default constructible
>>>>>>     because they are created in the stack in each non-terminal
>> *before*
>>>>>>     calling the RHS of the rule.
>>>>>
>>>>>>
>>>>>> Can I use  boost::optional<T> instead of T as attribute of grmr, to
>>>>> work around this,
>>>>>> where I would have a trivial semantic action like this
>>>>>>
>>>>>> grmr1opt whose synthetized attribute is boost::optional<T>
>>>>>> grmr1 whose synthetized attribute is boost::optional<T>
>>>>>>
>>>>>>     grmr1opt = grmr1 [ _val = _1 ];
>>>>>>     ...
>>>>>>     start_ = ( grmr1opt  >> grmr2opt  >> grmr3opt  ) [ _val =
>>>>> pnx::construct( *_3, *_2,
>>>>>>     *_1) ];
>>>>>>
>>>>>>
>>>>>> or something like this?
>>>>>
>>>>> I think so, yes.
>>>>>
>>>>> Regards,
>>>>> --
>>>>> Joel de Guzman
>>>>>
>>>>>
>>>> Unfortunately, even just in
>>>>
>>>>> grmr1opt = grmr1 [ _val = _1 ]
>>>>
>>>>  the attrib of _1 requires to be default constructible.
>>>>
>>>> The same sort of compile error happens with value_init which tries to
>>>> default construct the attrib of _1 (which is T), the attrib of _val
>> being
>>>> compatible with boost::optional<T>
>>>>
>>>> Parsing grmr1 with qi::parse, passing an existing instance of T,
>> succeeds.
>>>>
>>>> I would have thought    _val = _1     is lazily equivalent to calling
>>>>  boost::optional<T>::operator( const T& )
>>>>
>>>> I have tried with these 2:
>>>>
>>>>> grmr1opt = grmr1 [ _val = pnx::construct<T>(_1) ]
>>>>
>>>> and
>>>>
>>>>> grmr1opt = grmr1 [ _val = pnx::ref(_1) ]
>>>>
>>>>
>>>> Both bark for the same reason....
>>>>
>>>> MM
>>>>
>>>
>>> I have been told to use the customization point transform_attribute.
>>> I can't quite see which would be the exposed and the transformed type.
>>> Can it help to work around no default ctor of T?
>>>
>>> Regards,
>>
>> Can you post the code somehow?
>>
>>
> http://codepad.org/3kQzYt4E
>
> The 3 grammars for day, month and year can be used to qis::parse(
> begin,end,  greg_day_<>(), ...a ref to a greg_day );
>
> But the grammar for date fails to compile because the _1 , _2 and _3
> (greg_day, month, date types don't have a def ctor.

I assume you mean by greg_day, month, date, you mean the member
variables:

  greg_day_<Iterator> date_<Iterator>::day_rule_;
  greg_month_<Iterator> date_<Iterator>::month_rule_;
  greg_year_<Iterator> ydate_<Iterator>::ear_rule_;

Which can't be constructed because their attributes:

  gregorian::greg_day
  gregorian::greg_month
  gregorian::greg_year

cannot be default constructed.
>
> I have tried to use optional,

So you've tried chaning the attributes to:

  boost::optional<gregorian::greg_day>
  boost::optional<gregorian::greg_month>
  boost::optional<gregorian::greg_year>

and it still failed to commpile?  Based on:

  boost::optional<const Resource> resource_;
  .
  .
  .
  optional's default constructor creates an uninitialized optional.
  No  call to Resource's default constructor is attempted.

from:


http://www.boost.org/doc/libs/master/libs/optional/doc/html/boost_optional/quick_start/optional_data_members.html

I would have expected all to compile since, "No call to Resource's
default constructor is attempted" means, in your case,
"No call to greg_day, greg_month, or greg_year's default
constructors are attempted".

In that case, I'm stumped.

 yes i tried to have sort of wrapper qi::rule  whose attribute is boost::optional<gregorian::greg_day> rather than gregorian::greg_day

then I define 

greg_day_<Iterator> day_rule_;
rule<Iterator, boost::optional<gregorian::greg_day>()> day_rule_wrp_;

day_rule_wrp_ = day_rule_ [ _val = _1 ];     /// _val's attrib is optional<greg_day>

the semantic action causes spirit to instantiate greg_day with def ctor anyways.
It may also be that boost::optional is somehow short cut, and its embedded gets def cted too....

MM

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

cppljevans
In reply to this post by MM
On 09/26/2014 08:48 AM, MM wrote:
> On 26 September 2014 14:20, Larry Evans <[hidden email]> wrote:
>
[snip]

>>
>> Can you post the code somehow?
>>
>>
> http://codepad.org/3kQzYt4E

I tried to compile the code, but got an error about missing
uint_parser parser; hence, I added:

#include <boost/spirit/home/qi/numeric/uint.hpp>

but now I'm getting:

/home/evansl/dwnlds/llvm/3.5/rel/build-variants/Release/cmake-install/bin/clang++
-c -O0 -gdwarf-2 -stdlib=libc++  -std=c++1y
-I/home/evansl/prog_dev/clang/libcxx
-I/home/evansl/prog_dev/boost/boost-releases/ro/boost_1_56_0
-DTYPE_AT_IMPL=0   -ftemplate-depth=324  MMgrammar.cpp -MMD -o
/tmp/build/clangxx3_5_rel/clang/libcxx/MMgrammar.o
MMgrammar.cpp:51:14: error: no member named 'if_' in namespace
'boost::phoenix'
        pnx::if_( _1>=1u && _1<=31u )
        ~~~~~^

Could you please let me know what other #include's are missing from
the posted code?
[snip]



------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
MM
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

MM

On 26 September 2014 16:04, Larry Evans <[hidden email]> wrote:
On 09/26/2014 08:48 AM, MM wrote:
> On 26 September 2014 14:20, Larry Evans <[hidden email]> wrote:
>
[snip]

>>
>> Can you post the code somehow?
>>
>>
> http://codepad.org/3kQzYt4E

I tried to compile the code, but got an error about missing
uint_parser parser; hence, I added:

#include <boost/spirit/home/qi/numeric/uint.hpp>

but now I'm getting:

/home/evansl/dwnlds/llvm/3.5/rel/build-variants/Release/cmake-install/bin/clang++
-c -O0 -gdwarf-2 -stdlib=libc++  -std=c++1y
-I/home/evansl/prog_dev/clang/libcxx
-I/home/evansl/prog_dev/boost/boost-releases/ro/boost_1_56_0
-DTYPE_AT_IMPL=0   -ftemplate-depth=324  MMgrammar.cpp -MMD -o
/tmp/build/clangxx3_5_rel/clang/libcxx/MMgrammar.o
MMgrammar.cpp:51:14: error: no member named 'if_' in namespace
'boost::phoenix'
        pnx::if_( _1>=1u && _1<=31u )
        ~~~~~^

Could you please let me know what other #include's are missing from
the posted code?
[snip]

Thanks for helping. I apologize for the incomplete includes.
Just include  the 2 top levels for qi and phoeinx
#include <boost/spirit/include/qi.hpp>
#include <boost/phoenix/phoenix.hpp>

note c++11, and a define BOOST_SPIRIT_USE_PHOENIX_V3
are required as well

MM

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

cppljevans
In reply to this post by MM
On 09/26/2014 09:53 AM, MM wrote:
[snip]

>  yes i tried to have sort of wrapper qi::rule  whose attribute is
> boost::optional<gregorian::greg_day> rather than gregorian::greg_day
>
> then I define
>
> greg_day_<Iterator> day_rule_;
> rule<Iterator, boost::optional<gregorian::greg_day>()> day_rule_wrp_;
>
> day_rule_wrp_ = day_rule_ [ _val = _1 ];     /// _val's attrib is
> optional<greg_day>
>
> the semantic action causes spirit to instantiate greg_day with def ctor
> anyways.
Wrapping the rule doesn't help because the wrapped rule still needs
the default CTOR.  IOW, change day_rule_ to have an
optional<greg_day> attribute instead of wrapping it.

HTH.

-regards,
Larry




------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
MM
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

MM
On 26 September 2014 16:34, Larry Evans <[hidden email]> wrote:
On 09/26/2014 09:53 AM, MM wrote:
[snip]

>  yes i tried to have sort of wrapper qi::rule  whose attribute is
> boost::optional<gregorian::greg_day> rather than gregorian::greg_day
>
> then I define
>
> greg_day_<Iterator> day_rule_;
> rule<Iterator, boost::optional<gregorian::greg_day>()> day_rule_wrp_;
>
> day_rule_wrp_ = day_rule_ [ _val = _1 ];     /// _val's attrib is
> optional<greg_day>
>
> the semantic action causes spirit to instantiate greg_day with def ctor
> anyways.
Wrapping the rule doesn't help because the wrapped rule still needs
the default CTOR.  IOW, change day_rule_ to have an
optional<greg_day> attribute instead of wrapping it.

HTH.

-regards,
Larry

But I use greg_day_ elsewhere to parse just day independently from date, and that works because I pass in the greg_day&
Is there a way to have a greg_day member in the date grammar, and use that member somehow for the greg_day_ subgrammar?

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
MM
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

MM


On 26 September 2014 15:58, MM <[hidden email]> wrote:
On 26 September 2014 16:34, Larry Evans <[hidden email]> wrote:
On 09/26/2014 09:53 AM, MM wrote:
[snip]

>  yes i tried to have sort of wrapper qi::rule  whose attribute is
> boost::optional<gregorian::greg_day> rather than gregorian::greg_day
>
> then I define
>
> greg_day_<Iterator> day_rule_;
> rule<Iterator, boost::optional<gregorian::greg_day>()> day_rule_wrp_;
>
> day_rule_wrp_ = day_rule_ [ _val = _1 ];     /// _val's attrib is
> optional<greg_day>
>
> the semantic action causes spirit to instantiate greg_day with def ctor
> anyways.
Wrapping the rule doesn't help because the wrapped rule still needs
the default CTOR.  IOW, change day_rule_ to have an
optional<greg_day> attribute instead of wrapping it.

HTH.

-regards,
Larry

I rewrote the date grammar to not depend on those subgrammars.

Now there is a peculiarity of date.
It is default constructible, has a copy ctor, and is user constructible from day/month/year, but does not have assignment operator:
There is no:
date& date::operator=( const date& );
And it doesn't have modifiers for year/month/day.
It's pretty crap actually.

So i came up with a grammar that returns a date* to become owned by the caller of the grammar, and that works because I then call:
_val = pnx::new_( year,month, day)
And this returns the date* to the caller. 
However, this is non performant as I have 10000 dates to parse from 1 file.

Is there some sort of construct in place mechanism whereby the semantic action lazily re-constructs an existing object in place by the provider user ctor that takes year/month/day?  Just shooting in space:-)

MM

MM

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

cppljevans
On 09/26/2014 03:38 PM, MM wrote:

> On 26 September 2014 15:58, MM <[hidden email]> wrote:
>
>> On 26 September 2014 16:34, Larry Evans <[hidden email]> wrote:
>>
>>> On 09/26/2014 09:53 AM, MM wrote:
>>> [snip]
>>>
>>>>  yes i tried to have sort of wrapper qi::rule  whose attribute is
>>>> boost::optional<gregorian::greg_day> rather than gregorian::greg_day
>>>>
>>>> then I define
>>>>
>>>> greg_day_<Iterator> day_rule_;
>>>> rule<Iterator, boost::optional<gregorian::greg_day>()> day_rule_wrp_;
>>>>
>>>> day_rule_wrp_ = day_rule_ [ _val = _1 ];     /// _val's attrib is
>>>> optional<greg_day>
>>>>
>>>> the semantic action causes spirit to instantiate greg_day with def ctor
>>>> anyways.
>>> Wrapping the rule doesn't help because the wrapped rule still needs
>>> the default CTOR.  IOW, change day_rule_ to have an
>>> optional<greg_day> attribute instead of wrapping it.
>>>
>>> HTH.
>>>
>>> -regards,
>>> Larry
>>>
>>> I rewrote the date grammar to not depend on those subgrammars.
>
> Now there is a peculiarity of date.
> It is default constructible, has a copy ctor, and is user constructible
> from day/month/year, but does not have assignment operator:
> There is no:
>
>> date& date::operator=( const date& );
>
> And it doesn't have modifiers for year/month/day.
> It's pretty crap actually.
>
> So i came up with a grammar that returns a date* to become owned by the
> caller of the grammar, and that works because I then call:
>
>> _val = pnx::new_( year,month, day)
>
> And this returns the date* to the caller.
> However, this is non performant as I have 10000 dates to parse from 1 file.
>
> Is there some sort of construct in place mechanism whereby the semantic
> action lazily re-constructs an existing object in place by the provider
> user ctor that takes year/month/day?  Just shooting in space:-)
>
What about:

http://www.boost.org/doc/libs/master/libs/optional/doc/html/boost_optional/quick_start/optional_data_members.html

In particular:

  resource_.emplace("resource", "arguments");

where, in your case, that would be:

  _val.emplace(year,month,day)

I also am just guessing :(




------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

Richard-45
In reply to this post by MM

In article <CADsB1iA=[hidden email]>,
    MM <[hidden email]> writes:

> Is there some sort of construct in place mechanism whereby the semantic
> action lazily re-constructs an existing object in place by the provider
> user ctor that takes year/month/day?  Just shooting in space:-)

You already have three rules for year/month/day in a version of this
code that I looked at earlier.

IIRC, there was also a rule that aggregated a year/month/day rule
into a "date" rule.

What I would do is have the synthetic attribute for the
year/month/day all be unsigned ints and have the synthetic attribute
for the date rule be a date and synthesize it from the three ints.

Is this not possible?

Just randomly thinking out loud here...
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

cppljevans
In reply to this post by MM
On 09/26/2014 03:38 PM, MM wrote:

> On 26 September 2014 15:58, MM <[hidden email]> wrote:
>
>> On 26 September 2014 16:34, Larry Evans <[hidden email]> wrote:
>>
>>> On 09/26/2014 09:53 AM, MM wrote:
>>> [snip]
>>>
>>>>  yes i tried to have sort of wrapper qi::rule  whose attribute is
>>>> boost::optional<gregorian::greg_day> rather than gregorian::greg_day
>>>>
>>>> then I define
>>>>
>>>> greg_day_<Iterator> day_rule_;
>>>> rule<Iterator, boost::optional<gregorian::greg_day>()> day_rule_wrp_;
>>>>
>>>> day_rule_wrp_ = day_rule_ [ _val = _1 ];     /// _val's attrib is
>>>> optional<greg_day>
>>>>
>>>> the semantic action causes spirit to instantiate greg_day with def ctor
>>>> anyways.
>>> Wrapping the rule doesn't help because the wrapped rule still needs
>>> the default CTOR.  IOW, change day_rule_ to have an
>>> optional<greg_day> attribute instead of wrapping it.
>>>
>>> HTH.
>>>
>>> -regards,
>>> Larry
>>>
>>> I rewrote the date grammar to not depend on those subgrammars.
>
> Now there is a peculiarity of date.
> It is default constructible, has a copy ctor, and is user constructible
> from day/month/year, but does not have assignment operator:
> There is no:
>
>> date& date::operator=( const date& );
>
> And it doesn't have modifiers for year/month/day.
> It's pretty crap actually.
>
> So i came up with a grammar that returns a date* to become owned by the
> caller of the grammar, and that works because I then call:
>
>> _val = pnx::new_( year,month, day)
>
> And this returns the date* to the caller.
> However, this is non performant as I have 10000 dates to parse from 1 file.
>
> Is there some sort of construct in place mechanism whereby the semantic
> action lazily re-constructs an existing object in place by the provider
> user ctor that takes year/month/day?  Just shooting in space:-)
>
[snip]
This gihub gist:

https://gist.github.com/cppljevans/d76e250feba518a428c7

shows what works using boost::optional.  I recall you
said in another post that there was some problem where you
wanted to actually pass in a day attrubute to the
greg_day_ parser.  I haven't figured how to do that.

HTH.

-regards,
Larry




------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|

Re: >> operator, fusion vector, and default constructible attributes

cppljevans
On 09/26/2014 11:17 PM, Larry Evans wrote:

> On 09/26/2014 03:38 PM, MM wrote:
>> On 26 September 2014 15:58, MM <[hidden email]> wrote:
>>
>>> On 26 September 2014 16:34, Larry Evans <[hidden email]> wrote:
>>>
>>>> On 09/26/2014 09:53 AM, MM wrote:
>>>> [snip]
>>>>
>>>>>  yes i tried to have sort of wrapper qi::rule  whose attribute is
>>>>> boost::optional<gregorian::greg_day> rather than gregorian::greg_day
>>>>>
>>>>> then I define
>>>>>
>>>>> greg_day_<Iterator> day_rule_;
>>>>> rule<Iterator, boost::optional<gregorian::greg_day>()> day_rule_wrp_;
>>>>>
>>>>> day_rule_wrp_ = day_rule_ [ _val = _1 ];     /// _val's attrib is
>>>>> optional<greg_day>
>>>>>
>>>>> the semantic action causes spirit to instantiate greg_day with def ctor
>>>>> anyways.
>>>> Wrapping the rule doesn't help because the wrapped rule still needs
>>>> the default CTOR.  IOW, change day_rule_ to have an
>>>> optional<greg_day> attribute instead of wrapping it.
>>>>
>>>> HTH.
>>>>
>>>> -regards,
>>>> Larry
>>>>
>>>> I rewrote the date grammar to not depend on those subgrammars.
>>
>> Now there is a peculiarity of date.
>> It is default constructible, has a copy ctor, and is user constructible
>> from day/month/year, but does not have assignment operator:
>> There is no:
>>
>>> date& date::operator=( const date& );
>>
>> And it doesn't have modifiers for year/month/day.
>> It's pretty crap actually.
>>
>> So i came up with a grammar that returns a date* to become owned by the
>> caller of the grammar, and that works because I then call:
>>
>>> _val = pnx::new_( year,month, day)
>>
>> And this returns the date* to the caller.
>> However, this is non performant as I have 10000 dates to parse from 1 file.
>>
>> Is there some sort of construct in place mechanism whereby the semantic
>> action lazily re-constructs an existing object in place by the provider
>> user ctor that takes year/month/day?  Just shooting in space:-)
>>
> [snip]
> This gihub gist:
>
> https://gist.github.com/cppljevans/d76e250feba518a428c7
>
> shows what works using boost::optional.  I recall you
> said in another post that there was some problem where you
> wanted to actually pass in a day attrubute to the
> greg_day_ parser.  I haven't figured how to do that.
>
You can do that by adding an optional template template paramter:

template <typename Iterator, template<typename Attr>class
Wrapper=attr_wrap_optional>
struct greg_day_
: grammar< Iterator, typename Wrapper<gregorian::greg_day>::type()> {


Then, when you want to use greg_day by itself an pass the greg_day
attribute to the phrase_parse function, just change Wrapper to
boost::mpl::identity.

HTH.

-regards,
Larry




------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
12