FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Don's Compile-time Symbol Mangler
Goto page Previous  1, 2, 3
 
Post new topic   Reply to topic     Forum Index -> DDL - D Dynamic Libraries
View previous topic :: View next topic  
Author Message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Mon Jan 02, 2006 7:20 am    Post subject: Reply with quote

Very Happy

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. Wink
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
Don Clugston



Joined: 05 Oct 2005
Posts: 91
Location: Germany (expat Australian)

PostPosted: Mon Jan 02, 2006 8:12 am    Post subject: Reply with quote

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++. Smile

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
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Mon Jan 02, 2006 5:27 pm    Post subject: Reply with quote

Ack. Too bad D doesn't give us the intrspection we crave to make that happen. Sad

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
View user's profile Send private message Yahoo Messenger
Don Clugston



Joined: 05 Oct 2005
Posts: 91
Location: Germany (expat Australian)

PostPosted: Tue Jan 03, 2006 10:07 am    Post subject: Reply with quote

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
View user's profile Send private message
h3r3tic



Joined: 30 Mar 2004
Posts: 261
Location: Torun, Poland

PostPosted: Tue Jan 03, 2006 10:50 am    Post subject: Reply with quote

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
View user's profile Send private message MSN Messenger
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Tue Jan 03, 2006 2:31 pm    Post subject: Reply with quote

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 Smile

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
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Tue Jan 03, 2006 3:01 pm    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Tue Jan 03, 2006 3:25 pm    Post subject: Reply with quote

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 Smile

In terms of constructing the appropriate .ddl, what do you think some guidlines might be?
Back to top
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Tue Jan 03, 2006 3:47 pm    Post subject: Reply with quote

Quote:
That sounds like a very good idea Smile


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
View user's profile Send private message Yahoo Messenger
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Tue Jan 03, 2006 4:01 pm    Post subject: Reply with quote

pragma wrote:
Quote:
That sounds like a very good idea Smile


Yes, but is it to .di for? ::snicker::

Egad! Very Happy

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
View user's profile Send private message
pragma



Joined: 28 May 2004
Posts: 607
Location: Washington, DC

PostPosted: Thu Jan 05, 2006 9:17 am    Post subject: Reply with quote

Added a research task for this:

http://trac.dsource.org/projects/ddl/ticket/36
_________________
-- !Eric.t.Anderton at gmail
Back to top
View user's profile Send private message Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> DDL - D Dynamic Libraries All times are GMT - 6 Hours
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
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