www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - name resolution in module imports

reply Jon Perez <jbperez808 yahoo.com> writes:
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.
Oct 01 2010
next sibling parent Justin Johansson <no spam.com> writes:
On 2/10/2010 2:19 AM, Jon Perez 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.


Is this a recap of DLL-hell?
Oct 01 2010
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 01 Oct 2010 20:19:01 +0400, Jon Perez <jbperez808 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.
Oct 01 2010
parent Jon Perez <jbperez808 yahoo.com> writes:
 Either way, once an executable compiled there is a
 correspondence from each function to a .DLL file,
 and thus situation you describe is impossible.


Ah yes, right.  So if game.exe called drawcircle(int,int)
in module1 at the time it was compiled, it will know to
keep calling that even if module2.dll now has a function
with the same name and signature.
Oct 01 2010
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Jon Perez wrote:

 In the Youtube tech talk by Andrei (
 http://www.youtube.com/watch?v=3DRlVpPstLPEc ), the audience member rai=


ses a

 point at  34:20 about how code that does not qualify a module in a func=


tion

 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.=



=20
 Andrei argues that this is a deliberate trade-off.  I think this is fin=


e in a

 statically linked library context because the binaries you ship never b=


reak

 anyway.  But what about in a dynamically linked library scenario?
=20
 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.
=20


	What Andrei describes is only valid at the source code level. Once
the program is compiled, it doesn't use "drawcircle(int,int)" to
identify the function, instead it uses the mangled name which
includes the module name anyway.

		Jerome

PS: BTW, this has nothing to do with static vs dynamic linking. If
you link statically against module1 and module2 and they both
contain a function named drawcircle(int,int) then a file may still
call the unqualified drawcircle if it imports only one of the modules.
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Oct 01 2010