Announcement

Collapse
No announcement yet.

Mono Developers Regret Doing Moonlight In C++

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

  • #71
    Originally posted by AnonymousCoward View Post
    With JIT cache startup times would be history but oracle focuses more on the server side and there it does not matter.
    I doubt they would add this feature anytime soon, if ever.
    That's something that should be always there, I don't know how it didn't came from day zero. What's the point on compiling everytime you run the program?
    Does it at least profile the program so you can get better optimization everytime?

    Originally posted by AnonymousCoward View Post
    prefer vectors over arrays
    While I do agree in most cases, I think for fixed size arrays, a C array is better. Why? Because most of the extra features a vector provides has no real use, and the C array uses less memory and probably incurs in slightly less overhead. For all other uses, yeah, stick to vectors, or the equivalent of the project you are working on (some projects in C++ use custom containers instead of the STL, SCUMMVM for example; they do provide a substitute for vectors).

    Comment


    • #72
      Originally posted by Apopas View Post
      It sucks nevertheless.
      True.

      WTF, man the guy is confusing RAII with RTTI I think...
      s/RAII/RTTI

      My point is still valid: RTTI is a piss-poor substitute for proper reflection.

      Comment


      • #73
        Originally posted by mrugiero View Post
        While I do agree in most cases, I think for fixed size arrays, a C array is better. Why? Because most of the extra features a vector provides has no real use, and the C array uses less memory and probably incurs in slightly less overhead.
        However, with C arrays you need to store a length parameter explicitly and pass it around in function arguments. So the memory angle does not hold in practice, plus you incur the burden of maintaining the length manually.

        Comment


        • #74
          Have you seen their code base?

          I did it and what I found is horrible. Here my analysis:

          Recently Miguel de Icaza revealed in his blog the fact that they regret the decision to develop Moonlight in C++, you can read about it in h...


          his regret has to be read like this:

          "We regret to have chosen C++ without having a deep knowledge of it and without any best practice to follow".

          Comment


          • #75
            Originally posted by AnonymousCoward View Post
            It's obvious that the C++ haters use C++ like a glorified C (or never even used it properly), well guess what it isn't! If you use C strings and arrays or pointers in C++ (unless absolutely neccessary, which should be almost never) then you are doing it WRONG.

            In C++:
            prefer vectors over arrays
            string over c strings
            references over pointers
            exceptions over error return codes
            classes over structs
            And the point I made earlier. There's no set of "best practices" for c++ that people agree on.

            std::vector<> is mostly fine but std::array<> is a simple way to make sure your iterative recursive algorithm keeps its storage on the stack.

            std::string over cstring, generally agree although I think std::string's api is lame and archaic, not matching the other std:: collection apis and is a total mismatch with utf8.

            exceptions? a big gun to shoot yourself with and a way to make your code hard to trace due to call stack blowing. Too many folks treat normal bad data as exceptional. Our nicest compromise has been to have isValid() checks on important state stuff, allowing computations to go on even with bad data to be checked when convenient.

            In some rare cases passing by pointer instead of by reference can make the code easier to understand at the caller. It's a weakness of c++ not knowing if a function parameter is pass by ref or pass by const ref.

            pure classes are almost always overkill, over encapsulation requiring too much boilerplate accessors. We find that allowing direct access to some data members, then checking current state with isValid() to be reasonable, reducing a bunch of boilerplate.

            the absolute biggest gain we've seen with c++ has been const correctness and making things as immutable as possible. Frankly I don't see how its possible to do safe thread coding any other way. Yes that's what I mostly do, highly threaded computational workloads, 64+ core stuff, linux and windows (although windows still doesn't seem to be as stable as linux).

            Comment


            • #76
              Best Practices

              Well actually there are a set of C++ best practices. You just have to know where to look.
              Of course all best practices are contingent on the agreement of the majority.

              Some books, 2 by Bjarne Stroustrup originator of the language
              Programming Principles Practice using C++
              Coding Standards Rules Guidelines Practices
              C++ Programming Language 4th Edition

              Miguel de Icaza proably wants to express how easier it is to just write everything in C#. But even C# has best practices and hidden caveots. If the MONO team is having a hard time with C++ I can only imagine their ordeal with C#.

              It's been said before that those guys farted to try and get Microsoft to take a whif. Unfortunately nobody over at the Redmond campus cares about GNU/Linux other than what Google is selling. They're currently engagued in damage control over Windows RT/8.1 and how to hook customers on Server 2012. Let's not forget SharePoint ladies!

              Besides, if you're developing C# solutions under Linux you're probably doing so from within Virtualbox, Vmware, or KMS.

              Smoke a kipper or something.

              Comment


              • #77
                Originally posted by kalman View Post
                Here my analysis:

                Recently Miguel de Icaza revealed in his blog the fact that they regret the decision to develop Moonlight in C++, you can read about it in h...


                his regret has to be read like this:

                "We regret to have chosen C++ without having a deep knowledge of it and without any best practice to follow".
                Read your blog post: spot on mate!

                Comment


                • #78
                  Originally posted by bnolsen View Post
                  the absolute biggest gain we've seen with c++ has been const correctness and making things as immutable as possible. Frankly I don't see how its possible to do safe thread coding any other way. Yes that's what I mostly do, highly threaded computational workloads, 64+ core stuff, linux and windows (although windows still doesn't seem to be as stable as linux).
                  That's one point where D is strongly pushing for. It's even safer there, with the immutable variable keyword (not only does it guarantee full immutability, but it even allows the compiler to optimise things since it knows it's not going to change in any way ever), pure functions (that guarantee that they will not change any global variables or use other functions that do that) etc.

                  Comment


                  • #79
                    Originally posted by mrugiero View Post
                    JDownloader was pretty responsive, AFAIR. Its only problem was the time it took to start, but after that, it was snappy enough.
                    then you should run it on low end hardware. is sluggish and slow and often unresponsive as hell. jdownloader is a great example for the VERY slow java gui rendering. just look at the cpu usage.
                    I am kind of a Java hater (although, contrary to most haters, I acknowledge I am and that it is irrational; I don't make futile attemps to make it look like there are real reasons to discard a language independently of the context),
                    i'm no java hater. until a few years i didn't acutally cared much about it now i'm coding professionally with it. though java has (from an informatics point of view) some very bad design fails. though these are issues 99% of the programmers either wont encounter or simply won't miss as they never made the experience how you could do things right if java would allow it.

                    for me personally the most annoying thing is how the java designers actually made one of the basic and most importants datastructzures of informatics more or less useless: lists.
                    and not enough, the fact that the list interface also includes access by index makes it practice nearly impossible to know and rely on some performance assumptions.

                    it is funny to see how much work has been put into various VMs just to compensate for the lack of this.

                    also, i'm often missing polimorfic heritence and real generics (i.e. suppoting primitive types).

                    there is really a lot broken by design in java that won't ever be fixed without totally braking compatibility.
                    when ever i run into such a design flaw i think the designer just were some experienced coders but none had a clue about informatics.

                    during my science time many of mates used java but they all had to code their own version of the standard datastructures just because with the javas way you fail to implement a lot of algorithms efficiently. now since i am now working in the reseatch and dev of big enterprise i already had to do this myself. and it is damn annoying not to be able to use primitive types with generics when doing so.

                    Comment


                    • #80
                      Originally posted by GreatEmerald View Post
                      That's one point where D is strongly pushing for. It's even safer there, with the immutable variable keyword (not only does it guarantee full immutability, but it even allows the compiler to optimise things since it knows it's not going to change in any way ever), pure functions (that guarantee that they will not change any global variables or use other functions that do that) etc.
                      GCC has supported pure functions since version 2.96. But I really would like to have a really-const keyword, yeah.

                      Comment

                      Working...
                      X