www.digitalmars.com         C & C++   DMDScript  

D - Implementing extern methods

reply "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
Hi.

Maybe is a dumb question... We can declare extern methods like this:

// test1.d
class SomeObject
{
     extern (D) void someMethod();
}

But I don't know how to implement someMethod() in other d file. I've tried
with:

// test2.d
class SomeObject
{
    void someMethod()
    {
        printf("void SomeObject.someMethod()\n");
    }
}


Wich compiles but (comprehesibly enough) doesn't link, and with:

// test1.d
void SomeObject.someMethod()
{
    printf("void SomeObject.someMethod()\n");
}

Is there a way to implement extern methods or it isn't supported yet?



--
Julio César Carrascal Urquijo
http://www.artelogico.com/
Nov 13 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:bp06d4$mda$1 digitaldaemon.com...

 Hi.

 Maybe is a dumb question... We can declare extern methods like this:

 // test1.d
 class SomeObject
 {
      extern (D) void someMethod();
 }

 But I don't know how to implement someMethod() in other d file. I've tried
 with:

 // test2.d
 class SomeObject
 {
     void someMethod()
     {
         printf("void SomeObject.someMethod()\n");
     }
 }


 Wich compiles but (comprehesibly enough) doesn't link, and with:

 // test1.d
 void SomeObject.someMethod()
 {
     printf("void SomeObject.someMethod()\n");
 }

 Is there a way to implement extern methods or it isn't supported yet?


Look at phobos/std/gc.d, and phobos/internal/gc/gc.d which does it.
Nov 13 2003
parent reply "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
 Is there a way to implement extern methods or it isn't supported yet?


 Look at phobos/std/gc.d, and phobos/internal/gc/gc.d which does it.


Throught delegates? The only lines that have extern (D) are:

aaA.d(500): extern (D) typedef int delegate(void *) dg_t;
aaA.d(540): extern (D) typedef int delegate(void *, void *) dg2_t;
gc\gc.d(91): extern (D) alias void (*fp_t)(Object);

What I want to be able is to define a class in one file and implement some
of it's methods in another. Can we do this?

Thanks
Nov 13 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:bp1adb$2g4f$1 digitaldaemon.com...

 Is there a way to implement extern methods or it isn't supported yet?


 Look at phobos/std/gc.d, and phobos/internal/gc/gc.d which does it.


 Throught delegates? The only lines that have extern (D) are:

 aaA.d(500): extern (D) typedef int delegate(void *) dg_t;
 aaA.d(540): extern (D) typedef int delegate(void *, void *) dg2_t;
 gc\gc.d(91): extern (D) alias void (*fp_t)(Object);

 What I want to be able is to define a class in one file and implement some
 of it's methods in another. Can we do this?


Yes. In phobos\std\gc.d, we have the functions declared but not defined:

void fullCollect();

whereas in phobos\internal\gc\gc.d, it is implemented:

void fullCollect() { ... implementation ... }

The way phobos is built, it is not linked with phobos\std\gc.d, but with
internal\gc\gc.d, though the user of gc never sees the implementation and
doesn't care.
Nov 13 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
Julio did you get this working ?  If so could you post it so we could put it
on the  wiki ?  ( I am still not sure how you would implement this for
classes )


C

"Walter" <walter digitalmars.com> wrote in message
news:bp28fs$uof$3 digitaldaemon.com...

 "Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
 news:bp1adb$2g4f$1 digitaldaemon.com...

 Is there a way to implement extern methods or it isn't supported








yet?

 Look at phobos/std/gc.d, and phobos/internal/gc/gc.d which does it.


 Throught delegates? The only lines that have extern (D) are:

 aaA.d(500): extern (D) typedef int delegate(void *) dg_t;
 aaA.d(540): extern (D) typedef int delegate(void *, void *) dg2_t;
 gc\gc.d(91): extern (D) alias void (*fp_t)(Object);

 What I want to be able is to define a class in one file and implement




some

 of it's methods in another. Can we do this?


 Yes. In phobos\std\gc.d, we have the functions declared but not defined:

 void fullCollect();

 whereas in phobos\internal\gc\gc.d, it is implemented:

 void fullCollect() { ... implementation ... }

 The way phobos is built, it is not linked with phobos\std\gc.d, but with
 internal\gc\gc.d, though the user of gc never sees the implementation and
 doesn't care.
Nov 14 2003
parent "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
"Charles Sanders" <sanders-consulting comcast.net> wrote in message
news:bp3a0h$2ldb$1 digitaldaemon.com...

 Julio did you get this working ?  If so could you post it so we could put


it

 on the  wiki ?  ( I am still not sure how you would implement this for
 classes )



Haven't been able to get it working. Getting lots of compiler assterts
though ;)
Nov 15 2003
prev sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bp28fs$uof$3 digitaldaemon.com...

 "Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
 news:bp1adb$2g4f$1 digitaldaemon.com...

 Is there a way to implement extern methods or it isn't supported








yet?

 Look at phobos/std/gc.d, and phobos/internal/gc/gc.d which does it.


 Throught delegates? The only lines that have extern (D) are:

 aaA.d(500): extern (D) typedef int delegate(void *) dg_t;
 aaA.d(540): extern (D) typedef int delegate(void *, void *) dg2_t;
 gc\gc.d(91): extern (D) alias void (*fp_t)(Object);

 What I want to be able is to define a class in one file and implement




some

 of it's methods in another. Can we do this?


 Yes. In phobos\std\gc.d, we have the functions declared but not defined:

 void fullCollect();

 whereas in phobos\internal\gc\gc.d, it is implemented:

 void fullCollect() { ... implementation ... }

 The way phobos is built, it is not linked with phobos\std\gc.d, but with
 internal\gc\gc.d, though the user of gc never sees the implementation and
 doesn't care.


But they're free functions. The OP (and me!) wants to know how to do this
for classes. In other words, get back to the C++ way of separation of
interface from implementation.
Nov 14 2003
next sibling parent "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
Yes, that's exactly what I want!


 But they're free functions. The OP (and me!) wants to know how to do this
 for classes. In other words, get back to the C++ way of separation of
 interface from implementation.
Nov 15 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bp3d8k$2qe0$1 digitaldaemon.com...

 Yes. In phobos\std\gc.d, we have the functions declared but not defined:

 void fullCollect();

 whereas in phobos\internal\gc\gc.d, it is implemented:

 void fullCollect() { ... implementation ... }

 The way phobos is built, it is not linked with phobos\std\gc.d, but with
 internal\gc\gc.d, though the user of gc never sees the implementation




and

 doesn't care.


 But they're free functions. The OP (and me!) wants to know how to do this
 for classes. In other words, get back to the C++ way of separation of
 interface from implementation.


In file the public sees:
----------------------------------
module xyz;
class Foo
{
    void bar();
}
----------------------------------

In the private implementation f ile:
-----------------------------------
module xyz;
class Foo
{
    void bar() { ... implementation ... }
}
-------------------------------------
Nov 16 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 But they're free functions. The OP (and me!) wants to know how to do




this

 for classes. In other words, get back to the C++ way of separation of
 interface from implementation.


 In file the public sees:
 ----------------------------------
 module xyz;
 class Foo
 {
     void bar();
 }
 ----------------------------------

 In the private implementation f ile:
 -----------------------------------
 module xyz;
 class Foo
 {
     void bar() { ... implementation ... }
 }
 -------------------------------------


But the two files are unrelated, are they not? It's not possible to
"include" the public into the private, one just has to generate a stripped
public one, no? Hence, an opportunity for errors. Or am I missing something?
Nov 16 2003
next sibling parent Patrick Down <pat codemoon.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in
news:bp8mb0$1p2m$1 digitaldaemon.com: 


 But they're free functions. The OP (and me!) wants to know how to
 do 




 this

 for classes. In other words, get back to the C++ way of separation
 of interface from implementation.


 In file the public sees:
 ----------------------------------
 module xyz;
 class Foo
 {
     void bar();
 }
 ----------------------------------

 In the private implementation f ile:
 -----------------------------------
 module xyz;
 class Foo
 {
     void bar() { ... implementation ... }
 }
 -------------------------------------


 
 But the two files are unrelated, are they not? It's not possible to
 "include" the public into the private, one just has to generate a
 stripped public one, no? Hence, an opportunity for errors. Or am I
 missing something? 


So you need dmd -strip
Nov 16 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bp8mb0$1p2m$1 digitaldaemon.com...

 But the two files are unrelated, are they not?


Right.


 It's not possible to
 "include" the public into the private, one just has to generate a stripped
 public one, no?


Right. As Patrick suggested, a tool to do this is possible (and fairly easy
to do).


 Hence, an opportunity for errors. Or am I missing something?


No, you're not missing anything. I anticipate that using this capability
will be pretty rare. At least it is possible to do so, unlike Java.
Nov 17 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Well, there are two aspects to this.

1. IP protection. This may be rare. Most shared software will be
open-source, or at least source-supplied. Most application software will be
binary only. However, once established, there will be

2. The separate writing of interface and implementation as a development
convenience. I know the "wider development community" has an issue with C &
C++'s separation of interface and implementation, but I've always thought

sometimes enormous amounts of implementation into the class interface. If D
was to support both, as C++ does, I think that would be an advantage.
However, I suspect this will never happen, so I'm not going to argue
forcefully for it.

So, we really just want a stripper. How will this be implemented?

I think dmd.exe should support, as standard, the option -strip=<file>. When
it receives this option, it should defer to a strip module (module in the
binary sense, not in the D sense), i.e. a DLL or .SO, called DMDStrip.dll or
libDMDStrip.so, and loaded according to the host operating system's loading
rules. The module should have the following entry points (which should be
C-compatible, so we can use this in other tools):

int DStrip_Initialise()
void DStrip_Uninitialise()
int DStrip_String(char (const) *srcName, char (const) *dest, uint flags);

The inclusion/separation has the following advantages:

1. By being a standard part of the compiler, we can have a standard approach
to the development of scripts (make) and tools leds/DIDE/etc.
2. It does not have to be implemented by Walter. All he has to do is add the
small amount of code into the compiler that parses -strip=<file>, loads the
DLL and calls the entry points. (I expect he'll put some SEH around the
calls, in case the strip author is a gibbering fool. ;)
3. We can each install and write our own strip components, _if we want_
(Most will not, of course)
4. There can be a shared strip project. Hopefully we can start with Burton's
dstrip code, if we're allowed. Naturally, the expectation is that a shared
project would reach very high quality quite quickly.



"Walter" <walter digitalmars.com> wrote in message
news:bpb42k$2a08$1 digitaldaemon.com...

 "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
 news:bp8mb0$1p2m$1 digitaldaemon.com...

 But the two files are unrelated, are they not?


 Right.


 It's not possible to
 "include" the public into the private, one just has to generate a




stripped

 public one, no?


 Right. As Patrick suggested, a tool to do this is possible (and fairly


easy

 to do).


 Hence, an opportunity for errors. Or am I missing something?


 No, you're not missing anything. I anticipate that using this capability
 will be pretty rare. At least it is possible to do so, unlike Java.
Nov 17 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
Forgot to finish a sentence

"Matthew Wilson" <matthew-hat -stlsoft-dot.-org> wrote in message
news:bpb7ig$2ev2$1 digitaldaemon.com...

 Well, there are two aspects to this.

 1. IP protection. This may be rare. Most shared software will be
 open-source, or at least source-supplied. Most application software will


be

 binary only. However, once established, there will be


a non-trivial amount of people who wish to supply binary lib + stripped
header. This will especially be the case if the ABI gets standardised, at
least per operating system-family
Nov 17 2003
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Matthew Wilson wrote:

 a non-trivial amount of people who wish to supply binary lib + stripped
 header. This will especially be the case if the ABI gets standardised, at
 least per operating system-family


DIG compiler driver can generate stripped declaration files.

However, they disable inlining!

-eye
Nov 18 2003
parent "Walter" <walter digitalmars.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bpe6hi$qal$1 digitaldaemon.com...

 DIG compiler driver can generate stripped declaration files.


Cool! I didn't know that.


 However, they disable inlining!


Of course. That's the price paid for hiding the implementation.
Nov 19 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
I agree with you - a stripper is the way to go. It should also be
implemented using the compiler source. But all it needs is the lexer and the
parser, and I think it should just be a separate tool (just built out of the
compiler sources). Unlike C++, you don't need much code to implement
something like this. (In fact, you could not implement this for C++ 100%.)
Nov 17 2003
parent reply Brad Anderson <brad sankaty.com> writes:
Walter wrote:

 I agree with you - a stripper is the way to go. 


Um, I'm trying really hard not to comment here.  In fact, I was hoping somebody 
else would post already, just so I could behave myself.  Hopefully there's a 
sense of humor in this group and Jan won't pull this, but what a great quote 
from our fearless leader.  Just trying to keep it light.
Nov 18 2003
parent "Walter" <walter digitalmars.com> writes:
"Brad Anderson" <brad sankaty.com> wrote in message
news:bpe45l$nfh$1 digitaldaemon.com...

 Walter wrote:

 I agree with you - a stripper is the way to go.


 Um, I'm trying really hard not to comment here.  In fact, I was hoping


somebody

 else would post already, just so I could behave myself.  Hopefully there's


a

 sense of humor in this group and Jan won't pull this, but what a great


quote

 from our fearless leader.  Just trying to keep it light.


LOL! When I was in college, one of the sports was to post on the frat house
wall out-of-context quotes from the members. The rules were that it had to
be an actual quote, and the out-of-context meaning had to be unintended.
Nov 19 2003
prev sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:bp06d4$mda$1 digitaldaemon.com...
| Hi.
|
| Maybe is a dumb question... We can declare extern methods like this:
|
| // test1.d
| class SomeObject
| {
|      extern (D) void someMethod();
| }
|
| But I don't know how to implement someMethod() in other d file. I've tried
| with:
|
| // test2.d
| class SomeObject
| {
|     void someMethod()
|     {
|         printf("void SomeObject.someMethod()\n");
|     }
| }
|
|
| Wich compiles but (comprehesibly enough) doesn't link, and with:
|
| // test1.d
| void SomeObject.someMethod()
| {
|     printf("void SomeObject.someMethod()\n");
| }
|
| Is there a way to implement extern methods or it isn't supported yet?
|
|
|
| --
| Julio César Carrascal Urquijo
| http://www.artelogico.com/
|
|
|

No creo que sea posible, pero no estoy seguro.
(T: I don't think it's possible, but I'm not sure.)

—————————————————————————
Carlos Santander


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.538 / Virus Database: 333 - Release Date: 2003-11-10
Nov 14 2003