[Qt-interest] Qt library in (non)Qt application

[Marco Borm]

Tumarov Alexander wrote:
> Marco Borm wrote:
>
>
>   
>> Also under Windows there is no real problem sharing objects between app
>> and dlls if you do it the right way:
>> 1. Components sharing objects on the head must use the same heap-manager
>> Typically this means using the same crt in all components and use them
>> as a dll/so.
>> 2. If you share objects using a base class / interface pointer don't
>> miss the virtual deconstructor if the receiver should delete the object.
>>     
> Hm... this is the point - I am not sure if the same CRT will solve this
> issue. Can you drop a link that can shed a light on this topic more deeply?
> I remember that I have some hard time of exporting stl objects out from
> dlls... virtual destructor did not solved that. May be the issue was a
> different CRTs... but anyway - I wanna be sure on this topic. At this point
> it bother me more then existance of QApplication since that can be defined
> as requirement (on this later).
>   
>> I think the bigger problem here is that you don't know if the app will
>> construct a QApplication or not.
>>     
>
> This is a second issue. Can QApplication be instantiated inside library?
> Will dll's objects work correctly with QApplication installed in application
> itself (like queued connections or event's handling)?
>
>
> Thank you in advance.
>
> p.s.: To be honest - the issues with right memory handling bothers me a lot.
> The possibility of existance of several heap managers can become a real
> headache if new/delete used across library boundaries (and if "recommended"
> way is used  - what created in library should be deleted in library
> itself). Virtual destructors will not solve this since the final
> memory "free" will operate on heap manager that used in the execution unit
> of "delete" call (app/dll). 
You're right and thats why I don't wrote "1." OR "2.". The virtual 
destructor hint wasn't more than a hint. Its a typical c++ pitfall, but 
of course there are more.

> I beleive that what you say is that the
> difference in the way I link CRT. If it is going to be static linkage - I
> will have the problem. If dynamic on both the app and dll - all of them
> will get the only one CRT with only 1 heap manager and then there will be
> no problem. Am I right or wrong?
>   
You're right.
You have simply take sure that you always use the same heap manager 
instance for a new/delete-pair.
If you use different crt-dlls in your application, you get multiple 
instances. If parts are linked statically to a crt, they also get there 
personal heap manager instance.

> BTW - good question  - is there any issues like this on linux/mac os?
> Additional issues may arize if QT uses static variables inside their
> libraries (if something inlined  - application and dll can get different
> copies of the same variable).
>
>
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
>