Question VB in Orbiter?

[StevoPistolero]

I really don't want to learn C++ . I am willing to learn Visual Basic. Is there a way to write the bulk of the code in Visual Basic and translate it into C++?

 

[Nistenf]

Just for curiosity, why don't you wanna learn C++?

 

[orb]

Is there a way to write the bulk of the code in Visual Basic and translate it into C++?

There is a way. If you know both Basic and C++, you can translate your code yourself from Visual Basic to C++.

 

[Wishbone]

I personally find mixed language programming a bit tiresome, unless it's managed code under .NET. Also, which VB version are you using? There are quite popular addons here that use .NET 3.5 and .NET 2.0 frameworks (possibly done in C# or VB.NET), but again, interfacing managed and unmanaged code gets quirky sometimes, and a small omission in memory management may crash Orbiter...

 

[StevoPistolero]

I am learning visual basic to write scripts for Rhino. I think coding in VB seems doable. I attempted learning a bit of C++, but it still looks like gibberish to me.

 

[Wishbone]

hehe, it *is* gibberish, as any foreign language you hear for the first time. Yet if you want to write the bulk of your code in VB6, for instance, and call Orbiter API, you have to learn the following, at least:

- C memory model
- procedure calling conventions
- names of datatypes in C that correspond to datatypes in VB
- how to treat C strings and how to pass VB strings to C routines
- pointers and references
- structures and unions
- array indexing
- VB Declare statement

That's what I can come up with off top of my head. BTW, I have seen somewhere on the Net automatic header file converters to VB declarations (more or less like API Viewer 2004), to enable linking with Orbiter's libraries, grab them ASAP.

 

[StevoPistolero]

What about C#?

Can C# talk to C++ code more easily than VB?

 

[Wishbone]

Not exactly. The key difference is memory model in unmanaged and managed code. C# and VB.Net have very much in common, since they simply express the same underlying concepts from the Common Language Runtime (including templates and extensions - used a lot and lambda expressions - which I don't really use).

I've been mixing VB.NET (e.g. for the main visual GUI) and C/C++/Fortran/Delphi code (for back-end computations or DB interface, in a separate DLL), but have always opted for fully managed code as soon as a port was available. There is too much potential for memory leaks and subtle (or gross) blunders. With Orbiter, I enjoy writing in C++ because I know that there is no language/ABI-border crossing.

EDIT: If the routines called from C#/VB.NET/whatever CLR language have scalar arguments, and don't deal with dynamically allocated memory/strings/arrays, you're for the most part shielded from blunders.

 

[Face]

Can C# talk to C++ code more easily than VB?

What Wishbone said. For .NET in Orbiter, you could take a look at Orbiter.NET. There you'll have examples for vessels in C# and VB.NET.

 

[The Aviator]

(Total C++ noob question)
So, since I started studying C++ two weeks ago for Orbiter purpose, your advice is learning to write native or managed code?

 

[StevoPistolero]

This orbiter.net library looks great! Looking at the C# examples I can understand the source code! This will be easier than I thought.

Do I just compile the C# code to create a DLL library?

I wish there was a tutorial to walk me through it. I also wish there were more MFD examples, which is what I want to build.

But from what I can tell, I just write the MFD in C#, referencing the Orbiter libraries as needed, compile it, and make sure the orbiter.interfaces and orbiter.wrapper DLLs are included in the release.

Is it really as easy as all that? The garbage collection and other non-intuitive C++ parts will be handled automatically? Are there any catches, pitfalls, or limitations I need to look out for? Can I reference any orbiter method I want or is there only a few I can use, limited by the wrapper? Do I use the Orbiter API reference, or do I have to throw it out and use some (non-existant?) reference specific to orbiter.net? Why doesn't everyone do this? Why write in C++ at all for orbiter?

 

[Face]

This orbiter.net library looks great! Looking at the C# examples I can understand the source code! This will be easier than I thought.

Do I just compile the C# code to create a DLL library?

I wish there was a tutorial to walk me through it. I also wish there were more MFD examples, which is what I want to build.

But from what I can tell, I just write the MFD in C#, referencing the Orbiter libraries as needed, compile it, and make sure the orbiter.interfaces and orbiter.wrapper DLLs are included in the release.

Is it really as easy as all that? The garbage collection and other non-intuitive C++ parts will be handled automatically? Are there any catches, pitfalls, or limitations I need to look out for? Can I reference any orbiter method I want or is there only a few I can use, limited by the wrapper? Do I use the Orbiter API reference, or do I have to throw it out and use some (non-existant?) reference specific to orbiter.net? Why doesn't everyone do this? Why write in C++ at all for orbiter?

Woa, woa, hold your horses there...

Orbiter.NET is of course not finished. Many OAPI calls are missing, as well as a load-strategy for module plugins. ATM it is possible to write vessels in VB or C#, but only to a certain degree, determined by the set of functions already wrapped.

That said, your assumption is indeed the goal for Orbiter.NET. Reference the Orbiter.Interfaces and Orbiter.Wrapper assembly in your .NET project, compile it, and you are set.

As for your question regarding why to write an addon in C++ at all, I guess it ultimately comes down to performance. Although my quick tests showed, that e.g. ShuttlePBdotNET's performance is pretty close to the native one.

regards,
Face

 

[Wishbone]

A nice feature of .NET is that (command-line) compilers for both C# and VB.NET are shipped with the framework FREE. They are csc.exe and vbc.exe.

Re: garbage collection. Interop with unmanaged code beyond the wrapper requires that you write and test the declaration yourself. This means that you're back to square one as far as knowledge of C++ memory stuff (stack, heap, arg passing, malloc()) goes, plus the necessity to specify MarshalAs. flags.

EDIT: Re: "why doesn't everyone do .NET for orbiter?". I won't name names but a very highly skilled and acclaimed team of developers here IS using .NET. The problem is, not everybody is as skilled as those guys, and "while in Rome do as Romans do" adage applies to almost everybody else. Orbiter API with its classes and C++ name mangling is best approached without extra blinders... In fact, it doesn't matter what language one uses if it gets the job done. It could be Perl or Java or Eiffel or Ada. Much more important are the algorithms you use and their complexity.