Announcement

Collapse
No announcement yet.

John Carmack's Comments On C/C++

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

  • #51
    Originally posted by GreatEmerald View Post
    That's why D has an option to turn it off.
    And much of the standard library relies on GC, so what then, roll your own to be sure?

    Comment


    • #52
      Originally posted by joe_gunner View Post
      And much of the standard library relies on GC, so what then, roll your own to be sure?
      Part of the whole "fad" part of 'D'. I should check back into CLAY. From a language perspective that was looking pretty decent. Not just another same old same old object inheritance thing, but an attempt at some orthogonality and simplicity. The biggest strike was missing "const".

      Btw this is a topic about john carmack and c++. How did this turn into a discussion on 'D'? Sometimes I wonder about astroturfing...
      Last edited by bnolsen; 15 January 2013, 04:46 PM.

      Comment


      • #53
        my opinion

        The c++ benefits does not compensate for its technical cost. Then, better stick to C.

        Comment


        • #54
          Originally posted by sylware View Post
          The c++ benefits does not compensate for its technical cost. Then, better stick to C.
          The c++ benefits does not compensate for its technical cost for you. What you wrote is like saying "Don't use competition skis, their benefits do not compensate for the difficulty to handle them". Certainly true for a beginner, certainly false for a competitor.
          I personally would miss exceptions, templates and polymorphism too much.

          Comment


          • #55
            Originally posted by newwen View Post
            As I'm old school (and embedded developer) I still use C. But even with C, my coding rules ban me from using some features of the language. The thing is that C++ has many features that leave a program indecipherable, like operator overloading. Yes, it is a powerful tool, yet it is often misused and makes the code hard to understand.
            Being a C programmer, I've always liked Java for it's simplicity. But then again, Java developers tend to abuse OOP paradignms just for the sake of having beautiful object model design. If I had to ask something to Java is unsafe contexts and an easier JNI, just like C# has them.
            Anyway, If you write C code, you get a better glimpse of what machine code the compiler may generate.
            Just adding a native unsigned 8-bit int type to java would make me happy.

            Comment


            • #56
              Originally posted by bnolsen View Post
              Part of the whole "fad" part of 'D'. I should check back into CLAY. From a language perspective that was looking pretty decent. Not just another same old same old object inheritance thing, but an attempt at some orthogonality and simplicity. The biggest strike was missing "const".
              Have you checked out the Rust programming language by Mozilla (rust-lang.org)? It it a systems programming language with many safety features (no null pointers, const/immutability by default, built on top of the LLVM, no GC if you don't need it, etc.)

              Comment


              • #57
                Originally posted by dnebdal View Post
                Just adding a native unsigned 8-bit int type to java would make me happy.
                So what does "unsigned byte" do then?

                Comment


                • #58
                  Originally posted by Ancurio View Post
                  So what does "unsigned byte" do then?
                  Fail to compile.

                  Comment


                  • #59
                    Originally posted by dnebdal View Post
                    Just adding a native unsigned 8-bit int type to java would make me happy.
                    I don't understand why 'byte' is signed in the first place, but it wouldn't give you much if there was such type. Every integer operation where none of the operands is a long is done in 32bit.
                    so it's byte + byte is converted to int + int and the result is converted back to byte.
                    This means you would use a little bit less space but have a more expensive operation, which is probably the reason 'byte' is signed. so byte2int and int2byte is just adding and removing bits from/to one end.

                    Comment


                    • #60
                      This is why I like D. Compared to C++/C#/Java, D gets a lot of things right.

                      Comment

                      Working...
                      X