Boost logo

Boost :

Subject: Re: [boost] [castor] Interest in Logic Paradigm for C++ ?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-03 19:05:37


----- Original Message -----
From: "Roshan" <roshan_naik_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, May 03, 2010 11:20 PM
Subject: Re: [boost] [castor] Interest in Logic Paradigm for C++ ?

>
> On Sun, 02 May 2010 20:40:39 -0600, OvermindDL1 <overminddl1_at_[hidden]>
> 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.
>
> 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 :
>
> (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.

Hi,

this is no the first time some one want to introduce a library in Boost but don't want to use nothing of Boost; even if the abstraction already exist in Boost.
Whether a library I use is about 1KLOC or 100KLOC it is not important to me, if the service the library provides is what I need.

What kind of users do you want to preserv with a standalone library that will not use your library if it depends on Boost?

Best,
Vicente


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk