Announcement

Collapse
No announcement yet.

Mono 2.11 Release Brings Many Changes

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #76
    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, 05:39 AM.

    Comment


    • #77
      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++.

      Comment


      • #78
        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).

        Comment


        • #79
          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!!!

          Comment


          • #80
            Originally posted by Ansla View Post
            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.

            Comment


            • #81
              Originally posted by BlackStar View Post
              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.
              Where did you come up with that? Do you mean the debug symbols? I don't think you can really call those dependencies. Otherwise, boost 1.46 on AMD64 is a whooping 6.4MB dependency, 13MB if you count both mt and non-mt versions. Compare this with ~100MB for mono or a lot more for Microsoft's .net

              Code:
              du -shc /usr/lib/libboost_*mt-1_46.so.1.46.1
              88K     /usr/lib/libboost_date_time-mt-1_46.so.1.46.1
              140K    /usr/lib/libboost_filesystem-mt-1_46.so.1.46.1
              364K    /usr/lib/libboost_graph-mt-1_46.so.1.46.1
              112K    /usr/lib/libboost_iostreams-mt-1_46.so.1.46.1
              112K    /usr/lib/libboost_math_c99-mt-1_46.so.1.46.1
              112K    /usr/lib/libboost_math_c99f-mt-1_46.so.1.46.1
              112K    /usr/lib/libboost_math_c99l-mt-1_46.so.1.46.1
              224K    /usr/lib/libboost_math_tr1-mt-1_46.so.1.46.1
              252K    /usr/lib/libboost_math_tr1f-mt-1_46.so.1.46.1
              224K    /usr/lib/libboost_math_tr1l-mt-1_46.so.1.46.1
              72K     /usr/lib/libboost_prg_exec_monitor-mt-1_46.so.1.46.1
              460K    /usr/lib/libboost_program_options-mt-1_46.so.1.46.1
              16K     /usr/lib/libboost_random-mt-1_46.so.1.46.1
              949K    /usr/lib/libboost_regex-mt-1_46.so.1.46.1
              477K    /usr/lib/libboost_serialization-mt-1_46.so.1.46.1
              88K     /usr/lib/libboost_signals-mt-1_46.so.1.46.1
              16K     /usr/lib/libboost_system-mt-1_46.so.1.46.1
              116K    /usr/lib/libboost_thread-mt-1_46.so.1.46.1
              805K    /usr/lib/libboost_unit_test_framework-mt-1_46.so.1.46.1
              1.4M    /usr/lib/libboost_wave-mt-1_46.so.1.46.1
              344K    /usr/lib/libboost_wserialization-mt-1_46.so.1.46.1
              6.4M    total
              I can give you that C# allows for somewhat faster development for small projects, but don't try to claim it requires less resources, be it CPU, RAM or disk space. That's just ridiculous.

              Originally posted by BlackStar View Post
              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".)
              I'm not sure I understand what you mean by writing everything twice or 3 times, or where the compiler ABI comes into play. At least gcc did not break it's C++ ABI since version 3.4 that was released in 2004.

              P.S.
              Originally posted by BlackStar View Post
              - GC by default, manual memory management only if necessary
              By manual memory management you mean mixing managed and unmanaged code? Because when you start doing that about all the "sanity" of C# vanishes. And I have yet to see a large C# project that does not require unmanaged code.
              Last edited by Ansla; 03-30-2012, 09:50 AM.

              Comment


              • #82
                Originally posted by Ansla View Post
                And I have yet to see a large C# project that does not require unmanaged code.
                Just to see, I think you just need to look just a little.
                SharpDevelop, its compressed source is 37MB (37224 KB). Check here and download the source of version 4.2. It has support from Syntax Highlighter, to code analysis, to multi-language IDE, and so on. MonoDevelop is the same.
                Pinta is just 1.5 MB compressed source (and are not so many pictures inside it), and as I know the source code, I don't know any native code inside it.

                In Java, the list is huge too (if us about unamanaged), and as C# is very close to Java, at least on matter of language semantics, shows that can be done with C# (at least as matter of possibility). As for Java big systems, Eclipse, Idea and NetBeans come to mind, but are a lot other, but they are more server-side.

                Mono class libraries are mostly written in C# (I don't know if are fully written in it), so applications don't need to write the same logic twice, so their logic can be smaller (hence, their binary can be smaller too), at the end providing a richer experience than some other same-sized native language platforms.
                Last edited by ciplogic; 03-30-2012, 10:11 AM.

                Comment


                • #83
                  Originally posted by Ansla View Post
                  By manual memory management you mean mixing managed and unmanaged code?
                  He means: Pointer arithmetic. You can do it using unsafe code (which is a "free to shot yourself" set of C#). Also he may mean IDisposable, where you can write your code to free predictable your code by having:
                  Code:
                  using (var instance = new MyType()) { 
                  } //guaranteed to be called instance.Dispose() that you may override

                  Comment

                  Working...
                  X