[asterisk-dev] [Code Review]: RFC for proposed astobj2 API container enhancements
rmudgett
reviewboard at asterisk.org
Thu Mar 29 14:54:05 CDT 2012
> On March 29, 2012, 9:50 a.m., Mark Michelson wrote:
> > /trunk/include/asterisk/astobj2.h, lines 1596-1600
> > <https://reviewboard.asterisk.org/r/1835/diff/1/?file=26924#file26924line1596>
> >
> > In a hash table, does this mean that the items within a bucket are traversed in descending order AND that the buckets themselves are traversed in descending order?
> >
> > Also, again, the word is "descending".
> >
> > As a final note, you provide preorder and postorder traversal options for ao2_callback(). Shouldn't the same options be available for iterators?
>
> rmudgett wrote:
> Yes the traversal order is as you stated: descending buckets and descending items within the bucket. It doesn't make much difference for a hash container unless it is a degenerate hash container (i.e. a list).
>
> The pre-order and post-order traversal options do not make sense for iterators since those orders require the container structure to remain the same over the traversal. Iterators just about guarantee that is not going to happen because the container is allowed to change during the traversal.
>
> Mark Michelson wrote:
> Okay, I would add some sort of comment here indicating why the pre-order and post-order traversals are not present then. That way it's more clear that their omission was intentional and not an oversight.
Done.
> On March 29, 2012, 9:50 a.m., Mark Michelson wrote:
> > /trunk/include/asterisk/astobj2.h, lines 938-946
> > <https://reviewboard.asterisk.org/r/1835/diff/1/?file=26924#file26924line938>
> >
> > How do you plan to detect a duplicate object?
>
> rmudgett wrote:
> Duplicate objects are easily detectable in sorted containers. Unsorted containers must be searched. I will note that the duplicate option is only applicable to sorted containers.
>
> Mark Michelson wrote:
> To clarify my question more, how do you differentiate between duplicate objects and objects with duplicate keys?
>
> I suppose that my definition of what a duplicate key is may be different from yours. For instance, if you have an object type foo, and it has a field bar within it like:
>
> struct foo {
> char *bar;
> };
>
> Then it is reasonable to assume that we might compare foos by using the comparison function:
>
> int cmp_foo(void *obj, void *arg, int flags)
> {
> struct foo *foo1 = obj;
> struct foo *foo2 = arg;
> return !strcmp(foo1->bar, foo2->bar) ? CMP_MATCH : 0;
> }
>
> Similarly, we may choose to hash foos using the hash function
>
> int hash_foo(const void *obj, int flags)
> {
> struct foo *foo = obj;
> return ast_str_hash(foo->bar);
> }
>
> Now, how do we determine if two foos are duplicates? Is it because cmp_foo() returns CMP_MATCH? Doesn't that just mean the objects have duplicate keys? Or would two foos be considered to have duplicate keys if hash_foo() returns the same value for two foos? If the latter, then what does it mean for an object to have duplicate keys if it is not in a hash container?
Your elaboration further points out reasons why the container must be provided a sort_fn to use the duplicate options. Otherwise there is no way to tell if an object is a duplicate except if the object pointer is equal.
- rmudgett
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1835/#review5906
-----------------------------------------------------------
On March 28, 2012, 10:51 a.m., rmudgett wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1835/
> -----------------------------------------------------------
>
> (Updated March 28, 2012, 10:51 a.m.)
>
>
> Review request for Asterisk Developers, Mark Michelson and Matt Jordan.
>
>
> Summary
> -------
>
> RFC to add proposed API enhancements for containers.
>
> API allows for sorted containers, insertion options, duplicate handling options, and traversal order options.
>
> Also has several documentation corrections.
>
>
> Diffs
> -----
>
> /trunk/include/asterisk/astobj2.h 360708
>
> Diff: https://reviewboard.asterisk.org/r/1835/diff
>
>
> Testing
> -------
>
> It compiles but doesn't link. This is a RFC. :)
>
>
> Thanks,
>
> rmudgett
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120329/9cd16e76/attachment-0001.htm>
More information about the asterisk-dev
mailing list