Re: GList changes

In message <>Owen Taylor writes
>Karl Nelson <> 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.


  GList *head,*i;
  /*... 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]