Re: a GList of g_object_add_weak_pointer()s



On Thu, Mar 01, 2007 at 06:38:48PM -0800, Rick Jones wrote:
I am in the midst of fitfully trying to convert netperf4 
(http://www.netperf.org/svn/netperf4/trunk/ to use GObject.  In netperf4 
there are these things (soon to be objects) called "tests" and a test 
can be dependent upon another test.  Several tests can depend on a given 
test.  I figured that a GList (into glib for a penny, in for a pound I 
figure) of g_object_add_weak_pointer() references would then allow the 
test on which the other N tests are dependent to send each of them a 
signal via a "foreach" when it was setup and they could proceede.

The problem is that g_list_append() wants a pointer value, but 
g_object_add_weak_pointer() wants a place to stuff the pointer - the 
GList node won't really exist until g_list_append() completes, which 
leaves me a chicken and egg situation.  I suppose I could just pass 
g_list_appeand() NULL, but (yes, I should look at the source or write a 
test program :) would g_list_append() actually like that?

I don't really want to allocate another bit of memory to hold the 
reference, I'd like to have it in the data field of the GList node.

Suggestions?

I was thinking that I could have a dummy area that I pass to 
g_list_append(), and then I could pass &(node->data) to 
g_object_add_weak_pointer().

Exactly, except for the `dummy area' which reveals some
misunderstanding.  The pointer passed to g_list_append() is
just a value.  If you for some reason don't know the value
at the time you are creating the item for it, just assign
the right value to item->data later, pass it to
g_object_add_weak_pointer(), or whatever.

However I don't understand why you can't do just this:

  p = some_object_new();
  item = g_list_append(NULL, p);
  g_object_add_weak_pointer(p, &item->data);
  list = g_list_concat(item, list);
  /* or g_list_concat(l, i), but that's inefficient, it's
   * better to construct the list in reverse order and then
   * do g_list_reverse() */

However, if the data structures do not change (or seldom
change) after construction, it would not use lists, they
bring no advantage in this case and they have bad data
locality, pointer arrays would be better.

Yeti


--
Whatever.



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