View previous topic :: View next topic |
Author |
Message |
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Mon Jan 02, 2006 7:20 am Post subject: |
|
|
Nice work Don! That's a very servicable interface.
Out of curiosity, do you have any ideas on how we can hack up a function-pointer symbol for the ctor instead of enumerating the params like that? I tried to do somthing to that effect, but I needed something like a compile-time parser to crack the function symbol down to the format the ctor uses.
Code: | // TODO: might be better to return a delegate? |
That would be ideal, but the current implementation will turn a few heads anyway. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
Don Clugston
Joined: 05 Oct 2005 Posts: 91 Location: Germany (expat Australian)
|
Posted: Mon Jan 02, 2006 8:12 am Post subject: |
|
|
Code: | Out of curiosity, do you have any ideas on how we can hack up a function-pointer symbol for the ctor instead of enumerating the params like that? I tried to do somthing to that effect, but I needed something like a compile-time parser to crack the function symbol down to the format the ctor uses | .
You can certainly do that, but that's not the real problem.
The issue is that for (say) a two parameter constructor TestClass(int, SomeOtherClass),
called with
x= new TestClass(7, other);
the actual call we need to make is:
ctor(x, 7, other);
So we need to add a parameter ('x') to the parameter list of the passed function. There does not seem to be any way to do that in D right now, because you can't get the types of the function parameters out of a function pointer.
More specifically, with .mangleof, you can get the types as a text string, but not as a compile-time type (you can convert text to a type for built-in types, but there's no way to go from "SomeOtherClass" to SomeOtherClass).
Originally I wanted the syntax:
Code: | auto newTestClass = testLibrary.getCtor!(ITestClass function(int, SomeOtherClass), "testmodule.TestClass")();
auto a = newTestClass(7, other); |
but it doesn't seem to be possible right now. Well, the extra parameter could probably be hacked in with a naked thunk... push the address onto the stack and jump to the constructor function. Ugh. Bleah. Sounds like C++.
The new -H option in DMD 0.142 is very interesting, it should allow the use of the raw class without an interface. If you supply "testmodule.dli", you could write
Code: | auto newTestClass = testLibrary.getCtor!(TestClass, "testmodule.TestClass", int)();
auto a = newTestClass(785);
a.test();
|
rather than being confined to ITestClass. Somewhat bizarre, because it would mean that the inlinable parts of TestClass would be statically linked, but the non-inlinable stuff would be dynamically linked... |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Mon Jan 02, 2006 5:27 pm Post subject: |
|
|
Ack. Too bad D doesn't give us the intrspection we crave to make that happen.
Don Clugston wrote: | The new -H option in DMD 0.142 is very interesting, it should allow the use of the raw class without an interface. If you supply "testmodule.dli", you could write
Code: | auto newTestClass = testLibrary.getCtor!(TestClass, "testmodule.TestClass", int)();
auto a = newTestClass(785);
a.test();
|
rather than being confined to ITestClass. Somewhat bizarre, because it would mean that the inlinable parts of TestClass would be statically linked, but the non-inlinable stuff would be dynamically linked... |
That is kinda wierd. Personally, I would use a hand-crafted .di file that has zero inlining, as to avoid versioning conflicts presented by (unpredictable) inlining. But that's just a matter of style -- looks like we're homing in on a tutorial after all, eh? _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
Don Clugston
Joined: 05 Oct 2005 Posts: 91 Location: Germany (expat Australian)
|
Posted: Tue Jan 03, 2006 10:07 am Post subject: |
|
|
Quote: |
Quote: | Somewhat bizarre, because it would mean that the inlinable parts of TestClass would be statically linked, but the non-inlinable stuff would be dynamically linked...
|
That is kinda wierd. Personally, I would use a hand-crafted .di file that has zero inlining, as to avoid versioning conflicts presented by (unpredictable) inlining.
|
I tend to agree, but it's essentially the same situation you have in C++ with a .h/.lib combination. The .h (.di) file needs to be updated whenever the .lib (.ddl) file changes; but it does mean that you can have library classes with highly efficient, inlined members. AFAIK, that it is not possible with DLLs or COM. It would mean you were only dynamically linking in the "heavy" functions. There may be useful applications for it -- perhaps among game programmers? |
|
Back to top |
|
|
h3r3tic
Joined: 30 Mar 2004 Posts: 261 Location: Torun, Poland
|
Posted: Tue Jan 03, 2006 10:50 am Post subject: |
|
|
Don Clugston wrote: | I tend to agree, but it's essentially the same situation you have in C++ with a .h/.lib combination. The .h (.di) file needs to be updated whenever the .lib (.ddl) file changes; but it does mean that you can have library classes with highly efficient, inlined members. AFAIK, that it is not possible with DLLs or COM. It would mean you were only dynamically linking in the "heavy" functions. There may be useful applications for it -- perhaps among game programmers? |
As a hobbyist game developer, I think that using strictly dynamic linking for a whole class is reasonable. Dividing its methods into dynamically and statically linked would be an overkill IMO. It's unlikely that a class with high-level 'heavy' functions will also be doing low-level, high performance operations. If it does, it's a symptom of bad design. Thus, I'd vote for the KISS approach. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Tue Jan 03, 2006 2:31 pm Post subject: |
|
|
Don Clugston wrote: | Quote: |
Quote: | Somewhat bizarre, because it would mean that the inlinable parts of TestClass would be statically linked, but the non-inlinable stuff would be dynamically linked...
|
That is kinda wierd. Personally, I would use a hand-crafted .di file that has zero inlining, as to avoid versioning conflicts presented by (unpredictable) inlining.
|
I tend to agree, but it's essentially the same situation you have in C++ with a .h/.lib combination. The .h (.di) file needs to be updated whenever the .lib (.ddl) file changes; but it does mean that you can have library classes with highly efficient, inlined members. AFAIK, that it is not possible with DLLs or COM. It would mean you were only dynamically linking in the "heavy" functions. There may be useful applications for it -- perhaps among game programmers? |
Well, it's likely you all know my perspective on this
I tend to think of dynamic loading as an exercise in decoupling.
-H does not perform decoupling. Therefore, its value is already limited with respect to this topic. There's also the somewhat non-deterministic aspect of inline that Eric notes above (I, too, would advocate manual construction of "di" files at this time). Thus, I believe it's inviting trouble to consider -H as being relevent. Perhaps that's overstating the point somewhat? I'd vote for the KISS approach too. |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Tue Jan 03, 2006 3:01 pm Post subject: |
|
|
kris wrote: | -H does not perform decoupling. Therefore, its value is already limited with respect to this topic. There's also the somewhat non-deterministic aspect of inline that Eric notes above (I, too, would advocate manual construction of "di" files at this time). Thus, I believe it's inviting trouble to consider -H as being relevent. Perhaps that's overstating the point somewhat? I'd vote for the KISS approach too. |
$0.02:
If it helps the discussion, its not at all far-fetched to roll a tool that composes a proper header from a .ddl or what have-you (IMO, symbols are easier to play with than full-on D sourcecode). Kind of like if ddlinfo output to a .di instead of the bits it does now - its all banked on the strength of the runtime demangler, really.
At least then we'd have a better route for a non-inlined header, rather than "use -H and play with the output". _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Tue Jan 03, 2006 3:25 pm Post subject: |
|
|
pragma wrote: | If it helps the discussion, its not at all far-fetched to roll a tool that composes a proper header from a .ddl or what have-you (IMO, symbols are easier to play with than full-on D sourcecode). Kind of like if ddlinfo output to a .di instead of the bits it does now - its all banked on the strength of the runtime demangler, really.
At least then we'd have a better route for a non-inlined header, rather than "use -H and play with the output". |
That sounds like a very good idea
In terms of constructing the appropriate .ddl, what do you think some guidlines might be? |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
Posted: Tue Jan 03, 2006 3:47 pm Post subject: |
|
|
Quote: | That sounds like a very good idea |
Yes, but is it to .di for? ::snicker::
kris wrote: | In terms of constructing the appropriate .ddl, what do you think some guidlines might be? |
As for the library itself, you'd most likely want to isolate your factory interface into a module such that the .di output doesn't contain extraneous information (such that a compile won't fail w/o an .obj to back it up). Basically, just keep it to interface definitions and functions. The header generator can then be instructed, via the command line, to only export that particular module namespace. _________________ -- !Eric.t.Anderton at gmail |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Tue Jan 03, 2006 4:01 pm Post subject: |
|
|
pragma wrote: | Quote: | That sounds like a very good idea |
Yes, but is it to .di for? ::snicker:: |
Egad!
This is doubly good, since it effectively takes care of the issue whereby a hand-built "di" file could easily be (mistakenly) trashed through using -H in conjunction with Build.exe (or some other tool).
[whew; that's a long sentence] |
|
Back to top |
|
|
pragma
Joined: 28 May 2004 Posts: 607 Location: Washington, DC
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|