Status & Roadmap
Authors & License
Funding U++
Search on this site

SourceForge.net Logo

SourceForge.net Logo

GitHub Logo

Discord Logo

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 (and run) 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, clang 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. Related issue - default and copy constructors are not allowed to throw exceptions in U++ (the common reason to throw exception here is out-of-memory condition).

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 designed in a way that all user events are passed and processed by the main thread. The synchronization is done using single global mutex (operated by EnterGuiMutex, LeaveGuiMutex or GuiLock scoped helper). Other threads can directly work with GUI as long they do use this global mutex. There are some operations (like opening/closing windows, message loops) that cannot be performed by any other thread than main.

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.


Do you want to contribute?