On Tuesday 22 May 2007 02:37:34 pm Michael L Torrie wrote: > Having written a nice 10,000 line straight C app with tons of dynamic > memory stuff (lots of variable tree structures), I have to agree. I > had only one minor memory leak in all that code (relating to creating > and destroying the complex tree structures). > > On the other hand, Python gives me such a warm fuzzy feeling. :)
That's why these scripting languages are becoming so popular. Unfortunately, hardly anything can beat C for power and speed. There are two ways to do things in C (or C++): the hard way and the easy way. The hard way is to simply reinvent the wheel every time. the easy way is to grab a library that implements the feature you want. As it was mentioned earlier, there is Glib that implements these sorts of tools. (Glib also has a C++ counterpart). Although the purists will probably say you are cheating, I disagree. Your are being smart. One of C's biggest challenges is memory management. These libraries have already been tested and are known to work. Any new code you may reinvent, even for educational purposes, is likely to contain bugs. There is also another library called GC which implements a garbage collector for C/C++. I don't think it's use would yield much if you are using Glib since Glib already takes care of many such administrative things. Straying more from the original topic, you can use Java which already has great array support built in. With the later GCC's you can even compile Java to native code instead of bytecode. The other option is to use D (www.ditigalmars.com/d) which is a C ABI compatible language but already contains great memory management and array support. Unfortunately, D is rather obscure and getting the compiler and libraries to work can sometimes be a challenge in and of itself. That's my $0.00000000000000002 worth. -- Alberto Treviño [EMAIL PROTECTED] CID Testing Center Brigham Young University -------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
