Mono 2.11 Release Brings Many Changes

[russofris]

Mono is a disease, it should be eliminated.

All computer languages are a disease. We just like to nitpick and fight about it and defend whatever shitty programming language was first to pop our intellectual cherry. It's as if we're arguing about which spoken language is better (even though all of those are turds as well).

Since Java was the first language to really wet my dick, I am bound by my ostensibly earthbound imagination to argue that it's the finest slice of pie in the sky.

I could fill up pages with why Java is so grERROR: java.lang.OutOfMemoryError: Java heap space
at java.lang.String.concat(String.java:2001)
at java.lang.String.isArrogant(String.java:160)
at java.lang.String.discussionHasNoPoint(String.java: 500)
at java.lang.String.itsAllDogma(String.java:2001)

[Ansla]

Even though I have roughly double the experience of C++ than C#, I find I can outperform C++ code with C# roughly 80% of the time, given a similar amount of effort. How can this be? The reason is that C# is a much easier language to develop with, so I can finish the implementation faster and dedicate time to optimization. With C++, just implementing the required features can be challenging enough, that optimization does not even enter the picture.

Are you referring to GUI programming with MFC? I can't think of any other use case where C++ could be that bad.

Consider how easy asynchronous programming or task-based parallelism is in C#. C++ is a with the gargantuan pain in the ass in comparison - so much, that your average Linux programmer still writes serial, synchronous code in 2012!

True, lack of threading support at the language level does make it slightly more difficult then in other languages, but C++ never lacked good threading libraries, and now it has one as part of the standard library. The problem is that your average Linux programmer writes in C, not C++.

[ciplogic]

Are you referring to GUI programming with MFC? I can't think of any other use case where C++ could be that bad.

The answer is in weighting his words: "Even though I have roughly double the experience of C++ than C#, I find I can outperform C++ code with C# roughly 80% of the time, given a similar amount of effort." And he explains right after why: "The reason is that C# is a much easier language to develop with, so I can finish the implementation faster and dedicate time to optimization. "

[BlackStar]

So change it to use a non-static code if C# doesn't like it, the problem will still be there. Java passes parameters "as value", but what it actually passes as value is a reference, so you can make changes to the object using either of the references. As far as I know C# does the same thing, and I'm not aware of any way to pass the actual data as value in either of the languages, though my knowledge of VM based languages is limited so please correct if I'm wrong and you can replicate what the following C++ function does:

struct Message {
    std::string text;
};

void PrintMessage(Message msg) {
    std::cout << msg.text << std::endl;
}

Whatever the caller does, if msg.text contains "Hi" when the function is called that's what will appear on the screen. Unless the function itself changes msg.text, but that's no side effect, if a programmer did that and didn't expect the result it's time to look for another profession, no language can be that idiot proof.

struct Message {
    public string Text;
}

void PrintMessage(Message msg) {
    Console.WriteLine(msg.Text);
}

This is identical to the C++ version. The msg parameter in PrintMessage is pass-by-value, and Message is a struct (aka value type) which gets copied on the stack when passed as a parameter - exactly like the C++ version. Additionally, C# strings are immutable, which means they cannot be modified after creation. This code will always print "Hi", as expected:

volatile var msg = new Message { Text = "Hi" };
PrintMessage(msg);
var troll = new Thread(() => msg.Text = "Trolled");
troll.Start();

struct Message { public string Text; }
void PrintMessage(Message msg) { Thread.Sleep(5000); Console.WriteLine(msg.Text); }

However, do any of the following changes and it will print "Trolled":

class Message { public string Text; } // classes are reference types, like Java

or

void PrintMessage(ref Message msg) { ... } // use pass-by-reference
unsafe void PrintMessage(Message* msg) { ... } // use pass-by-value with pointer

The main differences between C++ and C# parameter-passing semantics is that C# classes are reference types by default (so no "slicing" issues to take care of) and that C# lacks pass-by-const-reference (which hurts its math performance significantly). Everything else is there, and this is a pretty significant advantage of C# over Java.

[Ansla]

The answer is in weighting his words: "Even though I have roughly double the experience of C++ than C#, I find I can outperform C++ code with C# roughly 80% of the time, given a similar amount of effort." And he explains right after why: "The reason is that C# is a much easier language to develop with, so I can finish the implementation faster and dedicate time to optimization. "

What he didn't say is why it takes so long to implement in C++.

[ciplogic]

What he didn't say is why it takes so long to implement in C++.

I think he did, but I can say to you my experience.

If you mean C++ itself, compared with C#, C# have by default more services (like to read fast an xml or file content on disk), is more concise (you don't have to write twice header and cpp the same declaration), and have a code completion that (99%) works.
As C# is faster to parse/compile, this makes possible that MonoDevelop (or Visual Studio with CodeRush, JustCode or Resharper - my favorite) to give warnings that the code does not compile way before you did hit the Run key. Most of these cases, in C++ you would have to compile everything. The language is more forgiving too: if you use the "add collection operator" like:

var list = new List<int> { 1,2,3,};

it will not complain that you forget a comma in the "3," (it is good for generated code, as there should not be extra logic for the very last item, when you would generate a list like this). This also combines well with partial classes. (if you want to have generated code).

To start a project in C# world most of the time you reference the assemblies and you're good to go (or JAR in Java world). In C++ you mostly do: set directory of headers, set sometimes defines, set linker errors and you're eventually good to go. But you don't know before linking if you have done everything right. QtCreator/QMake may help a little (this is Qt, not C++ in itself), but working for a medium sized application, C++ is harder to work with overall.

As for me, where C++ "shines" is when you do very tight loops, picking the GCC option: -ftree-vectorize, when you want to use bit-fields, like: int a:12; sometimes it has a low-overhead auto-ptr template, but excluding that, I barely see any pattern where C++ is more productive than C#.

With all these features in place, I think you can save 20-30% of time that you may invest in optimizing the code, and if nothing works, to make that 20% in C/C++, export it with C interfaces and using it from C#. But in this case the person had 80% a better overall development experience, and it would need just 20% of code (most likely it would be much less) to get "dirty" with C++.

[Ansla]

So you say using C# with an IDE is easier then using C++ without one, but both Kdevelop/QtCreator are great IDEs that can be used for non-QT development as well, and also from what I saw recent versions of VisualStudio also started getting quite usable, though I never used it for C++.

[ciplogic]

So you say using C# with an IDE is easier then using C++ without one, but both Kdevelop/QtCreator are great IDEs that can be used for non-QT development as well, and also from what I saw recent versions of VisualStudio also started getting quite usable, though I never used it for C++.

C++ and an IDE (even with a plugin like WholeTomato) is overall a slower experience to develop than C#/Visual Studio, Java/IntelliJ IDea or Eclipse or NetBeans, Ruby (with almost any IDE).

[crazycheese]

I think that KDE may not need Mono (I think that Qt is a close replacement, QObject + Moc + QML is fantastic in my opinion), but Gnome's platform is not so fortunate. Vala helps a little, but as a streamlined workflow, Monodevelop + Gtk# + C# is in my opinion (after maybe Python) the best way to develop on Gtk+. People shunning Mono, shuns an option for developers that they may really use.

WHY IS WINDOWS NOT USING GTK???!! GO MAKE GTK INTEGRAL PART OF WINDOWS! THE GPL (NOT LGPL!) VERSION! So that Steve will opensource whole windows!!! Because you are precisely trying to sabotage GTK with moNO! in same way!

This is really fun how you throw unrelated technical crap like FIREFOX caches, incomplete unsupported patent-troll unstable monodevelop and VS.
VS overweights everyone 3x, and this is true mono size. 2x of JAVA. Ok, go ahead and polish moNO till it shines, just as java already. More choice? Of what - shiny boobytrap??!

And keep your mono crap outside of GNOME and GTK !!!!!!! You ARE a windows developer with windows takeover attitude!! , GO DEVELOP ON WINDOWS FORUM and take your dirt with your THANKS!!!

[BlackStar]

What he didn't say is why it takes so long to implement in C++.

Ciplogic covered this better than I could myself.
- GC by default, manual memory management only if necessary
- Proper ABI (modularization)
- Better standard library (XML, sockets, globalization, timers, threads, processes, math)
- More expressive syntax (linq, lambdas, generic constraints, enumerators, delegates, interfaces, strong enums)
- Less undefined behavior (e.g. primitive sizes, sign expansion, mod with negative numbers)
- Faster compilation times, shorter debugging cycles
- Reflection and runtime code generation

On its own, each feature might not be too impressive, but add them together and they make a very tangible difference. I would say that I can write C# code 30-50% faster than C++, on average.

Boost tries to solve some of these problems and bring some form of sanity to the language - if you are ok with adding 500MB worth of dependencies to your project. C++1x is much better, but still fails to fix the core issue of C++: its insane compilation system ("write everything twice", "recompile templates on every use", "each compiler has its own ABI, so you can't use .so files - unless you write everything three times", "each platform has different conventions, exact behavior is undefined, have fun".)

What all this amounts to, is that if I can finish my C# project 30% faster than C++, then I can use this extra time to identify and optimize the real bottlenecks (I/O, core algorithms.) The language is rarely the performance bottleneck nowadays. Disk accesses, high-level logic and data layout is where the real optimization potential lies.