From: Miklos Vajna <vmiklos@frugalware.org>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Olivier Marin <dkr+ml.git@free.fr>,
Junio C Hamano <gitster@pobox.com>,
Don Zickus <dzickus@redhat.com>,
git@vger.kernel.org
Subject: [PATCH] path-list documentation: document all functions and data structures
Date: Sun, 15 Jun 2008 14:06:43 +0200 [thread overview]
Message-ID: <1213531603-8364-1-git-send-email-vmiklos@frugalware.org> (raw)
In-Reply-To: <m3k5groyw8.fsf@localhost.localdomain>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sun, Jun 15, 2008 at 02:01:19AM -0700, Jakub Narebski <jnareb@gmail.com> wrote:
> > +NOTE: It is more efficient to build an unsorted list and sort it
> > +afterwards, instead of building a sorted list `(O(n log n)` instead
> > of
> > +`O(n^2))`.
>
> I think there is typo here (misplaced backticks '`' on the wrong side
> of enclosing parentheses), and this fragment should read:
>
> +afterwards, instead of building a sorted list (`O(n log n)` instead
> of
> +`O(n^2)`).
Exactly, thanks for pointing out. Updated patch below.
Documentation/technical/api-path-list.txt | 125 ++++++++++++++++++++++++++++-
1 files changed, 121 insertions(+), 4 deletions(-)
diff --git a/Documentation/technical/api-path-list.txt b/Documentation/technical/api-path-list.txt
index d077683..9dbedd0 100644
--- a/Documentation/technical/api-path-list.txt
+++ b/Documentation/technical/api-path-list.txt
@@ -1,9 +1,126 @@
path-list API
=============
-Talk about <path-list.h>, things like
+The path_list API offers a data structure and functions to handle sorted
+and unsorted string lists.
-* it is not just paths but strings in general;
-* the calling sequence.
+The name is a bit misleading, a path_list may store not only paths but
+strings in general.
-(Dscho)
+The caller:
+
+. Allocates and clears a `struct path_list` variable.
+
+. Initializes the members. You might want to set the flag `strdup_paths`
+ if the strings should be strdup()ed. For example, this is necessary
+ when you add something like git_path("..."), since that function returns
+ a static buffer that will change with the next call to git_path().
++
+If you need something advanced, you can manually malloc() the `items`
+member (you need this if you add things later) and you should set the
+`nr` and `alloc` members in that case, too.
+
+. Adds new items to the list, using `path_list_append` or `path_list_insert`.
+
+. Can check if a string is in the list using `path_list_has_path` or
+ `unsorted_path_list_has_path` and get it from the list using
+ `path_list_lookup` for sorted lists.
+
+. Can sort an unsorted list using `sort_path_list`.
+
+. Finally it should free the list using `path_list_clear`.
+
+Example:
+
+----
+struct path_list list;
+int i;
+
+memset(&list, 0, sizeof(struct path_list));
+path_list_append("foo", &list);
+path_list_append("bar", &list);
+for (i = 0; i < list.nr; i++)
+ printf("%s\n", list.items[i].path)
+----
+
+NOTE: It is more efficient to build an unsorted list and sort it
+afterwards, instead of building a sorted list (`O(n log n)` instead of
+`O(n^2)`).
++
+However, if you use the list to check if a certain string was added
+already, you should not do that (using unsorted_path_list_has_path()),
+because the complexity would be quadratic again (but with a worse factor).
+
+Functions
+---------
+
+* General ones (works with sorted and unsorted lists as well)
+
+`print_path_list`::
+
+ Dump a path_list to stdout, useful mainly for debugging purposes. It
+ can take an optional header argument and it writes out the
+ string-pointer pairs of the path_list, each one in its own line.
+
+`path_list_clear`::
+
+ Free a path_list. The `path` pointer of the items will be freed in case
+ the `strdup_paths` member of the path_list is set. The second parameter
+ controls if the `util` pointer of the items should be freed or not.
+
+* Functions for sorted lists only
+
+`path_list_has_path`::
+
+ Determine if the path_list has a given string or not.
+
+`path_list_insert`::
+
+ Insert a new element to the path_list. The returned pointer can be handy
+ if you want to write something to the `util` pointer of the
+ path_list_item containing the just added string.
++
+Since this function uses xrealloc() (which die()s if it fails) if the
+list needs to grow, it is safe not to check the pointer. I.e. you may
+write `path_list_insert(...)->util = ...;`.
+
+`path_list_lookup`::
+
+ Look up a given string in the path_list, returning the containing
+ path_list_item. If the string is not found, NULL is returned.
+
+* Functions for unsorted lists only
+
+`path_list_append`::
+
+ Append a new string to the end of the path_list.
+
+`sort_path_list`::
+
+ Make an unsorted list sorted.
+
+`unsorted_path_list_has_path`::
+
+ It's like `path_list_has_path()` but for unsorted lists.
++
+This function needs to look through all items, as opposed to its
+counterpart for sorted lists, which performs a binary search.
+
+Data structures
+---------------
+
+* `struct path_list_item`
+
+Represents an item of the list. The `path` member is a pointer to the
+string, and you may use the `util` member for any purpose, if you want.
+
+* `struct path_list`
+
+Represents the list itself.
+
+. The array of items are available via the `items` member.
+. The `nr` member contains the number of items stored in the list.
+. The `alloc` member is used to avoid reallocating at every insertion.
+ You should not tamper with it.
+. Setting the `strdup_paths` member to 1 will strdup() the strings
+ before adding them, see above.
--
1.5.6.rc2.dirty
next prev parent reply other threads:[~2008-06-15 12:07 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-13 16:55 [PATCH] git-apply doesn't handle same name patches well Don Zickus
2008-06-13 20:32 ` Johannes Schindelin
2008-06-13 20:42 ` Don Zickus
2008-06-13 22:48 ` [PATCH] path-list documentation: document all functions and data structures Miklos Vajna
2008-06-13 23:30 ` Olivier Marin
2008-06-14 0:13 ` Miklos Vajna
2008-06-14 0:56 ` Miklos Vajna
2008-06-14 12:50 ` Olivier Marin
2008-06-14 22:50 ` Miklos Vajna
2008-06-14 18:08 ` Johannes Schindelin
2008-06-14 23:22 ` Miklos Vajna
2008-06-15 9:01 ` Jakub Narebski
2008-06-15 12:06 ` Miklos Vajna [this message]
2008-06-15 5:04 ` Junio C Hamano
2008-06-16 9:01 ` [PATCH] git-apply doesn't handle same name patches well Mike Ralphson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1213531603-8364-1-git-send-email-vmiklos@frugalware.org \
--to=vmiklos@frugalware.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=dkr+ml.git@free.fr \
--cc=dzickus@redhat.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).