[Bayonne-devel] GNU Telephony Dispatch #2, UCommon 0.4 released today

[David Sugar]

UCommon 0.4.0 was released this afternoon as a new package licensed
using the GNU GPLv3.  While we are re-using the ucommon name, this
release not directly related to any prior releases.  It is available for
download at http://dist.gnutelephony.org/tarballs/ucommon-0.4.0.tar.gz.

UCommon is meant as a very light-weight C++ library to facilitate using
C++ design patterns even for very deeply embedded applications, such as
for systems using uclibc along with posix threading support.  For this
reason, UCommon disables language features that consume memory or
introduce runtime overhead, such as rtti and exception handling, and
assumes one will mostly be linking applications with other pure C based
libraries rather than using the overhead of the standard C++ library and
other similar class frameworks.

UCommon introduces some Objective-C based design patterns, such as
reference counted objects, memory pools, smart pointers, and offers
dynamic typing through very light use of inline templates for pure type
translation that are then tied to concrete base classes to avoid
template instantiation issues.  C++ auto-variable automation is also
used to enable referenced objects to be deleted and threading locks to
be released that are acquired automatically when methods return rather
than requiring one to explicitly code for these things.

UCommon depends on and when necessary will introduce some portable C
replacement functions, especially for sockets, such as adding
getaddrinfo for platforms which do not have it, or when threadsafe
versions of existing C library functions are needed.  Basic socket
support for connecting to named destinations and multicast addresses,
and binding to interfaces with IPV4 and IPV6 addresses is directly
supported.  Support for high resolution timing and Posix realtime clocks
are also used when available.

While UCommon has been influenced by GNU Common C++, it introduces some
new concepts for handling of thread locking and synchronization.
UCommon also builds all higher level thread synchronization objects
directly from conditionals.  Hence, on platforms which for example do
not have rwlocks, barriers, or semaphores, these are still found in
UCommon.  A common and consistent call methodology is used for all
locks, whether mutex, rw, or semaphore, based on whether used for
exclusive or "shared" locking.

UCommon requires some knowledge of compiler switches and options to
disable language features, the C++ runtime and stdlibs, and associated
C++ headers. The current version supports compiling with GCC, which is
commonly found on GNU/Linux, OS/X, BSD based systems, and many other
platforms; and the Sun Workshop compiler, which is offered as an example
how to adapt UCommon for additional compilers. UCommon may also be built
with GCC cross compiling for mingw32 for Microsoft Windows targets using
the Redhat w32 pthread library.

The minimum platform support for UCommon is a modern and working posix
pthread threading library.  UCommon does not support other non-posix
threading models such as Microsoft Windows threads or non-preemtive
threading libraries like GNU pth, so that we could optimize development
efforts around Posix pthread exclusively.  I further use a subset of
posix threads to assure wider portability by avoiding more specialized
features like process shared synchronization objects, pthread rwlocks
and pthread semaphores, as these are not implemented on all platforms
that I have found.

The first three releases of UCommon were introduced in 1999-2000 as a
pure "C" library for embedded targets, and had not seen an update in 7
years.  Hence I have had the package name in use for a very long time.
Work on what became UCommon 0.4 was originally intended as a refactoring
effort for GNU Common C++ to better support IPV6, and became something
different as entirely new code was written in 2006.  I originally hoped
to release UCommon in March of 2007 as a new package under the GNU GPL
V3, but the license was unavoidably delayed.  I may use UCommon to offer
guidelines and code for further improving GNU Common C++ releases, I may
merge the two packages, or I may make GNU Common C++ an extension
library for UCommon. This has not been decided yet.