Design decisions and trade-offs

At the moment, we strongly favor static linking of U++ packages. If nothing else, it makes U++ apps self-contained (together with system of .lay and .iml files) and also much faster to load in Linux (just compare start times of UWord with some KDE based word-processor). Shared builds were implemented mainly to improve build times in debug mode.

CPU has to be either little-endian or big-endian (exotic architectures are not supported), in flat 32-bit mode or in 64-bit mode with sizeof(int) >= 4 (that is quite standard). Currently tested CPU architectures are i386, AMD64, ARM and PowerPC.

CPU and compiler are supposed to support Moveable (true for any gcc platform and MSVC++ as well).

We decided to ignore possibility of "out-of-memory" exceptions and recovery. If U++ application goes out of memory, it simply prints the error message and terminates. This is quite pragmatic resolution - our experience is that it is quite hard and annoying to achieve robustness here and it cannot be reliably tested. Also, most platforms with virtual memory will almost freeze long before out-of-memory problem due to intensive page swapping. Connected issue - default and copy constructors are not allowed to throw exceptions in U++ (the common reason to throw exception here was out-of-memory condition). This limitation will be removed in future releases.

Maximum number of elements in any of U++ containers (including GUI elements, like number of rows in DropList) is 231 - 1 = 2,147,483,647.

GUI is single threaded. That does not mean you cannot do multi-threaded GUI apps - just use only one thread to perform GUI and communicate with others via timer queue (We guess this method is far safer anyway).

U++ does not use OS-native widgets. The main reason for this is to achieve widget interface model optimal for rapid development. The less important reason is that this way it is much easier to make U++ cross-platform. On the other hand, Chameleon skinning system achieves native look&feel, so there is a little perceivable difference for end user.