Question C#?

[spectre]

can you use C# for addon development or is it strictly C++?

 

[Lucy]

The answer is no, I'm afraid. Orbiter addons use .dll modules which are written in C++ exclusively.

The good news, however, is that if you understand and know C#, using and learning C++ is much easier than starting out from scratch, though you may have to break yourself of a few C# habits. The fundamentals of programming, however, remain the same, and since the languages share a common root, going from one to the other is somewhat easier.

 

[Hielor]

Yes--the OMP client is written in C#. However, I think it would be important for you to consider what exactly you're wanting to do in C# that you can't do in C++...

 

[Zatnikitelman]

Speaking as someone who went from C# to C++ with no formal training between the two (learned C# in college, taught myself C++ over the summer) C++ is fairly easy to learn from knowing C#.
But as Hielor said, not everything has to be a .dll Orbiter plugin. I was working on a mission control application in C# which communicated with Orbiter using Orb:Connect over a network. You can also write calculators, utilities (Orbiter Mesh Wizard was written in Visual Basic IIRC) etc. without C++.

 

[spectre]

what about MFD development?

 

[Hielor]

what about MFD development?

I'll be more specific this time.

The Orbiter API is specifically targetted toward C++. In order to write a plugin of any kind (vessel, MFD, generic plugin) and communicate directly with the API, you need to be using C++.

That said, you can write your own interop layer (as Face did for OMP) in order to talk to the API from C#. However, this adds a significant amount of complexity, and you gain nothing at all (other than reduced performance and reduced ability to debug your code, which aren't gains by any stretch of the imagination).

The next version of Orbiter includes LUA scripting support, which might be something you should look into if you're refusing to learn C++ for some reason or another, but C++ is a whole lot closer to C# than LUA is.

 

[Face]

can you use C# for addon development or is it strictly C++?

Take a look at this. It is an attempt on creating a general Orbiter-API for C#. ATM it contains a working ShuttlePB example.

In my experience, the common preconception of C# being slower or being harder to debug is wrong. I observed no slow-down or debugger-troubles while working on the API layer.

The layer itself indeed adds complexity, but only initially. Once the layer is established, the development gains are robust memory managment, even better debugging (due to reflection) and better module management. These are just some of the reasons why .NET was developed first place (and no - it is not an evil M$ plot to rule the world ).

regards,
Face

 

[Urwumpe]

and no - it is not an evil M$ plot to rule the world

Its hard to disclose the evil plots of a Daeva.

 

[Moach]

from what i've read on the matter, c# is roughly twice slower than c++... which is, indeed, amazing for any interpreted language...

yet, c# has a number of disadvantages that IMO exceeds the advantages it offers...

it is, in fact easier to learn than c++... if you have experience with flash and actionscript 3, you'll get the hang of c# with very little effort...
on the other hand, using it for anything other than things specifically made with it is a hassle larger than it's worth...

as a language, also, i find it lacking in many handy features available to c++, such as preprocessor, headers, and independence of classes and the files they're defined in...

pointers also may seem like a headache at first, but it's very nice to have that level of control....


the main reason i found c++ hard to learn is that there aren't many comprehensive tutorials on it... most seem to assume you're coming from a C background, rather than a simpler language, such as C#
so i'd suggest for any who are about to take on learning C++ to start looking into C... not only for the historic reasons, but c++ will be easier to understand afterwards

cheerz

 

[Urwumpe]

C# is not really interpreted, it is byte-code and about as slow or fast as Java. I think it is even a bit faster than Java for some applications.

also the features you list of C++, are its big advantage to be such low level, but that fires back if you plan to do high-level applications with C++, because you have the added complexity (unless you use a framework that implements the high level features).

Still...IMHO there is no better programming language yet than C++, simply out of the fact that it is more a high-level assembler than a real high-level programming language, like Java, C# or Ada. There is no trick that you can't teach C++ and IMHO it is not at the end of its evolution...it could learn many new big tricks.

 

[Enjo]

C# is not really interpreted, it is byte-code and about as slow or fast as Java. I think it is even a bit faster than Java for some applications.

I noticed this too while porting a huge C# program to Java. Don't ask me to tell you how big headache this porting project was

 

[Urwumpe]

I noticed this too while porting a huge C# program to Java. Don't ask me to tell you how big headache this porting project was

Just as coarse estimate: Did you need the UCGO box of Aspirin? :thumbup:

 

[Enjo]

Nah, I don't use medicine when I don't have to, but my shoulders were so stiff from coding that I sure could use a Thai massage ... ehm that's not what Thai massages are about, right? Well, I'd need one anyway

 

[orb]

from what i've read on the matter, c# is roughly twice slower than c++... which is, indeed, amazing for any interpreted language...

If you mean the byte-code as the result of compiling C# is the interpreted part, it's true, but like Urwumpe said C# itself isn't interpreted.

But it's a bit more complicated than only the C# layer and the byte-code layer as a result. Between C# and the byte-code there is CIL, like between C++ and the machine-code there is assembly. C# is simply a high-level language for CIL.


AFAIK, C++ can be also used for writing a managed code (.NET, Mono), like what C# is used for, but there are some constraints if it's used for it. I've never tried it, and I don't know if it produces byte-code in that case.

 

[Urwumpe]

Nah, I don't use medicine when I don't have to, but my shoulders were so stiff from coding that I sure could use a Thai massage ... ehm that's not what Thai massages are about, right? Well, I'd need one anyway

No, Thai massages are for dereferencing your pointer, stupid. :lol:

 

[Face]

as a language, also, i find it lacking in many handy features available to c++, such as preprocessor, headers, and independence of classes and the files they're defined in...

TBH, I don't count preprocessor and headers as advantage in C++. Those are more like excuses for bad design, especially regarding OOP. In this regard, I find .NET to be better designed than C++.

OTOH, C is a nice language and - like Urwumpe said for C++ - more like a high-level assembler.

Regarding the "interpreted language" statement: C# (like every other .NET language) is first compiled to MSIL (Microsoft Intermediate Language). This byte-code is then compiled to machine instructions via JIT (just-in-time) compiler. So in the end you have compiled code like with C++, just with a different framework.
This is also the reason why something like mixed-mode code is possible, merging managed and unmanaged code in one assembly.

regards,
Face

 

[Urwumpe]

TBH, I don't count preprocessor and headers as advantage in C++. Those are more like excuses for bad design, especially regarding OOP. In this regard, I find .NET to be better designed than C++.

I think the only error is calling the stuff preprocessor... many other languages have similar constructs, but included in the first compiler pass without special label for it. "#pragma" is not really a preprocessor instruction and a very powerful feature... especially with OpenMP.

I am sure, .NET also has such functions somewhere, if not, it is really a loss, conditional compilation is a great great great feature. AFAIR, annotations like in Java are not able to replicate the ability.

 

[orb]

Regarding the "interpreted language" statement: C# (like every other .NET language) is first compiled to MSIL (Microsoft Intermediate Language).

It was renamed to CIL (I mentioned in my previous post) some time ago:
[ame="http://en.wikipedia.org/wiki/Common_Intermediate_Language"]Common Intermediate Language - Wikipedia, the free encyclopedia[/ame]

 

[Face]

I think the only error is calling the stuff preprocessor... many other languages have similar constructs, but included in the first compiler pass without special label for it. "#pragma" is not really a preprocessor instruction and a very powerful feature... especially with OpenMP.

I am sure, .NET also has such functions somewhere, if not, it is really a loss, conditional compilation is a great great great feature. AFAIR, annotations like in Java are not able to replicate the ability.

You are right, .NET has conditional compilation and #pragma. What I normally understand with preprocessor is a system preprocessing the source code to extend or manipulate the code. I guess what I was talking about was actually macro preprocessing, something even Stroustrup frowned upon.

It was renamed to CIL (I mentioned in my previous post) some time ago:
Common Intermediate Language - Wikipedia, the free encyclopedia

Thanks for the hint, I think I've put myself in the "long-standing users of the .NET languages" category, then .

regards,
Face

 

[Urwumpe]

You are right, .NET has conditional compilation and #pragma. What I normally understand with preprocessor is a system preprocessing the source code to extend or manipulate the code. I guess what I was talking about was actually macro preprocessing, something even Stroustrup frowned upon.

yeah... it is a two bladed sword. If you do much cross-compilation, it can save you a lot of work, since you can literally let the compiler rewrite the program to switch program codes as needed - including the ability to manipulate identifiers.

But it is also so deep from the primordial soup of software development, that people are quickly confused by it.