| author | Jimmy Tang <jtang@tchpc.tcd.ie> | 2011-07-16 11:41:10 (GMT) |
|---|---|---|
| committer | Jimmy Tang <jtang@tchpc.tcd.ie> | 2011-07-16 11:41:10 (GMT) |
| commit | 11fa7dd2db350e1c44393d2078adfa1e720520e3 (patch) (side-by-side diff) | |
| tree | b6a9cbfff1b1003a015b2a50d459bd75999e37b1 | |
| parent | fc35b9219204705c86e8087c741e35aad7fb4dc2 (diff) | |
| download | wiki-11fa7dd2db350e1c44393d2078adfa1e720520e3.tar.gz wiki-11fa7dd2db350e1c44393d2078adfa1e720520e3.tar.bz2 wiki-11fa7dd2db350e1c44393d2078adfa1e720520e3.tar | |
short post
| -rw-r--r-- | blog/posts/Memory_debuggers_and_garbage_collectors_for_C__47__C++.mdwn | 30 |
1 files changed, 30 insertions, 0 deletions
diff --git a/blog/posts/Memory_debuggers_and_garbage_collectors_for_C__47__C++.mdwn b/blog/posts/Memory_debuggers_and_garbage_collectors_for_C__47__C++.mdwn index 8f6fbab..2bd9377 100644 --- a/blog/posts/Memory_debuggers_and_garbage_collectors_for_C__47__C++.mdwn +++ b/blog/posts/Memory_debuggers_and_garbage_collectors_for_C__47__C++.mdwn @@ -1,6 +1,36 @@ [[!google linux software draft]] +Usually I come across relatively well written pieces of code. That is +code that is broken up with 50-60 lines per function and not 1000+ +line long functions. Recently I was given a code written by a +scientist (I think he is a physicist), and it does some rather clever +stuff scientifically. However everything is in one big main() +function. + +The code mostly ran, and occassionally failed with no apparent +reason. The first few things I did was to format/indent the code as +much as I could and I started to replace all the malloc/free and some +of the string functions with wrapper functions to sanitise everything. + +It then occured to me that I should probably run the code through +[valgrind][] or something similar to debug the malloc/free +calls. Traditionally I would have used electricfence during testing, +bug fixing and development. I saw this opportunity to see what else is +out there. I had known about [gc][] for a while but never really got +around to using it, I'm quite happy to say that it's pretty easy to +use and it seems okay for doing garbage collection. It is particularly +useful but requires a small bit of work with existing codes. + +I was however surprised with [google-perftools][], I had realised that +it was a malloc() replacement and that it provided a bunch of +profiling and checking features. Best of it is relatively easy to use, +short and concise. I've yet to read up on the garbage collection +features in this library, assuming there is garbage collection. I can +see myself using this library a bit more when I write C or when I have +to fix someone elses code. + [google-perftools]: http://code.google.com/p/google-perftools/ [gc]: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ +[valgrind]: http://valgrind.org/ [[!template id=related tagged="tagged(software) or tagged(linux)"]] |
