Re: [boost] FC++ Formal review half way over today (ends 2/23)

From: Joel de Guzman (joel_at_[hidden])
Date: 2004-02-19 22:10:37

Brian McNamara wrote:
> On Thu, Feb 19, 2004 at 11:04:16PM +0800, Joel de Guzman wrote:

>>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?
> 
> 
> Probably not; I just have not done the work.  (There are only so many
> hours you can spend "boostifying" before you decide it's time to stop
> and put the library up for review.)
> 
> (Actually, if you look at the code for "full3"
>    http://www.cc.gatech.edu/~yannis/fc++/FC++.1.5/full.h
> I am not sure that the currying stuff can be so easily macro-ized.  
> But maybe.)
> 
> 
>>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).
> 
> 
> 10!  Except for code-generators, or people working in very specific
> domains, it's hard for me to imagine 10 not being enough.  Wow!

Yep, code generators! Especially, template code generators. This
is typical if your library's client is another template library.
Consider the (proposed) Spirit grouping (ala YACC) syntax:

     r = (a >> b >> c >> d >> e)
         [
             f(_1, _3, _5)
         ];

Even this trivial example requires an arity of 5, regardless if
only _1, _3, and _5 are actually used by the client.

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