Page 8 of 9 FirstFirst ... 6789 LastLast
Results 71 to 80 of 84

Thread: Mono 2.11 Release Brings Many Changes

  1. #71
    Join Date
    Jan 2012
    Posts
    729

    Default

    Mono is a disease, it should be eliminated.

  2. #72
    Join Date
    Jan 2009
    Posts
    394

    Default

    Quote Originally Posted by asdx View Post
    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)

  3. #73
    Join Date
    Oct 2010
    Posts
    258

    Default

    Quote Originally Posted by BlackStar View Post
    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.

    Quote Originally Posted by BlackStar View Post
    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++.

  4. #74
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    286

    Default

    Quote Originally Posted by Ansla View Post
    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. "

  5. #75
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,045

    Default

    Quote Originally Posted by Ansla View Post
    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:

    Code:
    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.
    Code:
    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:

    Code:
    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":
    Code:
    class Message { public string Text; } // classes are reference types, like Java
    or
    Code:
    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.

  6. #76
    Join Date
    Oct 2010
    Posts
    258

    Default

    Quote Originally Posted by ciplogic View Post
    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++.

  7. #77
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    286

    Default

    Quote Originally Posted by Ansla View Post
    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:
    Code:
    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++.
    Last edited by ciplogic; 03-30-2012 at 04:39 AM.

  8. #78
    Join Date
    Oct 2010
    Posts
    258

    Default

    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++.

  9. #79
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    286

    Default

    Quote Originally Posted by Ansla View Post
    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).

  10. #80
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by ciplogic View Post
    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!!!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •