Dear Konovalov, Vadim
> Sounds naïve.
Maybe it is. But if you don't try you've failed from the very beginning ;)
But let me give you an example:
sturt foo {
char bar[LENGTH]
int something_else;
}
foo s;
for (i = 0, i <= LENGTH, i++){
s.bar[i] = '\x0';
}
Of coure there is a bug, and this happens.
Now the code above overrides s.something_else by accident.
This can lead to hard to find bugs.
How could such be fixed? Introducing type classes:
class MemoryManagementFor foo {
memory_layout = # compile time thing describing how to layout the
# struct fields in memory.
# if you have "debug mode", separate struct fields by
# 8 bytes
# thus this code gets evaluated at compile time and
# returns a list of "struct fields" and memory
# position/sizes.
# This would also add a check sum field, see new/free
new :: # alloc such a thing, zero byte it, in debug mode fill those
# dummy 8 bytes by random bytes, and calculate a check sum
free :: # free such a thing, if debug mode, check that the check sum
# still matches the initial random bytes
}
Now if free detects failure, you know where to start looking for bugs.
When could such an implementation possibly fail? If you want to "stream"
to a file, having random bytes could be harmfull. Again, you just create
a new type class
class WriteToFileHandle where
write handle struct = # if debug then omit random bytes
and you're done. Now tell me how I can do that with C/C++?
Maybe such solutions exist. I'm pretty confident that such tooling built
into a compiler does help gitting stable code much more than valgrind.
Now you can continue with
foo a = new(); // and get the debug layout eventually.
free(a): // and this would check that no memory corruption happened.
But if you know a tool which is as smart as I told above, let me know
and teach me, please. I know that this can be done. And in fact I want
to do that. Thus if thus tooling is not available yet, I have to write
it.
> Does the idea have something brilliant in it that makes it different from
> a dozen of already failed projects in this list -
> http://www.freehackers.org/VimIntegration
Thanks for sharing this nice list. I've added this link to my wiki.
Still collecting ideas from community. I'v already published my own list
of things I'd like to fix. Whether that's enough to become more
brilliant is something you have to judge.
Marc Weber
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
