OK, maybe it's a goofy name, but I had to use SOMEthing, and "CampyCode" seemed as good as anything else.
The idea behind CampyCode is to provide a series C++ libraries that can be used as infrastructure for most any project. These libraries are to be provided as source code, allowing the client to customize them to their own specific needs. Payment is based on the amount of time and effort spent in developing the library in question. The only limitation is that the source code in its original form or any derivation may not be transeferred to any other party. Of course, we could always work out some kind of resale agreement. The idea is to approximate what would happen if I were to work directly for the client to produce these libraries - you'd pay me for my time, and you'd get the source code. The resale limitation is simply to protect my ownership rights. The benefit, though, is that you get the code NOW, and that you're getting code that's been around the block a couple of times.
The first library being worked on is C++ smart pointers. I feel that a major shortcoming of C++ is that the pointer type conveys no concept of semantics. That is, if a pointer is passed to a routine, there is no way to tell from the data type itself (Object*) whether the intention is to pass ownership of the object to the called routine or whether the pointer is being passed for temporary usage. True, the intended usage should be commented, but we all know software developers who feel that thorough documentation is beneath them. (In fact, I recently worked for a company that felt that usage documentation should be with the method implementations, rather than in the header files(!). But I digress...) Smart pointers are template classes that specifically convey the intended usage of a pointer, as well as providing for some safety in using those pointers. For example, an "owning" pointer will automatically delete the object it points to if the pointer is deleted, whereas a "temporary" pointer will not. Another pointer type is strictly used for passing ownership to a called routine. And still another facilitates shared ownership, where any number of pointers to an object may exist, and the object is only deleted when all shared pointers to the object are cleared or deleted. Smart pointers are used throughout CampyCode, but the libraries' public interfaces will be easily modifyable so that the client is not required to use them. But I'd strongly recommend their use. Quite frankly, these type of smart pointers ROCK!
Next on my list will be the error handling infrastucture that all other CampyCode libraries will use. Error handling can be extremely tricky, in that some prefer to use return values of methods for errors, while others prefer to use exception handling. While I had been considering the use of macros for error handling, allowing the end user to make the choice between return values and exceptions, I've rethought this strategy. I've had a bit of recent experience with exception handling, and I don't care for it at all. It bloats and slows code, makes code even more convoluted to read (with all of the "try-catch" blocks - yuck!), and excuses the developer from considering what needs to happen if an error occurs during a function call. I've elected instead to handle all errors as return codes. Any really robust code I've been involved with has been written this way. Furthermore, writing code that uses return codes is compatibile with code that uses exception handling,which the reverse is not true. In the vein of error handling, I will use some macros for ASSERT code. Macros are needed in order to accurately report the file and line numbers that trigger ASSERTs. I have found ASSERT code most useful in the development process when used to identify code misuse, unexpected environmental problems, and just plain invalid conditions that should never exist. The nice thing about macros in these cases is that ASSERTs can be easily compiled out of code.
This will be followed by an event logging library. This library will allow for runtime messages to be stored to a file, possibly a file of limited size, for later retrieval. Events will be coded with keys that will allow for selective output of events at runtime. In a multi-threaded environment, event logging should minimally impact process timing, although some impact is impossible to avoid. Also, with the interprocess communications library, a program will be provided that will allow for runtime modification of the events being tracked.
The next library will be for threading. It will include a base class that will be useful in creating new threaded objects and controlling them. It will also include locking primatives that will focus on intraprocess locks, interprocess locks, and eventually intersystem locks (requiring another library - interprocess communications).
This will be followed by a memory management library (requiring the threading library to be thread-safe). This library will include debug switches that will allow for common checks for memory misuse, such as overrunning buffers. Further, deleted memory will be cleared with a predetermined value so that ongoing usage of deleted memory can be more easily identified.
And lastly (so far), I will create an interprocess communications library that will provide for a common model of communications regardless of the underlying transport mechanism (where reasonable and possible). Initially, communications will be TCP/IP, UDP, and serial.
I do have a couple of white papers that are "works in progress". The non-linked entries here have not yet been written. These papers will appear as I work on the various libraries.