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