Re: RFC:Updated VEC API

[Mark Mitchell <mark at codesourcery dot com>]

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
mark@codesourcery.com
(916) 791-8304