C# Programming Language

eveningsky339

Resident Orbiter Slave
Addon Developer
Donator
Joined
May 3, 2008
Messages
1,062
Reaction score
1
Points
0
Location
Western Maine
Recently I've run into a programming language called C#. It is very similar to C and C++ in many ways, though it is more simple and faster to learn. It is possible to compile .dlls with this language.

Does anyone know if dlls written in this language are compatible with Orbiter? It would be interesting to see the pros and cons of using this language compared to c++.
 
C# is a language similar to Java, but less refined as the current version (Java 2 Version 6).

I don't see anything C# can do, which Java can not do better.
 
C# is a language similar to Java, but less refined as the current version (Java 2 Version 6).

I don't see anything C# can do, which Java can not do better.

This is not compared to C++, is it?
I tend to prefer Java for non-technological reasons, like the C# patents owned by microsoft. But how does Java compare to C++? And C#? And how well can they be used for Orbiter add-ons?

Is there any Orbiter plugin developed with a different language than C++?

I once considered using Java for a web applet, but I wanted to do 3D, and there didn't seem to be a single standard for that which is installed on all people's computers.
 
As soon as I'm done working on my current addon I will try to compile a simple .dll in C# and see how it works with Orbiter. It's worth a shot.
 
I tend to prefer Java for non-technological reasons, like the C# patents owned by microsoft. But how does Java compare to C++? And C#? And how well can they be used for Orbiter add-ons?

Java became very similar to C++ lately, as it now also allows templates, but it also had the addition of meta-data inside the language structure.

C# is still more like a old version of Java, from what I can say, with a .NET API.

You could create a Java VM for Orbiter add-ons, but even the embedded version is not really good for high performance.
 
The SDK for orbiter is designed for C++ classes and standard C functions, so if you want to write a module for orbiter in C#, you will have to provide C++style interfaces to the SDK (never really done it, but it's done via 'unsafe' and unmanaged code, and probably with the DLLImport directive).

The main pros of C# over C++ for orbiter (emphasis added before the inevitable out of context whining begins) would be:
* Easier learning curve as C# is an easier language to learn for simple cases
* Better error handling and exepction catching along with fewer crashes from memory mismanagement due to inbuild memory manager and the virtual machine

Cons would be:
* Harder to integrate as interface is designed for C++/C
* Lack of compatibility with simple things like GDI for drawing to the MFDs
* Everyone who wants to use your addon would be required to install the .NET framework.
* Lack of suppert from the Orbiter community as a lot of the Orbiter SDK-know-how is based in C++.

I don't see anything C# can do, which Java can not do better.
That's an incredibly naive and short sighted view. I can name many things. Using the .NET framework (which is a damn good set of libraries) is the first that comes to mind. Any reason for your bigotry?
 
That's an incredibly naive and short sighted view. I can name many things. Using the .NET framework (which is a damn good set of libraries) is the first that comes to mind. Any reason for your bigotry?

Using the .NET framework, which is just a "MFC reloaded", is not what I consider an important feature of a programming language.

Just take a look at the full Java API and then compare this to .NET... and I don't even consider the full Java API anything divine. An API should be suited for the task you want to do with it. For windows / linux application development, wxWidgets makes more sense to me as .NET, MFC and Swing together.

More important to me is, how minimal a language can be - not how much stuff I need to throw into it only for making a minimal application. Lua is a good example of minimalism. Even HAL/S is minimal compared to C# or Java.
 
C# is very good for quickly developing a GUI-based application which has more capability than a VB program.

For a case like Orbiter, where you want your addon to be running as quickly as possible, you don't want to have the .NET framework sitting under it all translating it into machine code. Interpreted languages like Java and the .NET languages are not the most suited to real-time simulations.
 
For windows / linux application development, wxWidgets makes more sense to me as .NET, MFC and Swing together.
:clap::hesaid:
I'm using wxWidgets exactly for that, and I'm quite pleased with it. Maybe the only thing that compares to it is Qt, if you work with C++ and don't mind using a "Meta Object Compiler".

But I think it's a bit off-topic, as these are GUI toolkits, which are less useful when developing for Orbiter.
 
C# is very good for quickly developing a GUI-based application which has more capability than a VB program.

For a case like Orbiter, where you want your addon to be running as quickly as possible, you don't want to have the .NET framework sitting under it all translating it into machine code. Interpreted languages like Java and the .NET languages are not the most suited to real-time simulations.
Is .NET necessary to translate a .dll written in C#? I have a very limited understanding of programming, but I've always thought that there is no difference between a .dll compiled in C/C++ and C#.
 
The SDK for orbiter is designed for C++ classes and standard C functions, so if you want to write a module for orbiter in C#, you will have to provide C++style interfaces to the SDK (never really done it, but it's done via 'unsafe' and unmanaged code, and probably with the DLLImport directive).

The main pros of C# over C++ for orbiter (emphasis added before the inevitable out of context whining begins) would be:
* Easier learning curve as C# is an easier language to learn for simple cases
* Better error handling and exepction catching along with fewer crashes from memory mismanagement due to inbuild memory manager and the virtual machine

Cons would be:
* Harder to integrate as interface is designed for C++/C
* Lack of compatibility with simple things like GDI for drawing to the MFDs
* Everyone who wants to use your addon would be required to install the .NET framework.
* Lack of suppert from the Orbiter community as a lot of the Orbiter SDK-know-how is based in C++.

That's an incredibly naive and short sighted view. I can name many things. Using the .NET framework (which is a damn good set of libraries) is the first that comes to mind. Any reason for your bigotry?
First, its not bigotry if you've used both and your evaluation is informed. Second, consider your decision of having to use the .NET framework as a con, then defending it as an advantage. We were discussing this in terms of Orbiter.

Let's not start the Java vs. C++/C# flame wars here; the web is full of those discussions. Suffice it to say that in these circumstances, C# and Java are very similar and both languages match each one of your pros and cons. Both would require adapters. Both require loading additional packages. The GDI issue may be solved with the next release of Orbiter, so that may not be a player in the near future. An additional downside of .NET is its not natively supported on Linux, and you need something like Mono to bridge the gap. On the upside is the Orbiter.NET project that Face and Reverend are working on will be providing the needed adapters. This will expand languages to VB.NET, as well as expand the support pool.

I do have to correct Hielor's mention of them being interpreted. C# can be compiled to native code, and Java is compiled at runtime by the Java Virtual Machine (JVM). So outside of that initial loading process for Java, they are similar in speed. Both have been used for 'real-time' apps.

@eveningsky339 - C# dll code can work with Orbiter, but you will have to write some 'glue code' to do it. From your original question, it seems that you may not know either language well (correct me if I'm wrong), so you are deciding whether to learn the "harder" C++ by modifying some simple Orbiter plugins, or learn a "simpler" language and wait for Orbiter.NET to provide the infrastructure. The decision should be based on your final goal, but consider that if you want to do Orbiter plugins, most of the available examples are in C++.
 
I would prefer a HAL/S compiler for orbiter, generating a byte code capable of being parsed by a MFD or plugin... HAL/S is a really cool language for aerospace programming, when used together with the multi-line code feature.
 
I would prefer a HAL/S compiler for orbiter, generating a byte code capable of being parsed by a MFD or plugin... HAL/S is a really cool language for aerospace programming, when used together with the multi-line code feature.
And being a SSU project conspirator has nothing to do with that, right? ;) Then we could all run on x386 machines. . .:)

I've never used it, and its been quite a few years since I've even seen an example of it. Its 'assembly-like', i.e. 'more difficult', so what do you see as advantages to offset that?
 
And being a SSU project conspirator has nothing to do with that, right? ;) Then we could all run on x386 machines. . .:)

Actually, it is made for running on IBM System/4Pi machines - which are compatible to IBM System/360.

I've never used it, and its been quite a few years since I've even seen an example of it. Its 'assembly-like', i.e. 'more difficult', so what do you see as advantages to offset that?

Actually, the language structure is more like Pascal or Modula. The "High-Level Assembly Language" sticker is not accurate.
 
There's Orbiter.NET, but I don't know the status of this project, you should contact Face about that: http://sourceforge.net/projects/orbiterdotnet/

Cheers
Tschachim

Well, we've essentially recreated ShuttlePB in .NET yet. The DeltaGlider is WIP, but almost there. No MFD-related wrappers ATM.

Short introduction in its usage:
It is all based around a mixed-mode wrapper assembly and a so-called launcher. The launcher gets called by Orbiter at vessel-creation, dynamically loads the vessel assembly, and creates a .NET object from a type implementing the wrapped VESSEL2 interface. From that point on, every .NET class or architecture is usable, i.e. you can use inheritance, polymorphism and so on. Orbiter functions can be called either via interface wrappers (VESSEL) or oapi wrappers (OAPI).

There's no black-magic, just simple marshalling all over the place.

Examples for the ShuttlePB for C# and VB are included in the current code base.

regards,
Face
 
That has nothing to do with bigotry. Bigotry is the intolerance to anyone else's ideas that do not conform to your opinion, whether it's informed or not.


bigot (plural bigots)

  1. one who is obstinately or intolerantly devoted to his or her own opinions and prejudices
  2. one who is strongly partial to one's own group, religion, race, or politics and is intolerant of those who differ.

So, do we now want to discuss, who is the bigot in the thread? Or go back to the topic of the language... where I consider Face the better expert on the matter.
 
Or go back to the topic of the language... where I consider Face the better expert on the matter.

Wow. While I actually consider myself an expert regarding .NET development, I'm certainly far away from being the better ;) . Thanks anyway.

As for the point of C#/.NET being superior or inferior to Java or managed development vs. C++ and such... I handle such discussions similar to Linux vs. Windows or VI vs. EMACS: I ignore them.

The reason for Orbiter.NET was just... interest. I'm a professional .NET-developer and I'm familiar with the tool-chain and the language itself. OTOH, I developed C++ application for approx. 6 years, too. Both object-oriented, of course. Both for command-line and UI. IMHO C# is much simpler to develop in than C++, especially if it comes to more complex applications. From my point of view, C# = C++ - pointer-pitfalls + huge component library. And therefore it was interesting for me to have a way to develop something for Orbiter in C#.

You don't have to use something like Orbiter.NET, though. OMP is a good example for it.

Something I wasn't aware of before I tried out .NET development for Orbiter - especially OMP - was the capability of .NET being truly platform-independent. This is something that is absolutely counter-intuitive if you consider .NET being a M$ child. But it is just true... I'm using Mono on the Linux side and .NET on the windows side with the exact same assembly binaries. Well, not the exact same set of assembly binaries (the system libraries coming with Mono and .NET are definitely different), but the application itself stays the same. Not only the source-code but the binary.

As for the performance... I can't really tell a difference between the ShuttlePB and the ShuttlePBdotNET in Orbiter, at least not in speed terms. On the memory side, it has its overhead due to launcher, wrapper and such.
The performance problems with managed systems are more of the psychological kind, I think. I can only tell you that you're much much more seduced to use more memory in C# than in C++, because it is so easy to say "myVar = new BigFatClassWithManyFunctions()", because you don't think about memory management anymore. But using a managed programming system doesn't free you from using your brain.It just frees you from using your brain for boring tasks.

my 2 cents,
Face


-----Post Added-----


Is .NET necessary to translate a .dll written in C#? I have a very limited understanding of programming, but I've always thought that there is no difference between a .dll compiled in C/C++ and C#.

The DLLs in .NET are called assemblies. They are completely different to the original DLLs.
.NET is necessary to run an assembly, not strictly to translate it. Translation is done via C#-compiler from C#-sourcecode to an assembly (more precise: to IntermediateLanguage - just like Java-bytecode). You can also use a VB-compiler to translate VB-sources to an assembly. There was a J# (as in Java) language, too, in the early versions of .NET, but I think they dropped that due to language extensions like generics (similar to C++ templates, but not the same).

The point is: you have to have a .NET framework installed to even run an assembly. Just like you have to have a JVM installed to run java applets.

regards,
Face
 
Back
Top