| |
In lugnet.robotics.rcx.java, Tyler Derkin wrote:
> In lugnet.robotics.rcx.java, Chris Phillips wrote:
>
> Hahaha,
>
> Your passionate condemnation of GC makes entertaining reading in light of the
> amount of work I have to do with lejos,Java,C++, etc for my final year
> undergraduate project. I will certainly pass some of your comments and remarks
> to one of my professor's who's teaching me a module in compiler construction.
>
> Anyway, thanks for your code snippet. I've tried it out and it works!! Thank you
> ever so much for your help. Finally, I can get on with other parts of my
> project. Thanks again.
>
> Tyler
Tyler,
Happy to be of help!
Regarding Garbage Collection, I'm not usually one to criticise without being
able to suggest a better alternative. In this case, I think most GC systems
could be improved by mimicking the concept of "smart pointers" from the COM
(Component Object Model) world.
COM uses the concept of reference counting on interface pointers. Every time
you store a pointer to an object, you increment the reference count on that
object. When you are done holding the pointer, you decrement the count again.
When the reference count on the object reaches zero, it is immediately deleted
from memory.
This works well as long as the programmer remembers to increment and decrement
the reference counts properly. However, it is easy to make mistakes, and so
improper reference counting is often the source of crashes and memory leaks in
COM programs. Enter Smart Pointers.
Some of the gurus of COM programming created C++ template classes that wrapped
interface pointers with automatic reference counting. Although this system was
by no means foolproof (mainly due to the extreme flexibility of the C++ language
which always seems to open new loopholes) it made reference counting errors much
less likely to occur.
In a language like Java, where every pointer is a reference, the concept of
Smart Pointers could easily have been employed at a level where it would be
impossible to circumvent. Assigning 'null' into an object reference (or any
other value) could automatically decrement and increment all of the affected
pointers. When an object has no remaining references (which is the same basis
by which any GC system determines that it may reclaim an object), it could be
immediately deleted. This would eliminate much of the arbitrary behavior that a
GC system brings to a program by making object deletion a predictable occurrence
instead of leaving it at the whim of the language implementation.
In your example, the system would decrement the reference counts on the RCXPort
and stream objects automatically when your 'port', 'dis' and 'dos' variables
went out-of-scope, which would have automatically released the RCXPort object
and prevented this problem.
Anyway, I'm glad I was able to help you figure out what was going on. Good luck
with your project, and don't forget to return those empties!
- Chris.
FUT lugnet.off-topic.geek
|
|
Message is in Reply To:
 | | Re: Opening COM port error
|
| In lugnet.robotics.rcx.java, Chris Phillips wrote: Hahaha, Your passionate condemnation of GC makes entertaining reading in light of the amount of work I have to do with lejos,Java,C++, etc for my final year undergraduate project. I will certainly (...) (21 years ago, 30-Nov-03, to lugnet.robotics.rcx.java)
|
6 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
