On Feb 7, 2014, at 12:28 PM, Tom Browder wrote: > Among other things, the literals, whether global or not, > need to be defined somewhere, and, IMHO, shouldn't be duplicated. I > can certainly rename them in accordance with convention.
Absolutely. Rule of Three is good (minimal), DRY is even better (none). If they span files, a private header file can be added (which consequently resolves their names being inconsistent, don't need to be as private symbols). > No argument there! Ideas welcome!. But I'm actually moving toward a > consolidation of such conversions into a more general function--maybe > the name would be too complicated now. It seems most of them can fit > into two or three classes instead of so many individual ones that are > variations on a theme. Fewer would be better! Might want to look at convert.c (the bu_cv_*() functions) and/or the 'cv' utility to make sure you don't expand into an area already covered. I'm not suggesting your extend it, but it deals with binary data conversion which is obviously related. The 'cv' routines provide buffer conversions to other size and types of buffers and it's highly generalized. In terms of generality, I think it'd help to find a purpose that this can use this before going too far. I've been working on contracting our libraries to help reduce our completely. This started with counting the number of places each function is used. Functions that have very few uses are on the list for removal consideration. Those with no uses are hard to justify keeping long-term. > Hm, I didn't realize a stack bu_vls would be so much better since the > guts use malloc. Another benefit is causing no allocations if it's never written to (in which case the free() does nothing too), like when an error condition is encountered. If it's a routine called LOTS of times, it will cut the malloc calls in half too. Cheers! Sean ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
