This is the mail archive of the
mailing list for the GCC project.
RFC:Updated VEC API
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: gcc <gcc at gcc dot gnu dot org>, Daniel Berlin <dberlin at dberlin dot org>
- Date: Tue, 12 Apr 2005 19:42:58 +0100
- Subject: RFC:Updated VEC API
- Organization: Codesourcery LLC
I promised to fix up the vector api, and there's a design decision
which needs to be made (incidentally, if we were in C++ land, we wouldn't
have to chose, as the right thing just happens).
The old API keyed the allocation strategy off the type name. This led to
typedef tree tree_on_heap;
so we could have heap allocated vectors of trees (as well as the default
gc allocated ones).
We want to separate this, so you'd now say something like
Now, certain vector accessors need to know the allocation mechanism (appending
for instance), and others don't (indexing, for instance). We also need
to obey the one definition rule.
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.
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
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.
Option1 is more easy to implement. Option2 requires a little nested
structure jiggery pokery to retain type safety.
So which has the more annoying downside, or alternatively, the more
Another option, is whether the type and allocation parameters of the
API calls are themselves parenthesized into a single macro argument,
Would this be a suitable visual aid to make those stand out as
'not expressions'? (In C++ land, you'd write it as
'VEC_append<tree,gc> (v,t)', if you really wanted a template-id-expr.
Mostly you'd just let template deduction DTRT and have a plain
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
firstname.lastname@example.org :: http://www.planetfall.pwp.blueyonder.co.uk