Re: [IBPP-DISCUSS] IBPP compiled inside a DLL on Win32

[Luca C. <luc...@se...>]

Hello,

On Fri, 14 Nov 2008 15:17:30 +0100, Olivier Mascia <om...@ti...> wrote:

> Le 14-nov.-08 à 13:32, Michael Hieke a écrit :
>
>> I'm not sure making IBPP into a COM DLL is the way to go.
>>
>> * Interfaces must not change.  Every change in the signature of a
>> method
>> or the removal of a method means that a new interface with its own
>> GUID
>> has to be created.  Much work for little gain.
>>
>> * What about the exceptions?  Catch them, turn them into COM result
>> codes, then throw them again in the IBPP layer around the COM object?
>
>
> Of course Michael :)  Hundred percent agreement here on these counter-
> arguments.  In the end, turning IBPP as a DLL, no matter how, exposes
> a lot of issues which easily overcome the gains in doing so.
>
> So...  What are the real significant pains which people would like to
> (or think they would) remove by turning IBPP as a DLL?
>
> Luca, I don't know exactly, can you comment?

Yes, I just read now the thread up to this email, and I think I could be  
more clear than I been in my original post.
My scenario looks like having a couple of libraries and a couples of  
executables linked to those libraries. All the libs and exes are developed  
by my company and are written in C++. Since we wanted to try a Firebird  
RDBMS, we had to use the IBPP library, and one executable and one library  
use directly some functionality provided by IBPP, so both of them must  
link to IBPP. The build system of these libs is set up to compile all of  
them as shared libraries when compiling for debug purpose, while as static  
library archives when compiling for a release. This is to improve linking  
time. Now, when I do a release compilation, IBPP is statically linked, so  
there is no problem at all. When a debug compilation is done, then I  
*need* IBPP to be a DLL too, otherwise if IBPP is a static library and I  
statically link my lib and my exe to IBPP, then I will have code  
duplication in both of them.

So, in poor words, is code duplication a problem?

If not, I *do not need* to have a DLL of IBPP :) Usually code duplication  
is a problem, since there could be some singleton which in case of code  
duplication would then become a dualton, or even more :-) Looking to the  
IBPP code I should not encounter any problem when having the code of IBPP  
duplicated here and there, but I am asking you anyway 'cause I wanted to  
be really sure.

> If I get you right you
> want to build an application 'A' which directly needs to use IBPP
> interfaces and also a DLL 'D' which also, but separately, needs to use
> IBPP interfaces.  Up until there, no issue.  Now you also want
> application 'A' to load the DLL 'D' or be linked to it?  Well no issue
> too, except that it's rather strange and that I'm not sure I had to
> build anything such in the past.
>
> If you want to go even a step further and have application A, linked
> to dll D, call some function in dll D which will allocate an IBPP
> object (a Database and Connect it for instance) and then return it to
> A which would then use the resource, then forget about it.  It is
> certainly possible, but with extreme care, the first one being
> compiling both A and D at the same time with the very same compiler
> and settings and dependencies. Which would void reusing D in another
> application A' build at some other time with different tools (if only
> by version of the tools).
>
> Just think of passing a std::string from A to D.  The one from
> compiler C, version V, runtime library L is not the same as the one
> from compiler C', version V', runtime library L'.

Dealing with precompiled libraries, e.g. DLLs, means to know which  
compiler/linker flags it was created with, exactly the same scenario that  
happens when you have to link to a static library someone else alredy  
compiled :)

>
> Daniel, code duplication?  At the source code level, I don't get it.

What about singletons, or static variables? Usually code duplication would  
harm in case of something not expected like a singleton cloned :)

See you,
Luca