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]


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
	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)')



Nathan Sidwell    ::   ::     CodeSourcery LLC    ::

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