On Tue, 2007-05-22 at 16:08 -0700, dave wrote: > There is also an augment for "reinventing the wheel". Aside from > the experience and insight you'll get, simply jumping on the latest > glib,stl,GC, or whatever bandwagon can have unintended consequences. > There is always a price to be paid for overly generic code, usually > performance and memory usage. The classic "simple" example is using > "strcmp" to test if two strings are not equal. Almost any first year > CS student could write a more efficient function.
Not even strcmp should be used anymore since it can't support non-ANSI encodings. Consider it highly deprecated. It was nice when it was actually useful, since it was a portable function that always worked. That's the reason you don't ever want to re-implement a library function, generic trade-offs notwithstanding. Fortunately new libraries are out now on all platforms to address character set issues. I've finally had enough experience to know that "re-inventing the wheel" is almost always a bad idea (in the narrow sense of duplicating library functionality), if you ever want to port your code to *any* other platform. What you may think is a wonderful hack or trade-off to get a tiny bit of speed will almost certainly come back to bite you down the road. Also, most generic algorithms are already optimized more than you'll be able to do by hand generally (barring assembly), particularly in the STL. Years ago, the specialized math libraries, hand-coded in assembly, were all the rage. Then someone came along and wrote a special library-generating library that could create generic math routines for any architecture in a portable way, and matched the straight-assembly routines in almost every way. No one uses hand-coded math libraries anymore. Remember, make the common case fast. Any other optimization should be secondary, including re-inventing the wheel of common, generic algorithms. > All these libs are a wonderful help, but one should be careful if > your code has performance and/or memory constraints. This is > especially true when you go to "managed" code. Garbage collection is > not cheap. What is this "garbage collection" of which you speak? :) > > dave > -------------------- > 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 > -------------------- 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
