Re: [boost] [typeof-users] Looking for a consistent scheme for adding Typeof support to Boost libraries

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-01-19 18:25:33

dan marsden wrote:
> --- Arkadiy Vertleyb <vertleyb_at_[hidden]> wrote:
> 
>>>Where should the header go?
>>>
>>>     boost/typeof/boost/<LIB>
>>>
>>>??
>>
>>No, definitely not under boost/typeof :-)
>>
>>I think the registration should be [conceptualy]
>>owned by the library
>>authors rather then typeof library, so I still think
>>boost/<LIB>/typeof is
>>more appropriate.  When I was talking about
>>non-intrusiveness I meant files,
>>not directories.  It is also much easier to work
>>with CVS when everything is
>>under the same root.
>>
> 
> 
> That sounds reasonable to me. The various macro
> approaches seem a bit too clever, a header based
> approach should be easy for library clients to
> understand.
> 
> As for structure, how about consistently placing the
> typeof headers in a directory beneath the file they
> support. So for a file:
> 
> boost/a/b/c.hpp
> 
> The corresponding typeof support would be in:
> 
> boost/a/b/typeof/c.hpp
> 
> So for a small part of phoenix2 for example we have:
> 
> boost/spirit/phoenix/operator/arithmetic.hpp
> boost/spirit/phoenix/operator/logical.hpp
> etc...
> 
> Which provide lamdba support for different types of
> operators. Their typeof support would be in:
> 
> boost/spirit/phoenix/operator/typeof/arithmetic.hpp
> boost/spirit/phoenix/operator/typeof/logical.hpp
> etc...
> 
> Phoenix also provides a single file that provides all
> the operator support in one hit:
> 
> boost/spirit/phoenix/operator.hpp
> 
> Again following the same logic, to add all the
> corresponding typeof support:
> 
> boost/spirit/phoenix/typeof/operator.hpp
> 
> Hopefully that illustrates one possible candidate
> naming scheme. I've aimed for simplicity, consistency
> and fine grain control over what typeof support is
> brought in. The higher level files (like operator.hpp)
> allow clients that are not fussy to just drag in a
> load of typeof support in one hit. At least one
> downside is that there are a lot of additional files
> for library writers to manage in some of the more
> complex libraries.

I think I like this best.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net