Interesting abuses of the object memory layout

[SirG3]

I've come up with a list of interesting abuses of this info:
- Mark & sweep garbage collector
- Serialization
- Cloning objects
- Introspection

Anybody have any more ideas?

-- SirG3

[Thomas Tempelmann]

One more use I find especially important:

"Post mortem" dump of the entire program state.

Meaning that if your program is in a state that it does not like, most
probably because of a bug, it could get the entire set of objects WITH
their values dumped into a file.

This would help in cases where you distribute your program to others
who can't make the effort to debug your code in place. It's
practically the next step after the Stack Trace :)

Would also be nice to get a specific dump that just related to the
locals involved in the stack trace. So that I, the developer, can not
only see where the crash happened but also what variables and
decisions did lead to it.

Getting local objects from the stack should not be too hard, at least
not on Windows, where, as Aaron wrote a while ago in his blog, there's
a function you can call telling you if a value is a valid pointer, and
that way you can look at every 4 byte value on the stack and follow it
if it's not outside valid memory ranges.

[Ed Kleban]

>>
>> I've come up with a list of interesting abuses of this info:
>> - Mark & sweep garbage collector
>> - Serialization
>> - Cloning objects
>> - Introspection

None of these are of particular interest to me. Like Mars said. Sure
they're fun to play with to understand the REALguts. But I've no desire to
make an investement of time in version-specific tools, or basing any serious
code on REALwitchcraft.

On 1/30/06 2:20 AM, "Thomas Tempelmann" <tempe...@gmail.com> wrote:

>
> One more use I find especially important:
>
> "Post mortem" dump of the entire program state.

Now THIS one on the other hand is quite intriguing. Especially if it wasn't
mere for post-mortem use but if you could programmatically generate such a
dump at any point in time for use in a object-oriented, navigational
debugger that would allow you to browse and navigate through the structures
of your code as an alternative to using the IDE debugger -- especially on
compiled programs where the IDE is nowhere in site. I don't know if such a
thing would be possible, and I'm quite sure it isn't anywhere near the top
of my priority list nor probably that of others. But it is indeed
intriguing.

[Scott Steinman]

>>> I've come up with a list of interesting abuses of this info:
>>> - Mark & sweep garbage collector
>>> - Serialization
>>> - Cloning objects
>>> - Introspection

There are applications for most of these. A mark & sweep garbage
collector probably isn't the most important because REALbasic already
has garbage collection. However:

- Serialization, especially to the built-in SQLite database, could
provide for object persistence.
- Cloning objects is something I'm surprised isn't already in
REALbasic, both shallow and deep clones.
- Introspection, though "expensive" to use, can be very useful in
some design patterns.

Dr. Scott Steinman
Brought to you by a grant from the Steinman Foundation (Thanks, Mom
and Dad!)
Recommended by Major University Studies Over the Leading Brand
steinman at midsouth dot rr dot com

I hope I die peacefully in my sleep like my grandfather. . .not
screaming in terror like his passengers. -- "Deep Thoughts", Jack Handy