On Thu, Mar 20, 2003 at 10:15:43AM -0800, Tim Riley wrote: > > > > The first library had malloc(). Always > > using calloc() would be a ridiculously inefficient way to obtain > > memory if you're going to just set it again anyway. > > It might seem inefficient to set memory twice, but you're looking > at it from the CPU's point of view. Instead, by looking at it from > the programmer's point of view, the extra nanoseconds it takes > to always get a clean data structure is worth hours of time savings > by not having to trace a core dump.
You're saying that you'd rather have your program silently set the wrong memory location than to vomit? In my experience, the earlier in the development stage you catch a bug, the better. What situation are you thinking of where an accidentally unset, malloc()ed structure would cause a core dump upon access that would not be duplicated had calloc() been used? > But in no way were the authors of calloc() being "ridiculous" in their > implementation. I never claimed this. calloc() is a wonderful tool. It just should not be used exclusively instead of malloc(), which is what the professor claimed. -Micah _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
