Re: A question of programming technique in C

"Richard Harter" <cri@tiac.netwrote in message
news:4910af56.146445250@news.sbtc.net...

Quote:

>
>
Suppose we are writing a program in C and that we have a
particular kind of object (in the sense of OO programming) that I
>
will call bobbles. Being well disciplined programmers (Ha!) we
create a module to package our bobble related functions together.

Quote:

I am going to throw in one curve ball. Our program will contain
references to created bobbles; we won't know where these are so
they can go stale when we delete bobbles. The code will need to
be able to detect that a reference has gone stale and deal with
it appropriately.

As I understand this problem: you may have a number of assorted references
to an object.

These objects may be deleted, and you want to verify that an existing
reference still points to an undeleted object.

Your idea of using a unique-id sounds reasonable, but, why not just use the
reference as the unique id?

Then you just need a set containing all the valid references; if a reference
is in the set, then it's valid. Deleting an object removes it's reference
from the set; creating one will add it to the set. (And in C, a set can be
just a hash-array.)

The reference can also become an ordinary C pointer.

--
Bartc

"Bartc" <bc@freeuk.comwrote in message
news:7z5Qk.82734$E41.74102@text.news.virginmedia.c om...

Quote:

"Richard Harter" <cri@tiac.netwrote in message
news:4910af56.146445250@news.sbtc.net...

Quote:

>>
>>
>Suppose we are writing a program in C and that we have a
>particular kind of object (in the sense of OO programming) that I
>>
>will call bobbles. Being well disciplined programmers (Ha!) we
>create a module to package our bobble related functions together.

>

Quote:

>I am going to throw in one curve ball. Our program will contain
>references to created bobbles; we won't know where these are so
>they can go stale when we delete bobbles. The code will need to
>be able to detect that a reference has gone stale and deal with
>it appropriately.

Quote:

Your idea of using a unique-id sounds reasonable, but, why not just use
the reference as the unique id?
>
Then you just need a set containing all the valid references; if a
reference is in the set, then it's valid.
>The reference can also become an ordinary C pointer.

Your later post explains why this simple scheme won't work. A ordinary C
pointer is not good enough because the value is recycled. It needs something
added to it and you end up with something not far off what you started with.

--
Bartc

"Bartc" <bc@freeuk.comwrote in message
news:7z5Qk.82734$E41.74102@text.news.virginmedia.c om...

Quote:

"Richard Harter" <cri@tiac.netwrote in message
news:4910af56.146445250@news.sbtc.net...

Quote:

>>
>>
>Suppose we are writing a program in C and that we have a
>particular kind of object (in the sense of OO programming) that I
>>
>will call bobbles. Being well disciplined programmers (Ha!) we
>create a module to package our bobble related functions together.

>

Quote:

>I am going to throw in one curve ball. Our program will contain
>references to created bobbles; we won't know where these are so
>they can go stale when we delete bobbles. The code will need to
>be able to detect that a reference has gone stale and deal with
>it appropriately.

>
As I understand this problem: you may have a number of assorted
references to an object.
>
These objects may be deleted, and you want to verify that an existing
reference still points to an undeleted object.
>
Your idea of using a unique-id sounds reasonable, but, why not just use
the reference as the unique id?

I've tried some ideas with actual code this time.

I managed to get a workable system along the lines you've been discussing,
but in this case using the serial number as the reference (so no pointers
involved from the 'user' point of view). The interface seen looks like this:

handle=newobj();
setobj(handle,value);
getobj(handle);
delobj(handle);

The key thing being that the handles must be unique and unrepeated during
the lifetime of the program.

--
Bartc

On Wed, 05 Nov 2008 10:36:02 GMT, "Bartc" <bc@freeuk.comwrote:

Quote:

>"Bartc" <bc@freeuk.comwrote in message
>news:7z5Qk.82734$E41.74102@text.news.virginmedia. com...

Quote:

>"Richard Harter" <cri@tiac.netwrote in message
>news:4910af56.146445250@news.sbtc.net...

Quote:

>>>
>>>
>>Suppose we are writing a program in C and that we have a
>>particular kind of object (in the sense of OO programming) that I
>>>
>>will call bobbles. Being well disciplined programmers (Ha!) we
>>create a module to package our bobble related functions together.

>>

Quote:

>>I am going to throw in one curve ball. Our program will contain
>>references to created bobbles; we won't know where these are so
>>they can go stale when we delete bobbles. The code will need to
>>be able to detect that a reference has gone stale and deal with
>>it appropriately.

>>
>As I understand this problem: you may have a number of assorted
>references to an object.
>>
>These objects may be deleted, and you want to verify that an existing
>reference still points to an undeleted object.
>>
>Your idea of using a unique-id sounds reasonable, but, why not just use
>the reference as the unique id?

>
>I've tried some ideas with actual code this time.
>
>I managed to get a workable system along the lines you've been discussing,
>but in this case using the serial number as the reference (so no pointers
>involved from the 'user' point of view). The interface seen looks like this:
>
>handle=newobj();
>setobj(handle,value);
>getobj(handle);
>delobj(handle);
>
>The key thing being that the handles must be unique and unrepeated during
>the lifetime of the program.

Yes, you can do that (using the id as a handle) but then you have
to map the id to the object address; to do that you will need
some sort of data structure to handle the map. At best it will
be costlier than using paired structures.

Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

Re: A question of programming technique in C

re: Re: A question of programming technique in C

re: Re: A question of programming technique in C

re: Re: A question of programming technique in C

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about