summaryrefslogtreecommitdiffstats
authorJimmy 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)
commit11fa7dd2db350e1c44393d2078adfa1e720520e3 (patch) (side-by-side diff)
treeb6a9cbfff1b1003a015b2a50d459bd75999e37b1
parentfc35b9219204705c86e8087c741e35aad7fb4dc2 (diff)
downloadwiki-11fa7dd2db350e1c44393d2078adfa1e720520e3.tar.gz
wiki-11fa7dd2db350e1c44393d2078adfa1e720520e3.tar.bz2
wiki-11fa7dd2db350e1c44393d2078adfa1e720520e3.tar
short post
Diffstat (more/less context) (ignore whitespace changes)
-rw-r--r--blog/posts/Memory_debuggers_and_garbage_collectors_for_C__47__C++.mdwn30
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)"]]