Hi jules,
Can we expect a fix for this problem in near future or you
recommend linking using static lib?
Regards,
Yogesh
[quote=“kini1982”]Hi jules,
Can we expect a fix for this problem in near future or you
recommend linking using static lib?
Regards,
Yogesh[/quote]
Static linking is faster, easier to install, can’t be messed up by the user moving a dll, can’t get into version problems or pick up the wrong dll by mistake, produces smaller code, is harder to hack, etc etc. Dynamic linking is something I’d only ever resort to if there’s absolutely no choice.
I do understand about the allocator problem, but the thing that puts me off is the idea that every object would need a pointer to its allocator. I’m having a think about it though…
Was this ever resolved? The reason I ask is that Juce looks very promising to me as I need a cross platfrom GUI environment (to replace MFC), but I have to use other dll’s (ACE being one), so I need to use Juce as a dll. Is this possible yet?
Why do you need to use Juce as a DLL to make use of other DLLs? Statically linking Juce with your program doesn’t prevent other libraries from being dynamically linked. Unless i’m getting something seriously wrong.
DLLs suck!
More bloody trouble than they’re worth!!
Just tried converting a static lib to a hell and what a shambles of grief! Project abandoned!!!
Yes, this was sorted out a while ago, I think.
Having said that, DLLs do suck, and should always be a last resort.
DLL’s are quite necessary in many circumstances (maybe not with Juce though) that I deal with, the main one is syncronizing singleton’s across diferent instances…
Across instances of what? It certainly won’t help you share singletons across processes, and within a process, sharing singletons is easy… ??
I meant between other dll’s. I’ve noticed you either need to have everything static, or most things dynamic…