Brian McNamara wrote:
Other than that, the only thing that makes the current version "bigger" than old versions is the number of functions and datatypes you find in headers like "prelude.hpp". As I've already mentioned, I know these headers are too monolithic (if you just want one function, like "map", you are forced to #include about 70 other functions too), but that's easy to fix.
Thanks! Refactoring the monolithic whole into chunks will definitely be a good thing. Anyway... I'm trying to get into the code and docs whenever I could steal some time. So, my comments may be fragmented. Pardon me. Here's one. In the docs, you say: (Now is a good time to mention that FC++ supports functoids of 0-3 parameters. The fullN, funN, and c_fun_type classes have only been defined for functions of up to three arguments.) Why only three? Experience with Phoenix with Spirit shows that this is not enough. Why hard-code the limit? I used to hate the preprocessor, but now, I always use boost.preprocessor to generate redundant code, hence, not having a hard coded arity limit. Is there a technical problem not to support more? I might be missing something significant though. But I recall that this is also one thing I didn't like when I first reviewed FC++ a few years ago (I was also hindered by LL's limit of 10, IIRC). Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net