Library standardization
e-t172
e-t172 at akegroup.org
Sat Apr 19 06:34:43 PDT 2008
Janice Caron a écrit :
>> I don't think it's a good
>> idea, because it will lead to very strange problems and unexpected behaviour
>> when dealing with shared libraries.
>
> It's an optimisation decision, so it should make no difference
> whatsoever, except to make your code run faster or slower.
When using shared libraries, it makes a big difference.
Imagine I am writing a shared library.
Consider the following function:
void foo()
{
/* do something complex here */
}
This function is big, it is likely it will not be inlined by the
compiler. It will be included in the shared library as a symbol, which
will be referenced by the caller.
So, I compile and release my shared library, version 1.0.0. There is
absolutely no problem at this time.
After the first release of my shared library, I finally find out that
foo() did not have to be that complex. In fact, it can be simplified. So
I rewrite it, without changing the API :
void foo()
{
/* do something simple here */
}
This function is now simple, it is likely it will be inlined by the
compiler. Therefore, it will not be included in the shared library.
So, I compile my shared library, version 1.0.1. When I install it on my
system, all hell breaks loose: all the programs that were using foo()
are crashing at startup because they do not find foo() in the shared
library. What?! But I never changed my API?! How is that possible?
There is clearly a problem here.
More information about the Digitalmars-d
mailing list