Have you ever tried to cast or inherit from a class that´s in a dll?

At compile time you´ll always get symbol errors.

I´m able to create instances from a class with an export function that returns the class but, what can i do to make special uses of this class such as casts?

Heinz wrote:
> Have you ever tried to cast or inherit from a class that´s in a dll?
> 
> At compile time you´ll always get symbol errors.
> 
> I´m able to create instances from a class with an export function that returns the class but,
> what can i do to make special uses of this class such as casts?

Typing's done at compile time, so you need the class definition at that point. You can use a base class or interface, but that's about it. Unless you make the code that uses the dll symbols into a dll, which might work.

"Heinz" <malagana15@yahoo.es> wrote in message news:fnlkma$10e5$1@digitalmars.com...
> Have you ever tried to cast or inherit from a class that´s in a dll?
>
> At compile time you´ll always get symbol errors.
>
> I´m able to create instances from a class with an export function that
> returns the class but,
> what can i do to make special uses of this class such as casts?

I think you'd basically have to export (in the DLL) the typeinfo for the class, and then in your app, emit references to them using extern(D) and such.

This is a terrible mess, and DLLs have far more issues than that -- getting a DLL to link to a symbol within the app that loads it is hackish and only useable in certain circumstances, and there are interactions with the GC that I don't think anyone really understands.  Basically DLLs are terrible for anything more than a simple C interface, and their issues only make themselves known with D since it's got a lot more complex interfaces than C does.

The equivalent things on *nix systems and Darwin/OSX (SOs and Dylibs) are far more powerful, and basically work like a compile-time linker but at runtime, making this a non-issue on those platforms.

To solve this, there is DDL, D Dynamic Libraries, a library that allows you to dynamically (manually) load and link the object files produced by DMD on Windows.  It's a little rough around the edges but does what it's supposed to.  Now, deriving from a class that's in a library, that's something I don't think it can do, only because that has to be resolved at compile time, something that DDL can't be a part of :\