Alexandre Lision | ddd731e | 2014-01-31 11:50:08 -0500 | [diff] [blame] | 1 | GNU uCommon C++ is meant as a very light-weight C++ library to facilitate using |
| 2 | C++ design patterns even for very deeply embedded applications, such as for |
| 3 | systems using uclibc along with posix threading support. For this reason, |
| 4 | uCommon disables language features that consume memory or introduce runtime |
| 5 | overhead, such as rtti and exception handling, and assumes one will mostly be |
| 6 | linking applications with other pure C based libraries rather than using the |
| 7 | overhead of the standard C++ library and other class frameworks. |
| 8 | |
| 9 | GNU uCommon C++ by default does build with support for the bloated ansi |
| 10 | standard c++ library unless this is changed at configure time with the |
| 11 | --disable-stdcpp option. This is to assure maximum portability and will be |
| 12 | used to merge UCommon with GNU Common C++ to form GNU Common C++ 2.0. Some |
| 13 | specific features are tested for when stdc++ is enabled, and these will be used |
| 14 | to add back in GNU Common C++ classes such as TCP Stream and serialization. |
| 15 | |
| 16 | GNU uCommon C++ introduces some Objective-C based design patterns, such as |
| 17 | reference counted objects, memory pools, smart pointers, and offers dynamic |
| 18 | typing through very light use of inline templates for pure type translation |
| 19 | that are then tied to concrete base classes to avoid template instantiation |
| 20 | issues. C++ auto-variable automation is also used to enable referenced objects |
| 21 | to be deleted and threading locks to be released that are acquired |
| 22 | automatically when methods return rather than requiring one to explicitly code |
| 23 | for these things. |
| 24 | |
| 25 | GNU uCommon C++ depends on and when necessary will introduce some portable C |
| 26 | replacement functions, especially for sockets, such as adding getaddrinfo for |
| 27 | platforms which do not have it, or when threadsafe versions of existing C |
| 28 | library functions are needed. Basic socket support for connecting to named |
| 29 | destinations and multicast addresses, and binding to interfaces with IPV4 and |
| 30 | IPV6 addresses is directly supported. Support for high resolution timing and |
| 31 | Posix realtime clocks are also used when available. |
| 32 | |
| 33 | While GNU uCommon C++ has been influenced by GNU Common C++, it introduces some |
| 34 | new concepts for handling of thread locking and synchronization. GNU uCommon |
| 35 | C++ also builds all higher level thread synchronization objects directly from |
| 36 | conditionals. Hence, on platforms which for example do not have rwlocks, |
| 37 | barriers, or semaphores, these are still found in uCommon. A common and |
| 38 | consistent call methodology is used for all locks, whether mutex, rw, or |
| 39 | semaphore, based on whether used for exclusive or "shared" locking. |
| 40 | |
| 41 | GNU uCommon C++ requires some knowledge of compiler switches and options to |
| 42 | disable language features, the C++ runtime and stdlibs, and associated C++ |
| 43 | headers. The current version supports compiling with GCC, which is commonly |
| 44 | found on GNU/Linux, OS/X, BSD based systems, and many other platforms; and |
| 45 | the Sun Workshop compiler, which is offered as an example how to adapt UCommon |
| 46 | for additional compilers. GNU uCommon C++ may also be built with GCC cross |
| 47 | compiling for mingw32 to build Microsoft Windows targets natively. The cmake |
| 48 | build system can also be used, to create project files for various platforms |
| 49 | including xcode for OS/X and various Microsoft Visual Studio project file |
| 50 | formats. |
| 51 | |
| 52 | The minimum platform support for uCommon is a modern and working posix pthread |
| 53 | threading library. I use a subset of posix threads to assure wider portability |
| 54 | by avoiding more specialized features like process shared synchronization |
| 55 | objects, pthread rwlocks and pthread semaphores, as these are not implemented |
| 56 | on all platforms that I have found. I also eliminate the practice and |
| 57 | dependency on pthread automatic cancellation behavior, which otherwise |
| 58 | introduces much greater complexity to user applications and can often lead to |
| 59 | defective coding practices. |
| 60 | |
| 61 | The first three releases of uCommon were introduced in 1999-2000 as a pure "C" |
| 62 | library for embedded targets, and had not seen an update in 7 years. Hence I |
| 63 | have had the package name in use for a very long time. Work on what became |
| 64 | uCommon C++ 0.4 was originally intended as a refactoring effort for GNU Common |
| 65 | C++ to better support IPV6, and became something different as entirely new code |
| 66 | was written in 2006. I originally hoped to release GNU uCommon C++ in March of |
| 67 | 2007 as a new package under the GNU GPL V3, but the license was unavoidably |
| 68 | delayed. GNU uCommon C++ will merge code from and replace GNU Common C++ in |
| 69 | future releases. |
| 70 | |
| 71 | GNU uCommon C++ is a linkable library distributed under the GNU General Public |
| 72 | License, Version 3 or later. As of version 2.0, we are now using the GNU |
| 73 | Lesser General Public License, Version 3 or later, to remain consistent and |
| 74 | compatible with past GNU Common C++ licensing. A new release series of GNU |
| 75 | uCommon C++ is 2.1 involved refactoring the abi release from prior 2.0.x |
| 76 | releases, offering greater clarity, consistency of use, and some new features |
| 77 | that were migrated from Common C++. |
| 78 | |
| 79 | To better focus on standardizing secure and runtime services, uCommon was |
| 80 | somewhat simplified in release 3.4. ccscript is now part of GNU Bayonne, |
| 81 | and ccaudio has been separated again. |
| 82 | |