Can you load a DLL that implements an abstract class at run-time?

-Craig

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ejigt3$2o33$3@digitaldaemon.com...
> Craig Black wrote:
>> This is not a 1.0 blocker, but it is a blocker my development.  D doesn't have a good solution for cross-platform dynamic libraries.  Full dynamic class loading would be nice, but D should at the very least do what C++ does and support overridding virtual method across DLL boundaries.
>
> I'm not sure why that wouldn't work now. What happens when you try it?

Craig Black wrote:
> So it's possible for DDL to work in Linux.  Are there plans for implementing this in the near future?  If so how long would you expect it to take?

It's in the roadmap, although the milestones are really out of date.

It could be a very long time - weeks going into months - at the current level of manpower we have right now.  Lars and I are working on it when we have time, but honestly, just grokking the spec (correctly) is going to eat up most of that.  Having implemented OMF correctly (I'm pretty sure it's stable, it just needs some refactoring and TLC), I don't think ELF will take anywhere near as long.

The upside is that the DDL core library is pretty much done.  So the worst of it is loading and interpreting an ELF's data correctly.

> Also, it seems that Walter will eventually implement some kind of run-time reflection.  How do you think native reflection would influence DDL?  It seems to me that it would make it easier to do what  you are doing.

Honestly, I don't think Walter is going to go towards runtime introspection and reflection when he's so close to getting full introspection working great at compile-time.  There are also problems with the sheer overhead of symbolic information.  I think we're fare more likely to see this as a third-party thing, like a preprocessor that emits extra D code to cover where Typeinfo is lacking.

But if D did have such a system in place, the only flaw would be that the .exe's compiled-in reflection system would likely be unaware of the dynamically loaded parts.  DDL would have to provide a facade that makes access to the in-situ (.exe part) and dynamic reflection hooks, seamless. :)

However, I am working on a fairly comprehensive runtime-reflection solution as a part of D.  Since DDL's already playing with symbolic information, it's not a huge deal to serve it up in a way that's searchable and iterable.  The only drawback is that it's limited to what gets exposed as symbols, so anything that's compiled into an offset or constant (struct/class fields, enums, etc) is lost.  IMO functions, methods, modules and classes are adequate for most uses, so I'm going ahead with it.

As to what would make it easier to do this, well I don't think reflection is the big stumbling block here.  In order, the major hurdles have been:

1) Lack of experience (this is my first linker and module file loader)
2) Bad specifications (Just OMF.  ELF has been a godsend by comparison)
3) Lack of working examples (there's Binutils and then there's DDL)
4) Loading & Linking problems are *very* hard to debug.

That said, being able to extract anything useful from linked modules has been largely the work of Don and Tomasz.  Actually, it's the one thing that folks using the lib have found easiest to improve.

[another long-winded, rambling post by:]
-- 
- EricAnderton at yahoo

Well, I've been reading the D forums for quite a while with great interest but the news of upcoming v1 forced me into breaking the silence. Being an optimist, there are two features that I am dying to see in D to start using it in our production environment: well- fledged Win32 support (full SDK) and (ideally) an ability to use Microsoft DDK for driver development on D - this is the area where D would shine brightly. But SDK support is probably the biggest issue for me - I am quite well prepared now to shift some of the projected work in my company to D but can do that only in Windows platform infrastructure is ready.

Just my 2c.

Gene

Bill Baxter wrote:

> So, what's left on everyone's lists for D1.0 must-have features?

I think that one thing which is missed in phobos right now is string class which encapsulates utf-8/utf-16/utf-32 handling and issues connected with utf-8 strings e.g.:

        char[] foo = "hög";
        assert(foo.length == 3); // Sorry UTF-8, this is == 4
        assert(foo[1] == 'ö');   // Not a chance!

It's really annoying to write application in language different than English (or multi-language application) using just currently available language support (please note that I am not saying that in C++ it's better :-) - I am just saying that it could be greatly improved).

Problems which I see with current language support are:
1. You need 3 types of functions which are doing same, but getting different
char arrays - char[]/wchar[]/dchar[] as parameters, to write good API you
have to write. Best (maybe I should write worst ;-) ) example is Phobos API
2. It's quite easy to make wrong assumptions about utf-8 encoded arrays. See
example above. It could cause slicing string in wrong place, making it
improperly formatted utf-8 string.
3. What is char[] is probably not so clear for newbies. Especially for
utf-8: is char really one character/code point?
4. String class should be more than just array of characters. It should
probably have some more methods like e.g. removing characters from middle
of string and much more.

Some time ago Chris Miller posted on news list dstring implementation which looks quite good for me(link to site: http://www.dprogramming.com/dstring.php).

But if Walter is not happy enough with this implementation now maybe there
should be at least added alias in object.d:
alias char[] string;

I personally vote for dstring.

-- 
Regards
Marcin Kuszczak
(Aarti_pl)

Craig Black wrote:
> Can you load a DLL that implements an abstract class at run-time?

Sure. Just like in C++. (Note that shared library support isn't there in the linux DMD yet, but this should work under Windows.)

genie wrote:
> Well, I've been reading the D forums for quite a while with great
> interest but the news of upcoming v1 forced me into breaking the
> silence. Being an optimist, there are two features that I am dying to
> see in D to start using it in our production environment: well-
> fledged Win32 support (full SDK) and (ideally) an ability to use
> Microsoft DDK for driver development on D - this is the area where D
> would shine brightly. But SDK support is probably the biggest issue
> for me - I am quite well prepared now to shift some of the projected
> work in my company to D but can do that only in Windows platform
> infrastructure is ready.
> 
> Just my 2c.
> 
> Gene

A mostly complete port of the MinGW windows headers can be found here:

http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI

Could you elaborate on which parts of the DDK you need? I just installed it, and can run bcd.gen on it, but its quite large.

Aye, I have tried a couple of SDK ports - they all require some tweaking to work and I still have problems with some of the functionality.

As of the driver support, I am mostly into NDIS-based development and D looks like a very good choice for safe and stable driver coding. 64- bit support would be great, too, but this can wait.

I can not believe no one is using utf-8 characters in his program and is not concerned about issues with current D char[] implementation, so I repost my previous post. Sorry about reposting - if no one will comment I will get a lesson and thing that maybe this issue is not so much important.

But preferably I will get some even negative comments about importance of having string class built in...

For me string class is something what could significantly improve quality of libraries for D.

Best Regards
Marcin Kuszczak


Marcin Kuszczak napisał(a):
> Bill Baxter wrote:
> 
>> So, what's left on everyone's lists for D1.0 must-have features?
> 
> I think that one thing which is missed in phobos right now is string class
> which encapsulates utf-8/utf-16/utf-32 handling and issues connected with
> utf-8 strings e.g.:
> 
>         char[] foo = "hög";
>         assert(foo.length == 3); // Sorry UTF-8, this is == 4
>         assert(foo[1] == 'ö');   // Not a chance!
> 
> It's really annoying to write application in language different than English
> (or multi-language application) using just currently available language
> support (please note that I am not saying that in C++ it's better :-) - I
> am just saying that it could be greatly improved).
> 
> Problems which I see with current language support are:
> 1. You need 3 types of functions which are doing same, but getting different
> char arrays - char[]/wchar[]/dchar[] as parameters, to write good API you
> have to write. Best (maybe I should write worst ;-) ) example is Phobos API
> 2. It's quite easy to make wrong assumptions about utf-8 encoded arrays. See
> example above. It could cause slicing string in wrong place, making it
> improperly formatted utf-8 string.
> 3. What is char[] is probably not so clear for newbies. Especially for
> utf-8: is char really one character/code point?
> 4. String class should be more than just array of characters. It should
> probably have some more methods like e.g. removing characters from middle
> of string and much more.
> 
> Some time ago Chris Miller posted on news list dstring implementation which
> looks quite good for me(link to site:
> http://www.dprogramming.com/dstring.php).
> 
> But if Walter is not happy enough with this implementation now maybe there
> should be at least added alias in object.d:
> alias char[] string;
> 
> I personally vote for dstring.
> 

Aarti_pl wrote:
> I can not believe no one is using utf-8 characters in his program and is not concerned about issues with current D char[] implementation, so I repost my previous post. Sorry about reposting - if no one will comment I will get a lesson and thing that maybe this issue is not so much important.
> 
> But preferably I will get some even negative comments about importance of having string class built in...
> 
> For me string class is something what could significantly improve quality of libraries for D.

From previous discussions it seemed to me like there was a fair amount of support for a string class.   I think the lack of response could be just that not so many folks feel like it is a "must-have" for 1.0.

I think anything that can be done in a library can wait till post 1.0. C++ had very little in the way of a standard library at "1.0" (and really it still has very little).  But for 1.0, the language itself better be in a state that it is *possible* to write every library on the wish list.  If there is anything in the language itself that would prevent creating a string class like the one you speak of, then I think that needs to be addressed.  But the string class itself can come later.

Of course if dstring really is good enough as-is, then it might as well be in the std library for 1.0.

--bb

This is *very* serious for i18n:

>>         char[] foo = "hög";
>>         assert(foo.length == 3); // Sorry UTF-8, this is == 4
>>         assert(foo[1] == 'ö');   // Not a chance!

char[] should be a real char[], not a sort of byte[] for text. It needs to be fix for non-english.

Best regards,

              Samuel.


Aarti_pl escribió:
> I can not believe no one is using utf-8 characters in his program and is not concerned about issues with current D char[] implementation, so I repost my previous post. Sorry about reposting - if no one will comment I will get a lesson and thing that maybe this issue is not so much important.
> 
> But preferably I will get some even negative comments about importance of having string class built in...
> 
> For me string class is something what could significantly improve quality of libraries for D.
> 
> Best Regards
> Marcin Kuszczak
> 
> 
> Marcin Kuszczak napisał(a):
>> Bill Baxter wrote:
>>
>>> So, what's left on everyone's lists for D1.0 must-have features?
>>
>> I think that one thing which is missed in phobos right now is string class
>> which encapsulates utf-8/utf-16/utf-32 handling and issues connected with
>> utf-8 strings e.g.:
>>
>>         char[] foo = "hög";
>>         assert(foo.length == 3); // Sorry UTF-8, this is == 4
>>         assert(foo[1] == 'ö');   // Not a chance!
>>
>> It's really annoying to write application in language different than English
>> (or multi-language application) using just currently available language
>> support (please note that I am not saying that in C++ it's better :-) - I
>> am just saying that it could be greatly improved).
>>
>> Problems which I see with current language support are:
>> 1. You need 3 types of functions which are doing same, but getting different
>> char arrays - char[]/wchar[]/dchar[] as parameters, to write good API you
>> have to write. Best (maybe I should write worst ;-) ) example is Phobos API
>> 2. It's quite easy to make wrong assumptions about utf-8 encoded arrays. See
>> example above. It could cause slicing string in wrong place, making it
>> improperly formatted utf-8 string.
>> 3. What is char[] is probably not so clear for newbies. Especially for
>> utf-8: is char really one character/code point?
>> 4. String class should be more than just array of characters. It should
>> probably have some more methods like e.g. removing characters from middle
>> of string and much more.
>>
>> Some time ago Chris Miller posted on news list dstring implementation which
>> looks quite good for me(link to site:
>> http://www.dprogramming.com/dstring.php).
>>
>> But if Walter is not happy enough with this implementation now maybe there
>> should be at least added alias in object.d:
>> alias char[] string;
>>
>> I personally vote for dstring.
>>