There's A Direct3D 9.0 Gallium3D State Tracker

[zhasha]

an application that supports multiple renderers (d3d/ogl) will probably call LoadLibrary on d3d9.dll.

That could actually raise a concern under linux. Luckily again for us though, the vtable won't ever change on the C++ objects, as the API has already been decided upon (and somewhat abandoned).
Looking through some WINE headers reveals that the COM way of doing this is actually exactly the same as your example. That is to say, expose functions as virtual.

EDIT: On windows though, MS will always provide you with both OpenGL32.dll and d3d[something].dll (which is probably the latest version out anyway), so most developers probably don't care about runtime loading.

[mdias]

You sure can link C to C++. But when you introduce pure (or not) virtual interfaces, then vtables get used.
Plus, an application that supports multiple renderers (d3d/ogl) will probably call LoadLibrary on d3d9.dll.

[zhasha]

True. Don't know why I mention static linking. I meant manually opening the library with dlopen vs automatic resolving by the OS.
Sorry.

In that case sorry. I read 'dynamic linking' and didn't think for a second about runtime linking. Yes, that does get ugly as all hell with C++ classes. Namely because you have to resolve every single symbol yourself :/ - We're in luck though, because the C API of COM is a bunch of structs filled with function pointers a la vtables.
Obviously WINE won't ever use any C++ components so long as they maintain it should all be ANSI C for portability's sake. However, have you ever heard of an application that tries uses LoadLibrary on D3D?
The reason I decided to implement it in C++ was simply to have inheritance and virtual functions available with ease. It can get pretty ugly pretty fast when you do that sort of thing in C.

Again, sorry. I've heard too many people with their "OMG CNT LEENK C++ LIBS OLOLOLO" crap and I assumed you were one of them.

[mdias]

Here's proof of what I say even without using dlopen() and other related methods:

http://dl.dropbox.com/u/87650/forum_posts/test_lib.zip

If you compile and run as it is, it runs very well. After that try to uncomment the commented lines on the "lib" directory, and compile again. You'll notice that del isn't being called anymore... Where's your name mangling now?

I've included a compile script to make it easy for you to test.

[mdias]

No, he also dynamically links, just not with dlopen, but at the start of the program. Statically linking is a little different, where you link at compile time. Nobody really uses that in Linux development.

True. Don't know why I mention static linking. I meant manually opening the library with dlopen vs automatic resolving by the OS.
Sorry.

[Remco]

We're not, we're trying to have a discussion. You're not the center of the world.

Now, did you even read what I wrote? I was talking about DYNAMIC loading of a library, hence the reference to dlsym() functions and so on. It's all very preety when you statically link to an implemented class, but we're talking about pure virtual methods here that your binary will never know in which address they are.

No, he also dynamically links, just not with dlopen, but at the start of the program. Statically linking is a little different, where you link at compile time. Nobody really uses that in Linux development.

[mdias]

Why is everyone convinced I'm trying to screw you all over?

We're not, we're trying to have a discussion. You're not the center of the world.

Now, did you even read what I wrote? I was talking about DYNAMIC loading of a library, hence the reference to dlsym() functions and so on. It's all very preety when you statically link to an implemented class, but we're talking about pure virtual methods here that your binary will never know in which address they are.

For those blasting about me blasting about microsoft tech, this isn't microsoft tech, it's common tech. This method of linking to a library at compilation time isn't just available to microsoft or linux. Same goes for dynamic loading.

And what I said remains true, the methods aren't resolved when you call them and then "cached". This would imply that you call to the external library would first have to lookup (even on the cache) to call the correct address. This is done at loading time of the library only.

I'm not throwing around unfounded claims, you're the one who seems to think that you're the center of all knowledge and the God of us all. Please take care of your attitude.

[Remco]

Well, I'd kill for that feature on C++, but I don't think it's possible, no... Only the library that implements MyClass would know how to build a new instance of that class. You can have a static member function that does just that though, but that's coming back to the factory thing really...

On wonderland you'd be able to do what you just said and a little bit more, like overriding member functions after instantiation and so on, but I don't even want to think about the complexity of that compiler-wise...

Or how about deriving from a library class? This is something people tend to do in Java. There is also a pattern to define a few functions as pure virtuals which are called at specific times. For example, if you define a scenegraph, where the base class has a pure virtual member named render(), then you can create a tree of objects that can render themselves in some graphics context. AFAICS it's not possible to create a C++ library that allows this.

[V!NCENT]

Just one question: do you plan to make some dummy implementation of d3d taken from wine first and then slowly implementing the real functions?

You are mixing some things here. Wine is an application that translates Windows functionality to UNIX functionality. For example it translates DirectX to OpenGL while it's running.

What Zhasha is doing is making a part of a graphics driver so people can make and run Direct3D (graphics library of DirectX) applications on UNIX (and Linux).

I'm not sure I understand what you mean by "dummy implementation" but I can assure you I'm not taking code from WINE. I sometimes look at their implementation to figure out undocumented details but that's about it.
Right now, if you look at the code, you'll see a lot of stubs (functions that aren't implemented but still defined)

What he means is: "Are you going to change the Wine source code with small patches so that you can put your D3D implementation in place, but without being useful (dummy implementation) and then add features over time to make it useful?"

[zhasha]

I'm not sure I understand what you mean by "dummy implementation" but I can assure you I'm not taking code from WINE. I sometimes look at their implementation to figure out undocumented details but that's about it.
Right now, if you look at the code, you'll see a lot of stubs (functions that aren't implemented but still defined)