This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC:Updated VEC API

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
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]