Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2001:
[Freeciv-Dev] Re: Split patch (was Re: [RFC PATCH] init_techs)
Home

[Freeciv-Dev] Re: Split patch (was Re: [RFC PATCH] init_techs)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Freeciv Developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Split patch (was Re: [RFC PATCH] init_techs)
From: Justin Moore <justin@xxxxxxxxxxx>
Date: Mon, 24 Sep 2001 20:14:19 -0400 (EDT)

> >    Not very easily.  The options are to a) have the caller malloc a copy
> > of the string and pass it in, or b) malloc X buffers of unknown size ahead
> > of time and pass those in.  The memory management gets tricky.
>
> What about a strdup() in split?

   I could, but I really think all memory allocation and de-allocation
should be done at the same level, so-to-speak.  I've never been a big fan
of strdup.  I'd like to get other people's opinions on this (especially
since I see no compelling reason to do this, but I know it won't get into
CVS until it gets your approval ;p).

> >    Which general purpose method?
>
> cut_comment

   *nod*

> >    It is up to the caller to allocate the array of pointers.  And, yes,
> > they are pointers to buf.  Otherwise it becomes a nightmare trying to do
> > several small mallocs and frees along the way.  I'm open to suggestions on
> > another way to do this, but I find it just easier to accept the fact that
> > the original buffer you pass in will be modified.  If you want an original
> > copy of it, make it before you call split.  How is this restriction bad?
>
> Either the caller allocates the memory and pass the size down to split:
>
> char buffer[10][50];
> ...
> split(...,buffer,10,50);
>
> or split allocates the memory and the caller has the free it.
>
> char *strings[10];
> ...
> n=split(...,strings,10);
> ...
> for(i=0;i<n;i++)
>    free(strings[i]);
>
> IMHO the first one is nicer.

   I agree.  But I don't think we should place limitations on the size of
the buffer(s) in split, which is what your version does.

   On a side note, I'm going to remove the "automatically removes
whitespace" implementation, and require the caller to pass a "\S" as a
token if they want to split on whitespace.  If they want to remove
whitespace surrounding other split tokens, they would pass in a "\s".  A
"\S" implies "\s".

split("\s,", buf, args, 5);

will correctly parse

Alphabet,Iron Working,Pottery, The Wheel

Comments?

-jdm

"You don't give blood then take it back again
 We're all deserving of something more"
 - "Grievance"

Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin@xxxxxxxxxxx



[Prev in Thread] Current Thread [Next in Thread]