RE: [boost] Re: MPL include problem with BOOST_PP_ITERATE
Paul Mensonides wrote: - Original Message - From: Aleksey Gurtovoy [EMAIL PROTECTED] You have a point, here. I'll look into the issue tonight. Don't bother. What Hugo is doing is a sketchy use of the mechanism precisely because of this type of problem. Even if you efine a special flag macro to distinguish a certain MPL iteration from some other iteration, you are still going to have serious problems. Specifically, you'd have to rewrite all of it to reenter the file-iteration mechanism in an abstract and relative way, which means no direct references to specific iteration frames at all. This kind of thing is the purpose of the relative macros, but I cannot _evaluate_ the filename to iterate over. Therefore, I cannot abstract the depth. OK, I see, there is no easy way to fix it. Hugo, would the BOOST_PP_ANGLED_INCLUDE() mechanism Paul referred to in another message in this thread help you to implement what you are currently trying to do with BOOST_PP_ITERATE()? If it would, let's pursue that solution, then, since your case _is_ somewhat special and apparently is in conflict with recommended usage of file iteration mechanism. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL include problem with BOOST_PP_ITERATE
Hugo Duncan wrote: Maybe my use of ITERATE is slightly different, in that I am using it to include a LIST of files. The LIST provides a single integration point. Hoisting all the includes reduces the utility of using ITERATE. OK, I see the problem now. I can hoist the include of boost/mpl/list.hpp (and have done so for the moment), but I don't think that I should have to. The way I look at it, the fact that MPL uses ITERATE in its header files is an implementation convenience for MPL, and should not be visible to the user. You have a point, here. I'll look into the issue tonight. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL include problem with BOOST_PP_ITERATE
- Original Message - From: Hugo Duncan [EMAIL PROTECTED] Maybe my use of ITERATE is slightly different, in that I am using it to include a LIST of files. The LIST provides a single integration point. Hoisting all the includes reduces the utility of using ITERATE. Ah, okay, I see what your saying. You cannot use the file-iteration mechanism this way without near explicit collaboration with the files that your are including. The problems involved are not as easy to solve as you're are suggesting (see my other post in response to Aleksey). At one point in the past, however, I wrote a mechanism explicitly for including a set of files. It was intended to shorthand the process of including a lot of files from the same library. Something like: #define BOOST_PP_HEADERS \ (boost/preprocessor, (tuple/elem.hpp)(repetition/repeat.hpp)(list/adt.hpp)) \ /**/ #include BOOST_PP_ANGLED_INCLUDE() (I had BOOST_PP_QUOTED_INCLUDE as well.) I'd be happy to add such a mechanism, but I'd like to hear what people want from the mechanism and any thoughts on syntactic issues, etc.. Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL include problem with BOOST_PP_ITERATE
- Original Message - From: Aleksey Gurtovoy [EMAIL PROTECTED] Hugo Duncan wrote: Maybe my use of ITERATE is slightly different, in that I am using it to include a LIST of files. The LIST provides a single integration point. Hoisting all the includes reduces the utility of using ITERATE. OK, I see the problem now. I can hoist the include of boost/mpl/list.hpp (and have done so for the moment), but I don't think that I should have to. The way I look at it, the fact that MPL uses ITERATE in its header files is an implementation convenience for MPL, and should not be visible to the user. You have a point, here. I'll look into the issue tonight. Don't bother. What Hugo is doing is a sketchy use of the mechanism precisely because of this type of problem. Even if you define a special flag macro to distinguish a certain MPL iteration from some other iteration, you are still going to have serious problems. Specifically, you'd have to rewrite all of it to reenter the file-iteration mechanism in an abstract and relative way, which means no direct references to specific iteration frames at all. This kind of thing is the purpose of the relative macros, but I cannot _evaluate_ the filename to iterate over. Therefore, I cannot abstract the depth. --- It should be considered an absolute rule that you don't include normal headers inside an iteration. --- (If I missed saying that in the docs, sorry, I'll fix it. I actually thought that I mentioned it, but I haven't checked.) Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
