name resolution in module imports

Denis Koroskin 2korden at gmail.com
Fri Oct 1 09:29:27 PDT 2010


On Fri, 01 Oct 2010 20:19:01 +0400, Jon Perez <jbperez808 at yahoo.com> wrote:

> In the Youtube tech talk by Andrei (
> http://www.youtube.com/watch?v=RlVpPstLPEc ), the audience member raises  
> a
> point at @34:20 about how code that does not qualify a module in a  
> function
> call, and just relies on function signatures to know which module this  
> belongs
> to may break if a newer version of the modules it imports suddenly puts  
> into
> the namespace a new function with the same signature as another module.
>
> Andrei argues that this is a deliberate trade-off.  I think this is fine  
> in a
> statically linked library context because the binaries you ship never  
> break
> anyway.  But what about in a dynamically linked library scenario?
>
> game.exe links to module1.dll and module2.dll and calls  
> drawcircle(int,int)
> which is not defined in module2 right now, but what if module2.dll gets
> updated in the future and suddenly introduces a drawcirlce(int,int) as  
> well?
> Now game.exe will throw a runtime error.
>

Usually, you need to specify the DLL for each function that is not defined  
in your code. You can do it by either linking with a .lib or .def file.  
Both map function name to concrete DLL. Either way, once an executable  
compiled there is a correspondence from each function to a .DLL file, and  
thus situation you describe is impossible.


More information about the Digitalmars-d mailing list