On Mon, May 3, 2010 at 3:20 PM, Roshan <roshan_naik@yahoo.com> wrote:
On Sun, 02 May 2010 20:40:39 -0600, OvermindDL1 <overminddl1@gmail.com> wrote:
However, I notice a *lot* of overlap with Boost.Phoenix, it kind of seems like a continuation layer on top of Boost.Phoenix, and it probably could in fact be implement as a layer of Boost.Phoenix (Boost.Phoenix is made up of layers of functionality, and a logic layer makes sense). Boost.Phoenix is a lazy evaluation framework for C++. When it is finished being ported to Boost.Proto for Boost.Phoenix 3,
I think a Caster-style Logic layer would make a lot of sense, and would allow it to blend far more easily into the rest of boost while getting all the functionality of Boost.Phoenix (including the calling style fixes that Boost.Phoenix uses, val/ref's and such), along with pure lazy *type* inference too (which Caster does not do at all, not a major limitation, but one that could cause more code to be created at times then necessary), which would solve the whole list/vector thing the tutorial talks about (along with supporting any generic container transparently).
Have you thought about this?
Nope! I have restrained from introducing any cross library dependencies in an effort to keep it a standalone library. I am very keen on ensuring Castor continues to be distributable & usable as a standalone library even if included into Boost.
With the use of Boost.BCP, it is very simple to take the parts of boost you want and wrap it all up into a standalone project, it handles what requirements and all. On Mon, May 3, 2010 at 3:20 PM, Roshan <roshan_naik@yahoo.com> wrote:
However your suggestion interests me. From what I read, it seems that it might be possible to "peel off" just the necessary amount of Phoenix without dragging in all of Phoenix or rest of Boost. This sounds appealing to me since I want to ensure :
Boost.Phoenix is very powerful, and as someone else said in a different thread, its core is only about 90 lines of code (although that will be more once it is ported to Boost.Proto, but it will be even vastly more powerful then). The way it is designed is in layers (see its documentation www.boost.org/doc/libs/release/libs/spirit/phoenix/ , it has a whole picture and all, nice pretty examples), and any part only relies on pieces below it, it does not rely on any higher part, nor on any part on the same level, and yet they all inter-operate wonderfully. Caster could be such a part on a layer. And as stated, using Boost.BCP, you can rip out the libraries it needs, then you can manually trim them down (or another script) if you did not want to include all of Phoenix for whatever reason. On Mon, May 3, 2010 at 3:20 PM, Roshan <roshan_naik@yahoo.com> wrote:
(Benefits to end users + Benefits of code reduction in Castor's internals) > disadvantages of depending on another library (Phoenix)
Often these secondary libraries are too big (mcuh bigger than all of Castor) and in turn depend on other (Boost) libraries. Castor 1.0 is a really small library (under 5k LOC). The simple lambda support in Castor 1.0 totals to about 300 lines of code... compare that to relying on the "all powerful" boost.lambda which is about 14k LOC. Wasn't worth it.
Boost.Phoenix internals are also *very* small, just some parts of it are bigger then others, all depends on the functionality you need. The new version currently being made will be a bit bigger as its base since it will use Boost.Proto as the metafunction handler, but it will get a even more power by this move. On Mon, May 3, 2010 at 3:20 PM, Roshan <roshan_naik@yahoo.com> wrote:
I would like to investigate your suggestion further ... perhaps I can exchange emails with you offline on this topic to orient myself in the right direction.
I am not the right person for this, just a user of Boost.Phoenix (well, I have made a few customized parts for my own use, but still, just a user), Joel De Guzman is, but he is *busy*. It is always best to talk about these things in the public list anyway as others can learn from it as well. If you wish we can talk privately, but publicly is always better.