Announcement

Collapse
No announcement yet.

Mir Now Depends Upon C++14

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

  • #21
    Originally posted by JS987 View Post
    Smart pointers are necessary to avoid leaks, crashes, some security bugs when application becomes complex.
    Define "complex" for me?

    Comment


    • #22
      Originally posted by gamerk2 View Post
      Define "complex" for me?
      Over 200,000 lines of code, more than ten years of history and more than a hundred contributors, most of whom are not around any longer.

      Anything else is simple.

      If you can call what you're doing your 'current' project, it's too small to be complex.

      If "specializing your allocator classes" is the first thing you usually do, you're not working on a complex project.

      Comment


      • #23
        Originally posted by Kemosabe View Post
        I never use smart pointers. It's against my definition of clean and elegant coding.
        Am i a dummy now?
        yes.
        .
        .

        Comment


        • #24
          implementation language is the best feature of mir

          Comment


          • #25
            Originally posted by Kemosabe View Post
            I never use smart pointers. It's against my definition of clean and elegant coding.
            Am i a dummy now?
            I'll give you an answer from my experience with Objective-C, a language where all objects are reference counted and allocated on the heap. Because of having one way to treat objects, things are more straightforward, than let's say C++. That has also allowed for standard rules to be defined that, when adhered, guarantee code robustness and no memory leaks. It also made possible for clever compiler optimizations to emerge like the recent ARC (automatic reference counting).

            My point is that using smart pointers by default result in less headaches better productivity and more robust code.
            Last edited by zoomblab; 24 February 2015, 03:57 AM.

            Comment


            • #26
              Originally posted by zoomblab View Post
              I'll give you an answer from my experience with Objective-C, a language where all objects are reference counted and allocated on the heap. Because of having one way to treat objects, things are more straightforward, than let's say C++. That has also allowed for standard rules to be defined that, when adhered, guarantee code robustness and no memory leaks. It also made possible for clever compiler optimizations to emerge like the recent ARC (automatic reference counting).

              My point is that using smart pointers by default result in less headaches better productivity and more robust code.
              I agree, as well as minimizing the use of pointers. They are vastly overused in most code bases: they introduce memory leaks (unless reference counted), threading problems and break the cache. Sometimes you have to use pointers - they are extremely powerful as we all know - and that's fine. Just don't do it as a default.

              Comment


              • #27
                Originally posted by Azpegath View Post
                I agree, as well as minimizing the use of pointers. They are vastly overused in most code bases: they introduce memory leaks (unless reference counted), threading problems and break the cache. Sometimes you have to use pointers - they are extremely powerful as we all know - and that's fine. Just don't do it as a default.
                My rule (that I find clearer) is that a raw pointer means "this one" and never means "I own this"[1].

                That means e.g. iterating by pointer is fine; but that anything that needs to be deleted/freed/[whatever]ed is needs to be owned.

                [1] An exception obviously exists for code whose sole purpose is ownership (like std::unique_ptr<>) but that should rarely be part of user code.

                A second exception (but only when GC is used) is anything guaranteed to (transitively) only own memory.

                Comment

                Working...
                X