Derjo Phar wrote:
> "John Reimer" <jjreimer@telus.net> wrote in message
> news:c3gnjg$1s5f$1@digitaldaemon.com...
> 
>>I hope this is what you were looking for:
> 
> 
> Thank you John. Yes this is exactly it. I was almost there too. The only
> difference between the correct way you have shown and the way I was doing
> it, was that in the correct way there is the line 'module foo;' at the start
> of both the definition file and the implementation file. When I was doing
> it, I did not have that line or any 'module' statement at all.
> 
> I guess I didn't really understand the purpose of the module statement. It
> seems that this identifies the namespace for the file, and if not supplied,
> the namespace is the same as the file name.
> 

In fact, you don't need the module statement.  I believe that if you leave it out, the module name defaults to the filename.  So you probably had it figured out on your own afterall.  I just included it for clarity.

For more information about the specifics of "module":

http://www.digitalmars.com/d/module.html

I also realize it may have been more accurrate to use the terms definition/implementation vereses interface/implementation.  Oh well.

Later,

John

"John Reimer" <jjreimer@telus.net> wrote in message news:c3gvrr$2b48$1@digitaldaemon.com...
> Derjo Phar wrote:
> > "John Reimer" <jjreimer@telus.net> wrote in message news:c3gnjg$1s5f$1@digitaldaemon.com...
> >
> >>I hope this is what you were looking for:
> >
> >
> > Thank you John. Yes this is exactly it. I was almost there too. The only difference between the correct way you have shown and the way I was
doing
> > it, was that in the correct way there is the line 'module foo;' at the
start
> > of both the definition file and the implementation file. When I was
doing
> > it, I did not have that line or any 'module' statement at all.
> >
> > I guess I didn't really understand the purpose of the module statement.
It
> > seems that this identifies the namespace for the file, and if not
supplied,
> > the namespace is the same as the file name.
> >
>
> In fact, you don't need the module statement.  I believe that if you leave it out, the module name defaults to the filename.  So you probably had it figured out on your own afterall.  I just included it for clarity.
>
> For more information about the specifics of "module":
>
> http://www.digitalmars.com/d/module.html

I had read that section of the documentation many times before giving up. I now realize that the paragraph

"Modules have a one-to-one correspondence with source files. The module name is the file name with the path and extension stripped off."

was what confused me. Now I realize that the module name can actually be different from the file name. It's the module name that is the namespace name, and its this that is used by the linkeditor to resolve symbols in the .OBJ file.

Anyhow, I now have two source files...

//---------------- foo.d ---------
 module foo;

 import std.c.stdio;

 class Foo
 {
   private int x;


   /* expose */ int FuncA(){ printf("Inside method implementation funcA of
class Foo\n"); return 1;}
   /* expose */ int FuncB(){ printf("Inside method implementation funcB of
class Foo\n"); return 2;}

 }

and ...

//---------------- foo_i.d ---------
 module foo;

 class Foo
 {
  public:
   int FuncA();
   int FuncB();
 }

So I compile foo.d to get a .OBJ file and I distribute this OBJ file with the foo_i.d file. The "/* expose */" is a tag I can use to generate the foo_i.d automatically via a preprocessor job.


Thanks again.

-- 
Derek

With the following changes in the implementation file, what has to be in the interface module (definition file?).

In article <c3gnjg$1s5f$1@digitaldaemon.com>, John Reimer says...
>
>I hope this is what you were looking for:
>
>Here’s a quick tutorial for setting up an interface file and and implementation file. (I apologize about formatting... might turn up very bad in the newsgroup).
>
>STEP 1:
>
>Create your implementation file:
>
>/* -------------------------------------- */
>module foo;
>
>import std.c.stdio;
>
>class Foo {
static int basis = 0;
int start = 0;
static int funcS(int arg) {
return start + arg;
}
int incrBase() {
basis++;
}
>public:
this(int begin) {
start = basis + begin;
}
>      int funcA() {
>	printf(“Inside method implementation funcA of class Foo”);
return ++start;
>	}
>      int funcB() {
>	printf(“Inside method implementation funcB of class Foo”);
return ++start;
>	}
>}
>
>/* ----- end of implementation file ----- */
>
>
>STEP 2:
>
>Compile the implementation file in a separate directory (your work directory for the project):
>
>dmd -c foo.d
>
>This should produce foo.obj.
>
>Move to another directory of your choice.  This will be a directory that contains a project  that will make use of the foo implementation.  You will be providing an “interface” module that will allow the user to only see the public members of the class.
>
>So in this directory there will be:
>
>/* -------------------------------------- */
>/*
>    This module must be of the SAME NAME as the implementation module
>    because of the way symbols are combined with the module
>    name.
>*/
>module foo;
>
>class Foo {
>public:
>     int funcA();
>     int funcB();
>}
>
>/* ---------- end of interface module -------- */
>
>The interface module is the file you will provide along with the foo.obj (implementation) to the developer.  You do not compile this foo.d.  It will be imported into the external developers project.
>
>An example:
>
>/* --- main project --- */
>module project;
>
>import foo;
>
>int main( char[][] args )
>{
>	int a, b;
>	Foo Foo1 = new Foo;
>
>	printf("\nStarting from main():\n");
>	a=Foo1.funcA();
>	b=Foo1.funcB();
>	printf("\na = %d, b = %d\n", a, b);
>	return 1;
>}
>
>
>The developer will then compile the project like so (making sure that the interface module and implementation object file are in the same directory; if they are not, remember to specify the correct paths):
>
>dmd project.d foo.obj -of project.exe
>
>The provided implementation is linked in with the project.  The developer never sees the implementation details.  Thanks to Walter for the for the gc reference ;-).  Feel free to point any errors.
>
>I'm supposed to be busy studying for an exam... obviously I got sidetracked :-).
>
>Later,
>
>John
>

As I understand it, you simply provide a decleration/prototype for all public members, and that's that... could be wrong, haven't tried it.

-C. Sauls
-Invironz

larry cowan wrote:

> With the following changes in the implementation file, what has to be in the interface module (definition file?).
> 

<snip>

Yes, a more thorough example would have been better, one that included private and static members.  I may work out something later.  Truth be told, I haven't experimented beyond this point, but my assumption was that of C. Sauls.  You just reveal what you want to reveal in the definition (the public members).  It should all work properly because it doesn't change how the implementation module operates internally.

It shouldn't be too much work to add those additions and give it a try.

Later,

John

J Anderson wrote:

> John Reimer wrote:
> 
>> You just have to dig far enough.
> 
> dig being a keyword here.  Dig separates the implementation from definition using doxygen and by compiling to a lib.
> 

Yes, a reference to dig :-).  The Dig toolkit is probably the best example of this kind of thing in action.  Yet a highly simplified example helped me get a feel for how it worked.

<snip?
> 
> So I compile foo.d to get a .OBJ file and I distribute this OBJ file with the foo_i.d file. The "/* expose */" is a tag I can use to generate the foo_i.d automatically via a preprocessor job.
> 
> 
> Thanks again.
> 

You know what?  I never thought of using module keyword that way; the simple solution escaped me.  That's a great idea because than the two files don't have to be the same name.  And foo_i.d can point out the definition file better.

Also the stripping of the implementation with a preprocessor or script is indeed the way to go.

Good work,

John

John Reimer wrote:
> <snip>
> Also the stripping of the implementation with a preprocessor or script is
> indeed the way to go.

In fact, there's already a tool available that does some of this. Dig's strip.d doesn't require the rest of Dig. It's not perfect, but it works on some cases that I've thrown at it.

> 
> Good work,
> 
> John


-- 
Justin
http://jcc_7.tripod.com/d/

J C Calvarese wrote:

> John Reimer wrote:
> 
>> <snip>
>> Also the stripping of the implementation with a preprocessor or script is
>> indeed the way to go.
> 
> 
> In fact, there's already a tool available that does some of this. Dig's strip.d doesn't require the rest of Dig. It's not perfect, but it works on some cases that I've thrown at it.
> 

<snip lots of D code>

Hmmm... I should have known.

Thanks for posting it.  That should make things easier :-).  I was thinking a good 'ol python script was in order here.

Later,

John