Re: GList changes

[Karl Nelson <kenelson ece ucdavis edu>]

In message <ybelnbdxg3v.fsf@fresnel.labs.redhat.com>Owen Taylor writes
>
>Karl Nelson <kenelson@ece.ucdavis.edu> writes:
>
>> Hmm.  They ere both taken from head.  It seems most likely that
>> my mailer killed something when I tried to include it in the 
>> message.  
>
>Without even context diffs, it's pretty hard to figure
>out what is going on or read the diffs. ;-)

Yeah,  I goofed that one up. :-)

>> I was just trying to make seperate the head of the list argument
>> from the iterator to which the insertion should occur.  It makes
>> some code much more understandable if the head and iterator are
>> not the same.  Especially the case of a tail insertion where
>> the tail must be kept.  (C++ iterators)
> 
>Is there a difference between what you want and 
>what Tim proposed? I don't really see how Tim's
>interfaces confuse the head and "iterator".
>But very possibly, I don't understand what
>you mean by "iterator" here.

No, Tim and I are of the same mind on this one.  What I was proposing
was exactly the same thing that he was working on.   The
old iterface were to add to a list and not have to scroll
all the way through it is confusion the iterator (place to
do the insertion) and the list.

Ie. 

  GList *head,*i;
  head=g_list_append(head,p1);
  head=g_list_append(head,p2);
  head=g_list_append(head,p3);
  /*... i ends up somewhere in head */

  g_list_insert(i,p4,0);  // is this going to change the head or not?

Thus you must check to see if the location of insert matchs
the head.


>If I was writing the code in an app, I would certainly
>make other calls wrappers for g_[s]list_insert_[before/after]. 
>For GLib, it's more of a close call, since it is code that needs
>only to be written once, and performance is a big factor for GTK+.
>
>But for cases where the difference is _only_ the extra
>function call overhead, then I think we should fold
>the calls. In fact, if function call overhead is a big concern, 
>we could always make a statically inline _g_list_insert_before
>and make everything call that. [ That does assume
>that the function isn't complex enough to prevent
>it from being inlined. ]

Agree.  However, I am guessing the all 3 of the current
could be inline of the others.  

>Because the code takes
>
>  insert_before(NULL) => append.
>
>Admittedly, the above looks confusingly like buggy code
>to the casual reader, and I'd be tempted to put
>a insert_after() in for that reason.

Yep.  That was my thought.  However, I guess
mine has a bug because it looks like 
insert_before(NULL) is insert before the end.

--Karl