Nathan Sidwell wrote:
option1) Require the allocation mechanism to be mentioned in *all* vector API
calls. So you'd have 'VEC_append (tree,gc,v,t)', but you'd also have
'VEC_length (tree,gc,v)', which is kind of annoying.
I think that's more than annoying: it's dangerous. We'll get it wrong on some functions, with unfortunate results.
option2) Split the DEF_VEC operation into DEF_VEC and DEF_VEC_ALLOC parts.
The former would define all the non-allocation sensitive routines, and the
latter defines all the allocation specific ones. So now when defining a vector
type you'd have
DEF_VEC(tree); // define the common tree routines
DEF_VEC_ALLOC(tree,gc); // define the gc tree routines
DEF_VEC_ALLOC(tree,heap); // define the heap tree routines
I like this one. To me, that's just a C-ish way of doing inheritance from the "VEC<tree>" base class.
But you can now say 'VEC_length (tree,v)', without caring whether it's a gc'd or heap allocated vector. Unfortunately, now there must be *exactly* one invocation of DEF_VEC(tree), regardless of where the DEF_VEC_ALLOC calls are, which is also annoying.
I don't think that's so bad. Heck, it means we'll have less code.
Another option, is whether the type and allocation parameters of the
API calls are themselves parenthesized into a single macro argument,
as in
VEC_append ((tree,gc),v,t)
I don't think it's necssary to do this bit, but I'm not particularly opposed.
-- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
