Yes, but it's much easier not to have to worry about sizes (and potential reallocs - had by any chance the size of the response changed, from the initial calculation, to the rendering point), and just do:
struct foo* f = foo_create(); foo_write(f, ...); foo_write(f, ...); foo_write(f, ...); foo_write(f, ...); The O(N) is just a consequence that the buffers set is a circular buffer ordered by offset. Head and tail appending (which /methink are the only cases which we need to support), can just update the current (head or tail) buffer in place. On Mon, Dec 7, 2015 at 9:33 AM, Barret Rhoden <[email protected]> wrote: > On 2015-12-07 at 09:13 "'Davide Libenzi' via Akaros" > <[email protected]> wrote: > > It's much easier to have a reusable data structure which allows you > > to not make size assumptions and reallocs all over the code which > > needs to create a dynamic textual response. > > It's not an assumption if you calculate it. We want to know the length > anyways for stat calls. But whatever; so long as its simple to use and > out of the way, I don't care. log(n) seeks seems a little unnecessary > btw. > > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
