This is the mail archive of the
mailing list for the GCC project.
Re: RFC:Updated VEC API
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>
- Date: Tue, 12 Apr 2005 19:48:36 -0400
- Subject: Re: RFC:Updated VEC API
- References: <425C16B2.firstname.lastname@example.org>
On Tue, 2005-04-12 at 19:42 +0100, Nathan Sidwell wrote:
> 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).
> Option1 is more easy to implement. Option2 requires a little nested
> structure jiggery pokery to retain type safety.
I like option 2 from a writer perspective, but i don't know how much of
a pain in the ass it is for you.
> 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)'
This is just the push we need to move to C++.