event queue / checking if pointers are still valid

[copx]

How do you implement an event queue in C? The problem I had is that events
needed pointers to the objects they affect and I do not know any way to
check if pointers are actually valid in C. The main issue is that the
objects an event data structure points two might be removed before the event
is executed. The only solution I came up with was scanning the entire queue
each time an object was destroyed to remove all references to it. That was
rather ugly.
Also serializing (i.e. saving to disk) pointer-based structures is horrible
in C. You can not just save/restore pointers instead you have to translate
them to something else. I usually translate them to index values which works
but requires a lot of code (especially if you need to save/restore lots of
pointers who point to data in different data structures).
So what is the elegant way to implement an event queue in C?

[Vladimir S. Oka]

copx wrote:

How do you implement an event queue in C? The problem I had is that events
needed pointers to the objects they affect and I do not know any way to
check if pointers are actually valid in C.
I don't think there /is/ a way to ensure a C pointer is valid.
The main issue is that the
objects an event data structure points two might be removed before the event
is executed. The only solution I came up with was scanning the entire queue
each time an object was destroyed to remove all references to it. That was
rather ugly.
Not really a C question, you may be better of in comp.programming.

Shooting from the hip: Why don't you construct your objects in a way
that allows them to point to a queue member created for the event? That
way, when destroying object you can destroy their events as well very
easily.This becomes non-trivial, but still posible, if the object may
be used by multiple events.
Also serializing (i.e. saving to disk) pointer-based structures is horrible
in C. You can not just save/restore pointers instead you have to translate
them to something else. I usually translate them to index values which works
but requires a lot of code (especially if you need to save/restore lots of
pointers who point to data in different data structures).
So what is the elegant way to implement an event queue in C?

Define "elegant" and "queue".

--
BR, Vladimir

[copx]

"Vladimir S. Oka" <no****@btopenworld.com> schrieb im Newsbeitrag
news:11*********************@g10g2000cwb.googlegro ups.com...

copx wrote:

How do you implement an event queue in C? The problem I had is that
events
needed pointers to the objects they affect and I do not know any way to
check if pointers are actually valid in C.
I don't think there /is/ a way to ensure a C pointer is valid.

...and that is the problem.

The main issue is that the
objects an event data structure points two might be removed before the
event
is executed. The only solution I came up with was scanning the entire
queue
each time an object was destroyed to remove all references to it. That
was
rather ugly.

Not really a C question, you may be better of in comp.programming.

I do think it is a C question. Because my problems are caused by C-style
pointers. In many other languages object references are verifiable and some
have built-in serialization too.
Shooting from the hip: Why don't you construct your objects in a way
that allows them to point to a queue member created for the event? That
way, when destroying object you can destroy their events as well very
easily.This becomes non-trivial, but still posible, if the object may
be used by multiple events.

Objects being references by multiple events is the norm in my case. And in
that case the suggested solution is even worse than just scanning the entire
queue (given the fact that the queue is never THAT long).

[Chris Dollin]

copx wrote:

How do you implement an event queue in C? The problem I had is that events
needed pointers to the objects they affect and I do not know any way to
check if pointers are actually valid in C.
There isn't one (in portable C).
The main issue is that the
objects an event data structure points two might be removed before the
event is executed.
That would be a mistake.

Clearly, if a pending event may refer to objects, they /must not/ be
removed until the event is dequeued (or itself deleted).
Also serializing (i.e. saving to disk) pointer-based structures is
horrible in C. You can not just save/restore pointers instead you have to
translate them to something else.
Well, yes. (I don't see what this has to do with event queues, mind.)
I usually translate them to index values
which works but requires a lot of code (especially if you need to
save/restore lots of pointers who point to data in different data
structures).

I'd take the same brute-force approach as above: if it's that hard,
probably I'm building the wrong kind of data-structures: I should
build ones that I can (de)serialise conveniently.

As usual, specific examples are easier to argue about than abstractions.

--
Chris "x.f(y) == f(x, y) == (x, y).f" Dollin
The shortcuts are all full of people using them.

[Richard Tobin]

In article <e0*************@news.t-online.com>,
copx <in*****@invalid.com> wrote:

Not really a C question, you may be better of in comp.programming.

I do think it is a C question. Because my problems are caused by C-style
pointers. In many other languages object references are verifiable and some
have built-in serialization too.

Perhaps you should look into how those languages are implemented?

-- Richard

[copx]

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> schrieb im Newsbeitrag
news:e0***********@pc-news.cogsci.ed.ac.uk...

In article <e0*************@news.t-online.com>,
copx <in*****@invalid.com> wrote:

Not really a C question, you may be better of in comp.programming.

I do think it is a C question. Because my problems are caused by C-style
pointers. In many other languages object references are verifiable and
some
have built-in serialization too.

Perhaps you should look into how those languages are implemented?

AFAIK all those languages are very high-level and use garbage
collection/automatic memory management. That is why they are able to know if
object references are valid or not I think. Adding all this to C is a bit
much and I do not want to use garbage collection either.

[Vladimir S. Oka]

copx wrote:

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> schrieb im Newsbeitrag
news:e0***********@pc-news.cogsci.ed.ac.uk...

In article <e0*************@news.t-online.com>,
copx <in*****@invalid.com> wrote:

Not really a C question, you may be better of in comp.programming.

I do think it is a C question. Because my problems are caused by C-style
pointers. In many other languages object references are verifiable and
some
have built-in serialization too.

Perhaps you should look into how those languages are implemented?

AFAIK all those languages are very high-level and use garbage
collection/automatic memory management. That is why they are able to know if
object references are valid or not I think. Adding all this to C is a bit
much and I do not want to use garbage collection either.

So it seems you already know you don't want to use C...

--
BR, Vladimir

[Mark McIntyre]

On Fri, 24 Mar 2006 13:00:59 +0100, in comp.lang.c , "copx"
<in*****@invalid.com> wrote:

"Vladimir S. Oka" <no****@btopenworld.com> schrieb im Newsbeitrag
news:11*********************@g10g2000cwb.googlegr oups.com...

I don't think there /is/ a way to ensure a C pointer is valid.
..and that is the problem.

Then you either live with it, or use a different language, I'm afraid.

Not really a C question, you may be better of in comp.programming.

I do think it is a C question. Because my problems are caused by C-style
pointers.

That doesn't make it a C question. Its really about an efficient
algorithm for doing whatever it is you want to do.
In many other languages object references are verifiable and some
have built-in serialization too.

You could use one of those instead I guess, if this is a showstopper.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan