Hi,
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
the lovely
        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
        DEF_VEC(tree,heap);
        DEF_VEC(tree,gc);
        ...
        VEC(tree,heap) *on_heap;
        VEC(tree,gc)  *in_gc;

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
satisfactory upside?

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)
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
'VEC_append (v,t)')

comments?

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
[EMAIL PROTECTED]    ::     http://www.planetfall.pwp.blueyonder.co.uk


Reply via email to