I think your library is fantastic! I really hate boost and stl because of their syntax and calling conventions. I've always wanted something with the same feel as the .NET libraries and yours is exactly that. Great job!
Yes, I don't mean to start a Boost vs. Commonc++ argument. I just think it would be great if the author could share some of his opinions on why he reimplemented some of these constructs, and any areas where he thinks his approach is better than that taken by Boost. This would help others in choosing which to use.
Well, as others have pointed out, boost is a rat's nest of templates and cryptic symbols. The boost libraries are modeled after STL which itself has, in my opinion, an ugly API. I modeled commonc++ after Qt and the Java core APIs, which I've used extensively and which I believe are much more intuitive, more "elegant" (aesthetically, if not functionally) and much easier to wrap one's head around than boost.
commonc++ was designed to be a reasonably complete and self-contained wrapper around non-portable operating system APIs. It is meant to serve the same role for C++ programs as APR (the Apache Portable Runtime) does for C programs: it hides the messiness (particularly on Windows) of said system APIs, making it possible to write complex systems software that will run on all of the supported platforms without changes to the code.
There is indeed overlap in functionality but I think in general commonc++ provides portable access to a wider range of OS functionality than the equivalent boost libraries. For example how do you set a thread's scheduling priority or create a detached thread with Boost.Thread? And of course there is a whole lot of systems-level functionality in commonc++ for which there is no equivalent in boost.
I think both commonc++ and boost have their place. I wrote commonc++ because I'd looked at Boost (and other similar libraries) and none of them really suited my needs. It was open sourced with the hope that others might also find it useful.
