dll, sdk - non c++ - general api questions.

[aguest]

I am currently playing around with irrlicht from a non c language using only
the dll. Seems like a really great tool. This is fun.

A few questions.

1) Not all (but by just briefly looking, nearly all) functions are dll contained.
I mean that, a sdk for other languages is mostly a lot of object descriptions
and function prototypes. Easy to do. But the parts that are not dll contained,
for example "node->setMaterialFlag" makes for more work. (or tutorial
changes) Are there more advanced functions like this?

2) When will the class structures reach a more stable point? I noticed that
quite a few vtable members and some data changed positions from .9 to
.10. Will it stabilize evetually?

3) Ok, c++ export name mangling is on again. I import by ordinal to get
around that. Would a c straight export be utterly impossible now? An extra
export perhaps? C_CreateDevice ?

4) Any comment/flames/whatever towards this approach? Will this approach
fail at a later point? Are there other parts Ive yet to discover, that would
render non-c++ compilers useless/troublesome?

Cheers, and thanks for a (seamingly) great tool, and some fun sdk
translation exercises.

[aguest]

Just to elaborate a bit...

From what Ive seen so far of the sdk files, headers to use irrlicht from
pascal/delphi/visbasic and whatever, would be some typing but not to
complicated. It would be if the binary object layout changed with every
release though.

Looking around at some other enginges, this could be a small "popularity"
boost. Most seems really strictly bound to c++ (specific c++ compilers even)

But it would add some considerations when updating the api. And I dont feel
like doing a complete sdk translation just to find I need to do it again and
again.

ps. Im not a hardcore c++ guy but, theoretically this would help msvc <> gcc conflicts too right? I am not sure at what point the internal handling of
objects collides? From a user program, communicating to the dll, and objects, they should be able to work together... I am fairly sure most things
are handled the same... I guess you´d have to manually create objects...
When using irrlicht, when do you call the constructor yourself?
Most objects seem to be created internally and returned with calls.

[niko]

Hi,

1) Not all (but by just briefly looking, nearly all) functions are dll contained.
I mean that, a sdk for other languages is mostly a lot of object descriptions
and function prototypes. Easy to do. But the parts that are not dll contained,
for example "node->setMaterialFlag" makes for more work. (or tutorial
changes) Are there more advanced functions like this?

Yes, I think there are. There are lots of methods directly inline implemented in the header files. Just for making it easier for me to develop that thing.

2) When will the class structures reach a more stable point? I noticed that quite a few vtable members and some data changed positions from .9 to .10. Will it stabilize evetually?

I think the stable point is nearly reached, but, however, I think that some methods will be rearranged/renamed/added/whatever in the future anyway. It is nearly not possible to prevent this.

3) Ok, c++ export name mangling is on again. I import by ordinal to get
around that. Would a c straight export be utterly impossible now? An extra
export perhaps? C_CreateDevice ?

Yes, I switched this on again because the some people wrote bug reports that Irrlicht crashed, just because they confused the gcc and VisualStudio dlls. I think with this on again, they should notice fast that the problem is not in Irrlicht but in their code/directory structure.

4) Any comment/flames/whatever towards this approach? Will this approach
fail at a later point? Are there other parts Ive yet to discover, that would
render non-c++ compilers useless/troublesome?

I think that your approach is a little bit dangerous, if I I'll do some changes in the future which you won't notice, your program wouldn't like it, of course. Lots of people had problems because of this, because Irrlicht is written in C++ and not C. I already thought about writing a C frontend for Irrlicht, lots of people could need that. But unfortunately, I've got no time for this. But maybe we'll find a volunteer.

[aguest]

Thank you for the clarifications.

Why would it crash just because the dll was compiled with another compiler?
A msvc compiled dll can be used from gcc and vice versa. Unless there is
some small specifics, but afaik these can be made compatible. Their object
layout should be the same no? (yet not officially claimed to be?)

Is there irrlicht runtime incompatibles between msvc/gcc currently?

Aha, dangerous, I like the sound of that. .
Well, I have no problem with it because making headers is something I
always have to do (thats the way it is when not using c++)

But I would feel sorry for those who would think everything was fine if I made
some examples.. (as they would probably need rather active maintainance

[aguest]

>Yes, I think there are. There are lots of methods directly inline implemented
>in the header files. Just for making it easier for me to develop that thing.
So, they might recieve "virtual" status eventually?

Ooki, Im sorry if I seemed ignorant. Fiddled with the different dll´s... they are
indeed incompatible. Hmm. I might take a look at why... I think it should be
possible to make it compatible. Sweet engine btw...

Cheers.

[niko]

they are
indeed incompatible.

Because different compilers arrange virtual functions just like they want, and they also use a different naming for example for the namespaces. Welcome to the weired world of C++