Re: [AD] Export AL_VECTOR

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On June 18, 2008, Peter Wang wrote:
> On 2008-06-18, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > I would like to see AL_VECTOR be a public Allegro 5 api. The fshook stuff
> > would like to deal with paths a lot, and the splitdir/catdir set of
> > functions would be greatly simplified with a public vector interface.
> >
> > I've asked around a little, and have found that people would indeed use
> > splitdir and catdir and related functions, the problem is, without a
> > resizeable array api to give to the caller, it would be hard, if not
> > impossible to resize the char** array if needed (to pass back to
> > catdir/catpath etc).
> >
> > I'm trying to make this an api that people would actually want to use
> > over the various system specific apis, making common actions with paths
> > simpler. Without it I think allegro is missing a very important
> > /platform/ feature. Allegro is a platform, and a platform needs a good
> > set of consistent file and path api functions.
> >
> > Without a public AL_VECTOR, I'd have to either use char** arrays, or
> > implement my own dynamic array api just for the fs api. I find that wrong
> > on a few levels.
>
> You can export an (opaque) resizable array API which is specific to the
> fs API, and implement that using _AL_VECTOR.  Would that be okay?

I personally think that's still dirty. I then have to duplicate the api. then 
what happens to parts of the api that also need a resizeable array? Do they 
then duplicate the interface again?

> I'm not completely against exporting a generic resizable array API but
> the _AL_VECTOR interface isn't that good.  We want to be able to change
> it without breaking backwards compatibility with user programs.

I have a rather complete, and fairly performant C resizeable array "class". It 
was on par with std::vector in all the tests I made. Of course it also grows 
like std::vector, so it sacrifices memory use for speed (each time it 
expands, it doubles its total size).

I actually named it "list_t" but hey, its actually a vector like object:

list_t *list_create(void);
void list_destroy(list_t *list);
/* used to set sane defaults for statically allocated list_ts */
void list_init(list_t *list);

/* negative pos value (-1) indicates end of list */
int list_insert(list_t *list, int pos, void *item);
void *list_remove(list_t *list, int pos);

void *list_index(list_t *list, int pos);

int list_push(list_t *list, void *item);
int list_unshift(list_t *list, void *item);

void *list_pop(list_t *list);
void *list_shift(list_t *list);

int list_length(list_t *list);
void list_clear(list_t *list);

int list_reserve(list_t *list, int pos, int items);
int list_set(list_t *list, int pos, void *ptr);

Stores pointers only. 

> Peter
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php



-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/