lkml.org 
[lkml]   [2009]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH] flexible array implementation v3
From
Date
On Thu, 2009-07-23 at 11:44 -0400, Oren Laadan wrote:
> Probably premature, but -- I wonder if it's worth adding interfaces to:
>
> * copy a range of elements at once (perhaps to/from regular array ?
> or userspace ? -- depending on potential users)

I can see this making some sense, especially if you're dumping a bunch
of stuff out to userspace and don't want to worry about page boundaries,
etc... Or, if you have a ton of stuff to copy and some of the
flex_array overhead is getting in the way. I'm not opposed to it, but I
think I'd want to see a user first to make sure I got the implementation
right.

> * (macro ?) iterate through elements (better have it ready for users
> of flex_array before, than convert their code later on)

I've thought about this, but I don't think there's much advantage to
doing it. It obfuscates things without any real gain in simplicity. We
have LIST_FOR_EACH() because containerof() and some of the typing is a
little non-obvious. But, here, I think it's mostly dummy-proof:

We need a 'tmp' variable here because unlike list traversal, there's no
position implied in the variables. So, we're looking at (with a new
macro):

int tmp;
FA_FOR_EACH(fa, var, tmp)
foo(var);

vs.

int i;
for (i = 0; i < fa->total_nr_elements; i++)
foo(flex_array_get(fa, i));

The macro *looks* cleaner, but I don't think it really buys us much.

-- Dave



\
 
 \ /
  Last update: 2009-07-23 18:05    [W:0.094 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site