Boost C++ Libraries: Ticket #7996: phoenix::bind does not protoify the bound arguments

attachment set

Andrey Semashev — Wed, 06 Feb 2013 18:11:12 GMT

attachment → build_error.txt

Compilation error

Thomas Heller — Fri, 08 Feb 2013 21:06:53 GMT

Hi Andrey,

I am not sure what the problem here *exactly* is. I just checked the code of phoenix bind and all other phoenix expressions, they never use boost::proto::detail::protoify, the use the regular and document boost::proto::make_expr functionality. I am not sure who to blame here. However i think it rather is Boost.Log in this case, as phoenix uses official and document functions of proto. This means i needed to change every phoenix expression in order to work with boost.log which uses an undocument private function out of the detail namespace of a library.

That being said, this would probably need closer investigation. I will try to take a close look next week.

Andrey Semashev — Fri, 08 Feb 2013 22:04:15 GMT

Replying to theller:

I'm by far not an expert in Boost.Proto but as far as I understand protoify is used internally by Boost.Proto to envelop objects participating in template expressions into Boost.Proto expression tree structures. In particular this is done to all terminals, and this behavior is used by Boost.Log to transparently convert all attribute_keywords to attribute_actors.

Boost.Phoenix doesn't use protoify directly, but it does so through some public interface of Boost.Proto (which is probably make_expr, I don't know for sure). My guess is that phoenix::bind doesn't treat the bound arguments the same way Boost.Phoenix treats other terminals in template expressions. This results in bound arguments not being enveloped into Boost.Proto terminal structures and consequently it doesn't invoke protoify and breaks Boost.Log.

I will be happy to use a public interface of Boost.Proto or Boost.Phoenix to achieve what I need. I just didn't find such an interface. Please, tell me if there is one.

Andrey Semashev — Sun, 22 Sep 2013 18:58:12 GMT

Any updates about this problem?

Tue, 04 Feb 2014 20:55:14 GMT

I am going to start to look at this problem. My first reaction is that if Thomas did not know an answer, and he wrote version 3 of phoenix to use proto, then I am going to have to do quite a lot of digging to find this one. John

Tue, 04 Feb 2014 23:23:54 GMT

Replying to John Fletcher <J.P.Fletcher@…>:

I am going to start to look at this problem. My first reaction is that if Thomas did not know an answer, and he wrote version 3 of phoenix to use proto, then I am going to have to do quite a lot of digging to find this one. John

This is not working.

Tue, 04 Feb 2014 23:24:43 GMT

Sorry, response on the wrong item.

Fri, 07 Feb 2014 15:39:40 GMT

Replying to John Fletcher <J.P.Fletcher@…>:

Sorry, response on the wrong item.

It was "this is not working" which was on the wrong bug trac. I have yet to start on this one. John

severity, component, version, milestone, owner, type changed

Smithd413 — Thu, 17 Jul 2014 10:36:00 GMT

severity Problem → Not Applicable
component phoenix → xpressive
version Boost Release Branch → Boost.Build-M3
milestone To Be Determined → Website 1.X
owner changed from Thomas Heller to Eric Niebler
type Bugs → Library Submissions

Thanks so much for sharing this excellent info! I'm seeking forward to see much more posts! beececefeeeeeeec

severity, component, version, milestone, owner, type changed

Andrey Semashev — Thu, 17 Jul 2014 11:36:25 GMT

severity Not Applicable → Problem
component xpressive → phoenix
version Boost.Build-M3 → Boost Release Branch
milestone Website 1.X → To Be Determined
owner changed from Eric Niebler to Thomas Heller
type Library Submissions → Bugs

Thu, 17 Jul 2014 21:09:48 GMT

Andy My apologies I have never got around to looking at this one. John