- Joined
- May 14, 2008
- Messages
- 10,547
- Reaction score
- 347
- Points
- 158
- Location
- East Sussex
- Website
- blog.gdwnet.com
- Preferred Pronouns
- He/Him
It is? I'd heard that it was due out.... So behind the times with these OS updates!
Well, I do have Win 7 Ultimate, the only problem would be finding all the proper drivers.
Now in order for you not having to copy the whole orbiter API, but in order for a developper not having to port all the code to an entirely different language, how realistic would a SpaceWay C++ API be? Someone else could still write a wrapper for it if he wants to, but porting just to other API calls would be pretty simple if the add-on was designed with the possibility in mind.
There is no way to natively express C++ objects in binary (DLL).
Sorry, but that was a deep dive into the toilet - why do you blame C++ for the limitations of Microsofts PE file format, that it uses for object files, static libraries, executables and DLLs?
Because the first C++ compiler (Cfront) was not really a compiler -- it was a program which translated C++ classes into C code using name mangling. It was a hack to avoid writing a full-blown compiler and an object-oriented executable format... And we're still stuck with this hack 30 years later.
Yes, the C++ language is to be blamed of this. :facepalm:
Symbol resolution belongs to a (dynamic) linker. But instead of writing a C++-aware linker, Stroustrup used a hack (name mangling) and C compiler and linker. Then ISO C++ committee declared that name mangling is an internal functionality of the compiler and thus exempt from standarization. The result is that you cannot access C++ objects in DLL (or .so for that matter) without knowing which version of which compiler was used to generate the binary.
There is NO perfect language for all purposes! (not yet...?)