Re: glib: changes to the g*_array API.



On Tue, 3 Nov 1998, Sebastian Wilhelmi wrote:

> Hi,
> 
> as I think we reached consensus on that, I commit the following changes:
> 
> 1998-11-03  Sebastian Wilhelmi  <wilhelmi@ira.uka.de>
> 
> 	* glib.h: 
> 	* garray.h:
> 	(g_array_remove_index): new function for removing an entry from an
> 	array while preserving the order
> 	(g_array_remove_index_fast): new function for removing an entry
> 	from an array. the order might be distorted
> 	(g_ptr_array_remove_index_fast, g_ptr_array_remove_fast): new
> 	functions; working similiar to the above. (they have the semantic
> 	of the old g_ptr_array_remove[_index] functions)
> 	(g_ptr_array_remove_index, g_ptr_array_remove): new semantic. now
> 	the order of the elements in the array is not changed
> 	(g_byte_array_remove_index, g_byte_array_remove_index_fast): new
> 	functions; byte_array wrapper for g_array_remove_index[_fast]
> 
> Hope, thats ok.
> 
> Bye
> Sebastian
> 
> P.S.: I still think, its too much code duplication, an argument would have
> been better.

the committed versions are probably ok, though i would have named
g_array_remove_index_fast more like g_array_remove_index_unordered or something
the like, but taht's no real concern...
hm, what i actually meant to say is that if you worry about code duplication,
you can just do

static inline void
remove_index (GRealArray *array,
              gboolean    keep_order)
{ ... }

GArray*
g_array_remove_index_fast (GArray* array,
                           guint   index)
{
  g_return_val_if_fail (array, NULL);
  g_return_val_if_fail (index >= 0 && index < array->len, NULL);

  remove_index ((GRealArray*) array, FALSE);
  
  return array;
}

GArray*
g_array_remove_index (GArray* farray,
                      guint   index)
{
  g_return_val_if_fail (array, NULL);
  g_return_val_if_fail (index >= 0 && index < array->len, NULL);

  remove_index ((GRealArray*) array, TRUE);
  
  return array;
}

e.g. gdataset.c does this for g_data_set_internal() which is the core
function of the whole mechanism and is called from four places with only
slight adjustments. since the code is actually highly sensible wrt reentrancy,
(faulty) code duplication was a real concern there.

---
ciaoTJ



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