This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: New VEC API
- From: "Giovanni Bajo" <giovannibajo at libero dot it>
- To: "Nathan Sidwell" <nathan at codesourcery dot com>
- Cc: "Daniel Berlin" <dberlin at dberlin dot org>,<gcc-patches at gcc dot gnu dot org>
- Date: Sat, 16 Apr 2005 17:22:49 +0200
- Subject: Re: New VEC API
- References: <42612B2D.20603@codesourcery.com>
Nathan Sidwell <nathan@codesourcery.com> wrote:
>> The accessors that cannot cause allocation do not need to mention the
>> allocation mechanism. I.e.
>> VEC_length(tree,v); // how long is this vector (be it none,gc or
>> heap)
>> but when allocation might occur, you have to specify
>> VEC_safe_push(tree,gc,v,node); // push onto end.
What happens if you specify a wrong allocation type in such a function?
Would it be possible to assert this condition in ENABLE_CHECKING mode, at the
expense of (maybe) a slightly larger vec structure?
>> 1) duplicate adjacent calls to VEC_safe_push. I changed these to
>> VEC_reserve (2), VEC_quick_push (...), VEC_quick_push (...)
Assuming exponential grow, shouldn't the overhead of two consecutive safe_push
be negligible?
Giovanni Bajo