WebSitesOfNote

Modifying library code: "One of the joys of developing software these days is being able to build on top of high-quality libraries. Finding just the right package to solve one of your problems can remove a huge burden from your development shoulders. Unfortunately, sometimes you experience the disappointment of realizing your beloved library has a flaw. A bug, a missing function, whatever. Then you have to try to fix it. If you don't have the source, forget it, you have to work around it. But if you do have the source, do yourself a favor: before modifying the code, put in some protection to make sure your product really is using the modified source. The problem with modifying library code is that you shift from using the library as shipped to using your modified version, and subtle changes is build or deploy environments can switch you between the two without even knowing it. For example, modified include files have to be found in a product tree before searching the standard include directories. So the first modification to the library should be to mark it as your modified version, and your product code should assert that it is using the modified library. For example, in C++, in one of the headers, add a macro definition: // ReportGeneratorLib.h header file#define INITECH_REPORTGEN_LIB 1//.. blah blah rest of the header .. Then in your code where yo"