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