D - Implementing extern methods
- "Julio César Carrascal Urquijo" <adnoctum phreaker.net> Nov 13 2003
- "Walter" <walter digitalmars.com> Nov 13 2003
- "Julio César Carrascal Urquijo" <adnoctum phreaker.net> Nov 13 2003
- "Walter" <walter digitalmars.com> Nov 13 2003
- "Charles Sanders" <sanders-consulting comcast.net> Nov 14 2003
- "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> Nov 14 2003
- "Julio César Carrascal Urquijo" <adnoctum phreaker.net> Nov 15 2003
- "Walter" <walter digitalmars.com> Nov 16 2003
- "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> Nov 16 2003
- Patrick Down <pat codemoon.com> Nov 16 2003
- "Walter" <walter digitalmars.com> Nov 17 2003
- "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> Nov 17 2003
- "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> Nov 17 2003
- Ilya Minkov <minkov cs.tum.edu> Nov 18 2003
- "Walter" <walter digitalmars.com> Nov 19 2003
- "Walter" <walter digitalmars.com> Nov 17 2003
- Brad Anderson <brad sankaty.com> Nov 18 2003
- "Walter" <walter digitalmars.com> Nov 19 2003
- "Carlos Santander B." <carlos8294 msn.com> Nov 14 2003
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
"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
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
"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
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
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
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
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> "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
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
"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
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
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
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
"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
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
But they're free functions. The OP (and me!) wants to know how to do
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
"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
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
"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
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 this a strength, and I consider Java, C# and D weak, since they force 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
public one, no?
Right. As Patrick suggested, a tool to do this is possible (and fairly
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
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
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
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
"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
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
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
"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.
else would post already, just so I could behave myself. Hopefully there's
sense of humor in this group and Jan won't pull this, but what a great
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
"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