Here is a couple of software packages I've written in C++ and make avaliable to others in case they would like to use it, or similar. Please note that they are all licenced under the GNU LGPL Some of these packages was featured in Brave GNU World issue # 47. Unfortunately, there's no mailing list or similar set up for these packages, nor is there any CVS access. I could opt to have Savannah or SourceForge host the projects, but as I do not have readily available access to these sites from my primary development machine, I chose this rather archaic form. Sorry about that.
All packages uses Autotools (Automake, Autoconf, and possibly Libtool), so all you need to do to build them, is to do the regular ./configure make make install cycle. The documentation is automatically generated using Doxygen. Reporting bugs: When reporting bugs on any of these packages, please follow normal GNU bug-reporting procedures:
Note, that items 1-3 is taken care of by attaching the config.log of your build. In fact, I prefer that you send that file, rather than giving me the information separately, as that file contains more or less all the information I could ask for. As for item 4, that is only relevant if you modified any of the packages in any way. To make a patch, rename the directory of the modified sources, unpack the upstream tar-ball next to that directory, and run diff: mv <name>-<version> <name>-<version>-new gzip -dc <name>-<version>.tar.gz | tar -xf - diff -u -r <name>-<version> \ <name>-<version>-new \ > <name>-<version>.patch Item 5 means that you may have to preprocess some source files, if you're using non-standard headers or similar. Any bug report that does not follow these guidelines will be considered, but it'll speed up the process if you follow these guidelines. Thank you for your help. For developers only: The packages uses fairly recent versions of the Autotools, so if you need to change something in the build system, you need that too. This does not effect for people who only wants to install the packages. All of the packages supports building Debian packages directly. Just unpack the tar-ball, cd to the directory and type debuild. I'll add RPM support sometime in the future too. |
News
|
|||||||||||||||||||||||||||||||
Readline-- 2.0.9C++ wrappers around GNU readline. The C library readline is a library for making interactive command line applications, like shells, interpretors, and so on. However, the API of readline is very C-centric, so Readline-- provides C++ wrappers to make the C++ programmer more comfortable. |
||||||||||||||||||||||||||||||||
Yacc/Lex-- 2.7C++ wrappers around GNU Bison and Flex, and to some extend, classical Yacc and Lex as well as Berkeley Yacc (a.k.a. byacc). Yacc and Lex are the traditional UNIXTM tools for creating syntactic parser and lexical analysers respectively. They output C functions that often defines a state machine. These C functions a cumbersome to the C++ programmer, so Yacc/Lex-- provides a set of header files to nicely wrap up the Yacc/Lex generated functions. You can use Yacc/Lex-- with both Yacc and Lex, or with only Yacc or Lex. For an example usage, see the MyCC project on this page. Here's an overview of the C++ grammar as presented in the ISO/IEC C++ Standard, Annex A. Note, that it contains a lot of shift/reduce and and reduce/reduce conflicts. Oh, and it's not Yacc-able, I'm afraid. |
||||||||||||||||||||||||||||||||
Yacc/Lex/Readline/Option-- 0.5This example shows how to combine Yacc/Lex-- and Readline-- into a CLI based toy calculator with advanced features like user functions, commandline editing and history. Note: It uses Yacc/Lex--, Readline--, and Option-- so you need to install those packages first. Using the Libtool-- this example could be expanded to provide dynamic loading of functions. However, that's left as an exercise to the interested reader :-) |
||||||||||||||||||||||||||||||||
Option-- 2.2Class library to help parse command line options. Using templates, this library provides support for all sorts of command line arguments. The library supports the grand UNIXTM tradition of the long (--<option>=<arg>) and short (-<c> <arg>) format for command line options. Options can have multiple values, and their position on the command line is tracked. Any un-handled options are passed on to the user. |
||||||||||||||||||||||||||||||||
FILE-- 0.5Class library to wrap C FILE in a std::streambuf layer. A lot of C libraries assumes that file I/O operations go via a pointer to a C FILE object. However, the ISO/IEC C++ Standard does not deal with FILE save for a few remarks, so these headers wraps the C type FILE in a streambuf layer. streambuf can sound frightening to you, but once you get the hang of it, it is quite a neat thing. I'd venture to say, that after you've seen what you can do with streambuf, you'd agree with me that it's the coolest thing in C++, 2nd only to Andrei Alexandrescu's tricks in Modern C++ Design . |
||||||||||||||||||||||||||||||||
Thread-- 0.13C++ wrappers around threads. The class library is implemented entirely inline (in headers), so that it's easier to integrate into other projects. This class library takes a an approach based on traits - that is, the actual interface to the underlying thread library (POSIX threads, C Threads, and some day Win32 threads) is done via traits of the client classes. This makes the seperation of interface and implementation much nicer, without the overhead of virtual member functions, large numbers of #if's and so on. It also makes it much easier for client code to plugin their own backend. Also, there's no reason why on any platform, one may have multiple implmentations - for example realtime and normal threads on Solaris, POSIX and native threads on Win32, GNU PTH and POSIX threads on Un*x, C and POSIX(?) threads on GNU Mach, and so on. This approach is very different from some of the other C++ thread libraries avaliable out there - for example: The Boost thread classes uses loads of #if's, GNU Common C++ threads rely on inheritance, ThreadJack has interfaces in terms of functions, and ZThread uses adapter classes and #if's. You will not get me to say which is best, my solution or the above - I leave that for you to decide - the links are there, try them if you like. |
||||||||||||||||||||||||||||||||
Libtool-- 1.5Class library to load dynamically loadable (or shared) libraries, via Libtool's libltdl library. Extending an application dynamically (that is, at run-time) is quite a useful feature (think of `plugins' to your favourite web-browser), and requires loading compiled code. The GNU C library libltdl provides this feature for all platforms in a unified way. However, it is still a C library, and not very C++'ish. Hence, this library wraps libltdl in a small set of classes. Take a look at the factory example which I think is kinda cool. |
||||||||||||||||||||||||||||||||
std::cache 1.0Template container that caches memory to reduce the number of new and deletes. |
||||||||||||||||||||||||||||||||
MyCC 0.2ISO C parser and Abstract Syntax Tree (AST) generator. This uses Yacc/Lex--. It creates a representation of the AST which is visitable by the Visitor design pattern. One visitor is shown: a visitor to print the AST. Clients are invited to define new visitors to do more complex things, like resolving references in the AST, creating binary code ,and so on. |
||||||||||||||||||||||||||||||||
GSL-- 0.12C++ wrappers around GNU Scientific Library (GSL). Note that the library is not complete (see the TODO list). However, it shows one way to go when implementing GSL wrappers in C++. It makes heavy use of templates and template specialisation. |
Home Christian Holm Christensen |