JUCE as DLL


#1

Hi,
This is in reference to my previous post here:
http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=849&highlight=juce*dll

I was wondering if juce could be used as a dll?
Has jules fixed the problem?

Regards,
Yogi


#2

Well you can build it as a DLL but there’s a problem at the moment with destructors - if a juce object in the DLL creates an array, for example, and passes it to the app, then when the array is resized, the wrong allocator is used, and it blows up.

Not sure exactly how to sort this out - I think it’d need a virtual allocator object to be added to every juce class, with custom new and delete operators. Very messy…

Why are you keen to use it as a DLL, though? Why not statically link it?


#3

In my project I got three modules, say M1, M2 and M3. All these rely on Juce-lib for rasterisation operations(basically drawing and filling bezier’s).
Ideall I would like all, M1,M2 and M3 to go as dll’s to my users coz, sending a update is just sending a new dll.
Now if I include juce as a static lib, when building M1 or M2…, it causes the same problem you mentioned above. To prevent this, I end up compiling all M1,M2 and M3 as static lib and entire app is a huge one.
Also if I write a optional module m4,that I want to send it to a privileged user, I cannot do it , unless I have it as a dll.

I hope you undersatnd my problem, and write a fix for the problem.

Many thanks,
Yogi


#4

I understand. I’ll take a look at this soon, as it does need fixing.


#5

[quote=“jules”]Well you can build it as a DLL but there’s a problem at the moment with destructors - if a juce object in the DLL creates an array, for example, and passes it to the app, then when the array is resized, the wrong allocator is used, and it blows up.

Not sure exactly how to sort this out - I think it’d need a virtual allocator object to be added to every juce class, with custom new and delete operators. Very messy…

Why are you keen to use it as a DLL, though? Why not statically link it?[/quote]

The boost pattern has allocators inside such classes, hidden in a detail namespace. It then uses those to (de)allocate everything from the dll side. Basically, using boost, you never allocate anything on the heap, everything is lightweight containers designed for the stack and it handles all memory internally. That is also the reason boost is fast in execution, but rather slow when compiling.


#6

OvermindDL1, can you be more specific about this (what classes, how does it work, etc… ) ?

Jules, you can add a #ifdef JuceExport #define new JuceNew etc… #undef new to juce.h so you would be able to use your own allocator and deallocator.

By the way, you can even use a pointer to a function for JuceNew/JuceDelete so the user can set it with the right allocator…


#7

Actually, I’ve sorted this out now, in a much simpler way. What I’ve done is to add some juce_Malloc() and juce_Free() functions, which just wrap the normal malloc() functions. But these are exports from the juce dll, so all allocations from any module call the same function instance, and everything works just fine.

Might have a new release today…


#8

Thanks a Lot Jules :smiley:
Waiting for the release.

JUCE Rocks :smiley:

Regards,
Yogi


#9

Actually the normal C++ stl uses internal (de)allocators as well. Basically what Jules did.


#10