On Wed, 5 Nov 2008 00:37:50 -0800 (PST), Nick Keighley
<nick_keighley_ nospam@hotmail. comwrote:
I dare say you think that, but you are wrong to do so. First of
all, it is a requirement rather than design. Secondly it is a
quite normal requirement in an asynchronous message passing
environment with transient entities.
C++ may will have the same issues; however the question at hand
is how to deal with the problem in C.
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.
<nick_keighley_ nospam@hotmail. comwrote:
>On 4 Nov, 20:24, c...@tiac.net (Richard Harter) wrote:
>
>
>I seem to do a fair amount of rolling my own in C++ as well...
>(but then some argue C++ isn't a very good OO language)
>
>
>
>I think your design is broken at this point.
>
>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. =A0Being well disciplined programmers (Ha!) we
>create a module to package our bobble related functions together.
>>
>If we were using an OO based language there would be machinery in
>place, constructors, destructors, and such like, to handle the
>details of our module, but in C we have to roll our own.
>particular kind of object (in the sense of OO programming) that I
>will call bobbles. =A0Being well disciplined programmers (Ha!) we
>create a module to package our bobble related functions together.
>>
>If we were using an OO based language there would be machinery in
>place, constructors, destructors, and such like, to handle the
>details of our module, but in C we have to roll our own.
>I seem to do a fair amount of rolling my own in C++ as well...
>(but then some argue C++ isn't a very good OO language)
>
>
>One of the things we need to do is to create functions that will
>serve as constructors and destructors. =A0There are two things that
>we have to take care of, specifying the interface, and writing
>the function internals. =A0My concern is with specifying the
>interface.
>>
>I am going to throw in one curve ball. =A0Our program will contain
>references to created bobbles; we won't know where these are so
>they can go stale when we delete bobbles. =A0The code will need to
>be able to detect that a reference has gone stale and deal with
>it appropriately.
>serve as constructors and destructors. =A0There are two things that
>we have to take care of, specifying the interface, and writing
>the function internals. =A0My concern is with specifying the
>interface.
>>
>I am going to throw in one curve ball. =A0Our program will contain
>references to created bobbles; we won't know where these are so
>they can go stale when we delete bobbles. =A0The code will need to
>be able to detect that a reference has gone stale and deal with
>it appropriately.
>I think your design is broken at this point.
all, it is a requirement rather than design. Secondly it is a
quite normal requirement in an asynchronous message passing
environment with transient entities.
>This isn't a C
>problem you'd have exactly the same issues with C++ despite
>it's "machinary" .
>problem you'd have exactly the same issues with C++ despite
>it's "machinary" .
is how to deal with the problem in C.
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.