dan marsden wrote:
--- Arkadiy Vertleyb <vertleyb@hotmail.com> 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