mirror of
https://github.com/ultimatepp/ultimatepp.git
synced 2026-05-17 06:06:00 -06:00
65 lines
No EOL
3.9 KiB
C++
65 lines
No EOL
3.9 KiB
C++
topic "Design decisions and tradeoffs";
|
|
[2 $$0,0#00000000000000000000000000000000:Default]
|
|
[l288;i704;a17;O9;~~~.992;2 $$1,0#10431211400427159095818037425705:param]
|
|
[a83;*R6 $$2,5#31310162474203024125188417583966:caption]
|
|
[b83;*2 $$3,5#07864147445237544204411237157677:title]
|
|
[i288;b167;a42;O9;C2 $$4,6#40027414424643823182269349404212:item]
|
|
[b42;a42;2 $$5,5#45413000475342174754091244180557:text]
|
|
[l288;a17;2 $$6,6#27521748481378242620020725143825:desc]
|
|
[l321;t246;C@5;1 $$7,7#20902679421464641399138805415013:code]
|
|
[b2503;2 $$8,0#65142375456100023862071332075487:separator]
|
|
[*@(0.0.255)2 $$9,0#83433469410354161042741608181528:base]
|
|
[t4167;C2 $$10,0#37138531426314131251341829483380:class]
|
|
[l288;a17;*1 $$11,11#70004532496200323422659154056402:requirement]
|
|
[i417;b42;a42;O9;~~~.416;2 $$12,12#10566046415157235020018451313112:tparam]
|
|
[b167;C2 $$13,13#92430459443460461911108080531343:item1]
|
|
[i288;a42;O9;C2 $$14,14#77422149456609303542238260500223:item2]
|
|
[*@2$(0.128.128)2 $$15,15#34511555403152284025741354420178:NewsDate]
|
|
[l321;*C$7;2 $$16,16#03451589433145915344929335295360:result]
|
|
[l321;b83;a83;*C$7;2 $$17,17#07531550463529505371228428965313:result`-line]
|
|
[l160;t4167;*C+117 $$18,5#88603949442205825958800053222425:package`-title]
|
|
[{_}%EN-US
|
|
[s2; Design decisions and trade`-offs&]
|
|
[s0;i150;b33;O0; 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.&]
|
|
[s0;i150;b33;O0; 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.&]
|
|
[s0;i150;b33;O0; CPU and compiler are supposed to support [^topic`:`/`/Core`/srcdoc`/Moveable`$en`-us^ M
|
|
oveable] (true for any gcc platform and MSVC`+`+ as well).&]
|
|
[s0;i150;b33;O0; 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.&]
|
|
[s0;i150;b33;O0;%- [%% Maximum number of elements in any of U`+`+ containers
|
|
(including GUI elements, like number of rows in DropList) is
|
|
2][%%` 31 ][%% `- 1 `= ]2,147,483,647.&]
|
|
[s0;i150;b33;O0; GUI is designed in a way that all user events are
|
|
passed and processed 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, however U`+`+ workarounds
|
|
this by invoking such operations as `"call to main thread`".
|
|
In other words, you can do anything in non`-main threads as long
|
|
as you do not forget to synchronize using global GUI mutex.&]
|
|
[s0;i150;b33;O0; 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.&]
|
|
[s0; ] |