Hi,

I have several source files bound into one exe. There exists a function "OnCommand" in several of these files. The procs are defined in all sources like:



OnCommand proc private <args>


But when I try to add prototype definitions (to use invoke with functions defined later on)



OnCommand proto <args>


the functions became public and a linker error follows (duplicate symbols)

Is there a way to prevent this effect?

japheth
Posted on 2001-08-12 04:21:09 by japheth
This is normal. Exe's can't be built from .obj's with duplicate public symbols (function or data declaration). You can create a library from your .obj modules. The librarian will keep the 1'st one it sees and discard the others and you'll get a "WARNING" (but it will build).

Otherwise you will have to remove all but 1 instance of OnCommand.


GF
Posted on 2001-08-12 06:03:52 by gfalen
japheth, if you find out how to make PROTOed functions be private,
let me know. I messed with it some years ago and gave up; I had a
lot of other (more important) things to work on... and so do I right
now :/.
Posted on 2001-08-12 13:10:31 by f0dder
fodder,

in the meantime i had given up too. But yesterday I found by chance a solution, at least for my problem. I used

option proc: private

which sets the default scope for proc definitions. Ant it also prevents "proto" from making procs public. The doc states that this option doesn't work if a language is specified in the .model directive, but at least with masm 6.15 it seems to be no problem with ".model flat, stdcall". Of course you then have to expicitely declare your public procs "public".

japheth
Posted on 2001-09-05 03:53:26 by japheth
Nice nice nice, japheth :). This looks like it's exactly what I want.
I seem to have a vague recollection of using it some years ago,
but that might just be bullocks. I'll have a look at it.
Posted on 2001-09-05 11:41:54 by f0dder
japheth, yes -- awesome. That will surely come to use!
Posted on 2001-09-05 18:54:35 by bitRAKE
Hats Off to you japheth!

As well i think this may better serve encapsulation in our OOP model... its time to experiment, Thanx!

NaN
Posted on 2001-09-05 23:23:10 by NaN