Announcement

Collapse
No announcement yet.

Mono Developers Regret Doing Moonlight In C++

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

  • #31
    Originally posted by mrugiero View Post
    In defense of C++, in my short experience, ugly C++ is far nicer than ugly C. At least in ugly C++ you get classes, which usually hint you on what belongs together (which is important when you find projects with colossal dependencies because someone glued together huge amounts of unrelated pieces into single files).
    trust me. This is not true. Sometimes, the apparent purpose of the huge pile of senseless classes seem to be to make the reader insane and confused. Generally, the open-source project code quality is surprisingly very good but as soon as you go in a closed shop, all bets are on regarding the crappiness of the code. From my experience, the bigger the shop is, the crappier the code becomes. My favorite example. IBM source version control client ClearCase is 1GB big! The situation is so bad that they even have to resort to subliminal messages by drawing in blue pale the words 'Speed' and 'effeciency' in the client white background.

    Originally posted by BlackStar View Post
    Hey, but at least you can consume a shared object built with gcc in your clang or icc project. Try doing that with C++ for a laugh.
    Which is IMO an nonissue. In Linux world, you end up recompiling everything at each new release anyway...

    Comment


    • #32
      As an optimization geek and PHP / C/C++ coder....

      It has little to do with the language. Even PHP has a proper compiler (HHVM) these days... (So does Python in PyPy, I'm sure there are more examples)

      The potential for writing lousy code in C++ is huge, but there is also potential to write very efficient code.

      Remember, it's not C vs C++, it's C/C++.

      C++ still has a lot of C in it and noone prevents you from mixing them both.

      The key is to understand what STL (or your libs) does, and either use it or write your own more task-optimized routine.

      Whining and trolling about slow performance in some lib he didn't even write earns Miguel zero points from me.
      Especially when it comes to real time graphics which is really dependent on cache misses / memory management etc.

      When it comes to C#/Java etc:
      To understand a JIT compiler you have to know its innards VERY WELL so you can control it which IMO is a lot harder/obfuscated than understanding a C/C++ compiler where I can read the assembly code fairly easy when the need top optimize arises...
      This would put Mono in a theoretically more benefitial situation unless Microsoft documents their .NET JIT very well (I don't know the state of affairs).

      But in general - JIT doesn't really bring anything in my opinion, just more headaches with random garbage collection runs etc etc which has to be mitigated by elaborate workarounds.

      To conclude:
      Optimized C/C++ code has potential to be fastest unless you really know what you're doing with your JIT compiler.. And the other way around is true too of course if you only know a JIT-based language, but then you should know the JIT-compiler REALLY well before having any kind of right to an opinion.

      Comment


      • #33
        Originally posted by mrugiero View Post
        I think I've got your post backwards, and my guess is it was a translation problem (either from your language to english, or in my reading of english, which is not my main language). When I read "trading dev time", etc, I thought you meant you sacrifice that, not that you gain that, and that you gain ease of use in exchange of that sacrifice, and that's what sounded strange to me, as ease of use is, IMO, related to gaining in dev time, complexity (where gaining is reducing it), etc.

        In defense of C++, in my short experience, ugly C++ is far nicer than ugly C. At least in ugly C++ you get classes, which usually hint you on what belongs together (which is important when you find projects with colossal dependencies because someone glued together huge amounts of unrelated pieces into single files).
        I actually though I understood what he meant by that.

        I would say you can save dev time if the project is huge and complex and you know how to use C++

        Knowing C++ well is of course where most programmers fall through. Its as hard as becoming a world-class magician while fighting dragons in your spare time, and that is probably also why some people like it so much. Its a never ending challenge that has the potential to pay off.

        Personally I haven't kept up with all the patterns and paradigmes that has come about the last decade as I would prefer D or Go (my favourite) in most cases.

        Comment


        • #34
          Originally posted by BlackStar View Post
          Hey, but at least you can consume a shared object built with gcc in your clang or icc project. Try doing that with C++ for a laugh.
          Yes, please try that.

          It works. I use it all the time. Icc implemented gcc's C++ ABI in icc version 8, which is roughly 7 years ago, and clang has always used gcc's C++ ABI.

          FUD off!

          Comment


          • #35
            C/C++

            Problem with C/C++ for me is that many SW projects are so big, it is not REALLY possible to create million+ lines of code is either of these languages, and keep productivity and maintainability. LINUX is exception, but you are unlikely have other projects with hundreds of programmers that not only write code conformant to existing code, but do cleanup, documentation etc., to keep show running. Besides, it is unlikely even possible to write kernel in something else then c/c++, but other projects are not so constrained.

            Keeping track of what was allocated/released where in really big projects is almost impossible task for "normal" company (not IBM). So code is prone to eat all memory and crash, or only crash all of a sudden, which is in c/c++ usually represented as process suddenly dead whith no trace of whatever happened to it.

            In Java program crash usually leaves you really detailed trace of what is going on, so usually it is easy to fix it, even for big code bases = more productivity.

            Problem is, that programming teams change over time, and still you need to handle and improve codebases, c/c++ is not OK with this, me thinks.

            If someone proposed 10 years ago, that we can have all our code, besides kernel, in Java, we would think he is crazy. Now, world is dominated by Android, and everything in Android is written in Java, plus perhaps some c/c++ critical code, usually for 3D graphics. Constantly improving Java/Dalvik JVM also made this possible: with each improvement of JVM/Dalvik performance there are less cases of performance problems comparing to c/c++ and less projects that even need c/c++.

            Remaining big feature of c/c++ is ability to construct/destruct lots of simple objects (structs) at once, simply by declaring portion of memory to be an array of certain type of objects. This is what std::vector is doing, and this is why it is so much faster then Java ArrayList for large arrays - c/c++ doesn't care for initializing individual objects and fields unless you need it, big win for performance critical code (and again big problem for huge code bases -> uninitialized fields).

            Point is: use Java, and only write performance critical code in c/c++ if you really know that your c/c++ code will be actually any faster then Java code, and you are OK that your project will become less maintainable for future coders on that project.
            Last edited by mirza; 04 January 2014, 07:58 PM.

            Comment


            • #36
              Originally posted by lano1106 View Post
              Generally, the open-source project code quality is surprisingly very good but as soon as you go in a closed shop, all bets are on regarding the crappiness of the code. From my experience, the bigger the shop is, the crappier the code becomes.
              I can believe that. The first of the two projects I worked on was open-source, but it was generally done fairly hastily and without much thought into maintainability (the original author never thought anyone would pick up their code, and didn't get any comments from outside). But the second project was closed-source that was later dedicated to the public domain since it got outdated and no longer generated income for the author. And that code was truly horrific...

              Comment


              • #37
                Originally posted by carewolf View Post
                Yes, please try that.

                It works. I use it all the time. Icc implemented gcc's C++ ABI in icc version 8, which is roughly 7 years ago, and clang has always used gcc's C++ ABI.

                FUD off!
                As someone who uses C++ for a living, all I can say to this is *bollocks*. The STL implementations are not ABI-compatible, so your code will crash as soon as you try anything more complicated than "hello world".

                Straight from the clang++ documentation:

                ABI compatibility with gcc's libstdc++ for some low-level features such as exception objects, rtti and memory allocation.
                That's not nearly enough to consume a library compiled with gcc.

                What's more, even different versions of clang are not ABI compatible. From the same page:

                From years of experience (including having implemented the standard library before), we've learned many things about implementing the standard containers which require ABI breakage and fundamental changes to how they are implemented. For example, it is generally accepted that building std::string using the "short string optimization" instead of using Copy On Write (COW) is a superior approach for multicore machines (particularly in C++'0x, which has rvalue references). Breaking ABI compatibility with old versions of the library was determined to be critical to achieving the performance goals of libc++.
                I'm dealing with this shit every day, but you are welcome to try it yourself if you don't believe me.

                Comment


                • #38
                  Code Review

                  Software 101:
                  There is no performance increase to writing a program within C, C++, Object C, or anything except Assembler. Even then you'll need Michael Abrash's skill-level to accomplish that feat. The skill-level is what is important. Using the Drefus model http://en.wikipedia.org/wiki/Dreyfus...ll_acquisition, you seriously can't expect to be an expert in every language. Research into using new languages takes time. C++ has changed throughout the years and it's still changing.

                  My opinion is that they should just stick with C++. If it's a serious thorn in their sides then they need to learn some of the advanced features of the language. Code rewrites are common.

                  As a side note to consider, Microsoft lets you code DirectX applications in C# but their base libraries are written in C++. *hint* *hint* mono developers
                  Last edited by squirrl; 04 January 2014, 08:22 PM.

                  Comment


                  • #39
                    Originally posted by mirza View Post
                    Problem with C/C++ for me is that many SW projects are so big, it is not REALLY possible to create million+ lines of code is either of these languages, and keep productivity and maintainability. LINUX is exception, but you are unlikely have other projects with hundreds of programmers that not only write code conformant to existing code, but do cleanup, documentation etc., to keep show running. Besides, it is unlikely even possible to write kernel in something else then c/c++, but other projects are not so constrained.
                    From the top of Ohloh's list Firefox, MySQL and KDE contain more than 10 million lines of code, is primarily C++, and do pretty well w.r.t. code conformance, clean-up and documentation. I don't really have anything against Java, but I have seen some catastrophes using Java for large scale projects. As for C#/.Net, you may want to revisit the London Stock Exchange ordeal and see where they ended. Android is not about multimillion LOC projects, not yet anyway, so that data point does not seem to support your conclusion. Do you have some successful expamples of large Java-based projects in mind?

                    Comment


                    • #40
                      Originally posted by mirza View Post
                      Point is: use Java, and only write performance critical code in c/c++ if you really know that your c/c++ code will be actually any faster then Java code, and you are OK that your project will become less maintainable for future coders on that project.
                      I have to disagree about Java. It has caused endless hours of grief and it is tied to Oracle who doesn't play well with the open source community.

                      As a language I also think it is too verbose (like C++) and allows bad coding styles.

                      I encourage anyone to watch the talk by Rob Pike called "public static void"

                      Comment

                      Working...
                      X