Home » Developing U++ » U++ Developers corner » SO for Draw, Esc and other packages
|
|
| Re: SO for Draw, Esc and other packages [message #5176 is a reply to message #5173] |
Sat, 09 September 2006 15:55   |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| Shire wrote on Sat, 09 September 2006 08:09 |
Does standard libraries allow dynamic module design (dll on Windows)?
Many classes have exports inline methods with access to private and protected members. Linking with these classes causes error.
|
It does, or better said, it did... I am afraid this was not checked for quite a long time. But I remember that once it worked 
Anyway, AFAIK, inline methods should not (did not) cause problems.
| Quote: |
Draw package depends on plugins/bmp, but plugins/{bmp,jpg,png,tiff} depends on Draw by objects StreamRaster and StreamRasterEncoder.
Is possible to join plugins/bmp and Draw?
|
Well, more things to solve...
| Quote: |
IMHO, dll design will be good for solutions with many executables to prevent overhead in common code.
|
Yes, but... also introduces .dll hell and often slows down startup times. So far, easy maintainace of apps was major design criteria.
I am maintaining more than 20 U++/Oracle apps for my main customer, which already could be classified as "many executables". Anyway, they occupy about 70MB of hard disc space. You can find many ".dll modularised" apps that occupy significantly more. The idea that changeing single .dll would break more than single app would be a nightmare.
Actually, if you plan to develop some desktop environment based on U++ (a good idea , which IMO is the only place where dynamic libraries make sense, I would rather tried another approach to the problem - "join" all applets into single binary and make small "invokers" to call it. BTW, afaik, this is what trolltech is using for Qtopia...
OK, enough ranting (as you see, I really despise .dlls ), I am adding to ToDo that we should reestablish SO compilation.
Mirek
[Updated on: Sat, 09 September 2006 15:56] Report message to a moderator |
|
|
|
| Re: SO for Draw, Esc and other packages [message #5180 is a reply to message #5173] |
Sat, 09 September 2006 16:58 |
Shire
Messages: 41
Registered: September 2006
Location: Russia, Yamal peninsula
|
Member |
|
|
| Quote: |
Anyway, AFAIK, inline methods should not (did not) cause problems.
|
These methods inlines in calling module and tries to access private members from other module. Static linking hides this problem.
| Quote: |
Yes, but... also introduces .dll hell and often slows down startup times. So far, easy maintainace of apps was major design criteria.
|
dll hell appears when libraries became system-wide and shared between many untrusted vendors (like System32 directory on Windows). Local dll per version with correct name does not make hell.
First startup time increases, but following start of other executable, which uses common dll, will be much faster - dll will be in cache.
| Quote: |
The idea that changeing single .dll would break more than single app would be a nightmare.
|
Well, don't change dll  Make only bugfix, binary compatible with previous, and you never see nightmares.  Significant changes must increase version number and change dll name.
| Quote: |
as you see, I really despise .dlls
|
When develop environment with dynamic/plugin architecture, is important to share common environment between all parts. Dll (or .exe exports) is good solution in this case.
Thank you for answer.
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sun May 05 22:09:11 CEST 2024
Total time taken to generate the page: 0.01820 seconds
|
Members
Pages
Help
Register
Login
Home
). I'm worry about situation when modules begin to exchange common objects and each module have another version of common library...
