Triple code duplication

[Karl Vogel]

On 09 Aug 2004, you wrote in gmane.comp.kde.devel.optimize:

> On Saturday 24 July 2004 11:50, Karl Vogel wrote:
>> While converting kdelibs to a version that explicitly defines
>> what should be exported (using KDE_EXPORT), I noticed that a few
>> things are duplicated. 
>> 
>> For example:
>> 
>> $ objdump -CT /opt/kde/lib/kde3/kbzip2filter.so |grep init_
>> 00001ff0 g    DF .text  00000052  Base        init_kbzip2filter
> As wanted.
> 
>> $ objdump -CT /opt/kde/lib/kde3/kio_help.so |grep init_
>> 0000d900 g    DF .text  00000052  Base        init_kbzip2filter
>> 
>> $ objdump -CT /opt/kde/lib/kde3/kio_ghelp.so |grep init_
>> 0000d900 g    DF .text  00000052  Base        init_kbzip2filter
> Side effect, due to what you noticed:
>> kdelibs/kdoctools uses kbzip2filter.cpp and compiles it directly 
>> into the kio_help.so and kio_ghelp.so shared libs.

Well it's less severe than I first thought... it's only the wrapper
class that is included 3 times.. not the bzip2 code itself.

>> Since this is exactly the same sourcecode as kioslave/bzip2, we
>> now end up with this code duplicated 3 times!
> So? For a little bit of unbzip2 code, it's not worth making a 
> shared library, when every KDE code (other than kio_*help) gets
> that code dlopened from kbzip2filter.so 
> 
> If you want to fix this, add a #define INCLUDED_BY_KIO_HELP in
> kio_help.* and #ifndef INCLUDED_BY_KIO_HELP around the init_ 
> function.

I don't have the sources with me at the moment.. but can't you just
link kbzipfilter2.so to kio_help.so / kio_ghelp.so ?!


>> I'm also wary as I think this can introduce subtle bugs.. ie if 
>> one of those versions is used and then another shared lib is
>> opened containing a version, won't this override the present 
>> version ?! What if some state is kept in a global variable that
>> is now overridden by the new version! 
> I don't follow. The code dlopening kio_help isn't the same as the
> code dlopening kbzip2filter.so, so the above isn't a problem.

Well I was mistaken anyway... in case the same symbols are present
in 2 shared libs, then the ones from the first loaded lib are used. 

And in this case, the libs won't be loaded by the same code anyway, 
right?