[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
to GList or not to GList?
- From: Joshua N Pritikin <vishnu pobox com>
- To: gtk-app-devel-list gnome org
- Subject: to GList or not to GList?
- Date: Tue, 31 Jul 2001 19:22:00 +0530
i've implement linked-lists about a million times, but i'm still confused.
The GList structure is stored separately from the data. What is the
rationale for this organization? Is it mainly for GINT_TO_POINTER & friends?
To contrast, here is a linked-list implementation that must be embedded in
the data object (see MIME attachment). For example,
struct mydata {
pe_ring peer;
pe_ring queue;
gint hits;
gint priority;
};
In some cases, this organization seems like a better fit for the problem.
Ignoring the question of API freezes, would such an embedded list be appropriate
for inclusion in glib? Or is this style of design generally a bad idea?
--
Get self-realization at <http://sahajayoga.org> ... <http://why-compete.org> ?
Victory to the Divine Mother!!
struct pe_ring { void *self; pe_ring *next, *prev; };
#define PE_RING_INIT(LNK, SELF) \
STMT_START { \
(LNK)->next = LNK; \
(LNK)->prev = LNK; \
(LNK)->self = SELF; \
} STMT_END
#define PE_RING_EMPTY(LNK) ((LNK)->next == LNK)
#define PE_RING_UNSHIFT(LNK, ALL) \
STMT_START { \
assert((LNK)->next==LNK); \
(LNK)->next = (ALL)->next; \
(LNK)->prev = ALL; \
(LNK)->next->prev = LNK; \
(LNK)->prev->next = LNK; \
} STMT_END
#define PE_RING_ADD_BEFORE(L1,L2) \
STMT_START { \
assert((L1)->next==L1); \
(L1)->next = L2; \
(L1)->prev = (L2)->prev; \
(L1)->next->prev = L1; \
(L1)->prev->next = L1; \
} STMT_END
#define PE_RING_DETACH(LNK) \
STMT_START { \
if ((LNK)->next != LNK) { \
(LNK)->next->prev = (LNK)->prev; \
(LNK)->prev->next = (LNK)->next; \
(LNK)->next = LNK; \
} \
} STMT_END
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]