5 ms·

The link you have is also old - most of the issues reported there are not valid anymore with C++11. BTW, at least for Windows 8 now Microsoft recommends you to

• deleted 14y ago
  [deleted]
  • CCs 14y ago
    Yes, they fixed many things - and that's good. The alternative is to create a new programming language every year, just to discover it breaks down somewhere else (ask Twitter about Ruby). Memory management is needed for C, but not for C++ or ObjectiveC. I worked years on large C++ systems (>300 developers) without using "new" or "delete". Whenever I develop in Scala or other GC language, I still miss the deterministic destructors. For memory it is OK to be freed anytime, but there are other resources (GPU, file, TCP port) that you still have to manage manually and it needs to be freed right away. It's trivial to write in C++, but I never saw a failsafe C# implementation.
    • fusiongyro 14y ago
      Can you expand on using C++ without "new" or "delete"? I'm curious. I'm learning C++11 now and I'm having trouble seeing how you could do that.
      • yannickt 14y ago
        If you use smart pointers in your code (std::unique_ptr, std::shared_ptr), you will rarely have to call delete. A unique_ptr for example owns an object through a pointer; the pointer is automatically deleted when the unique_ptr goes out of scope. shared_ptr retains shared ownership through reference counting; the pointer is deleted when the reference count reaches zero.
        • fusiongyro 14y ago
          So, in your code you would never write this: class Foo { ... private: Bar *myBar; Baz *myBaz; }; You would instead always do something like this: class Foo { ... private: shared_ptr<Bar> myBar; unique_ptr<Baz> myBaz; }; Is that right?
          • blt 14y ago
            Yes.
          • yannickt 14y ago
            Using your example let's assume myBar and myBaz are _owned_ by Foo. Before C++11 you would typically do this: class Foo { public: Foo() : myBar(0), myBaz(0) { myBar = new Bar; myBaz = new Baz; } ~Foo { if (myBar) delete myBar; if (myBaz) delete myBaz; } private: Bar *myBar; Baz *myBaz; }; In C++11, the above could be written like this: class Foo { public: Foo() : myBar(new Bar), myBaz(new Baz) { } private: std::unique_ptr<Bar> myBar; std::unique_ptr<Baz> myBaz; }; You don't need to call delete because the unique_ptr destructor will do it for you. You would only need to use shared_ptr when ownership is shared among multiple objects. A shared_ptr holds a reference counter that is incremented every time it is copied, and decremented every time it is destroyed or re-assigned. When the reference counter reaches zero, the pointer is automatically deleted.
            • tyree732 14y ago
              And once they get around to adding std::make_unique (or you add it to your codebase yourself), you won't even need new there either.
            • SamReidHughes 14y ago
              Pre C++11 you would use a scoped_ptr in that scenario. And for the record, the conditionals in that destructor are redundant, deleting a null pointer does nothing.
          • 14y ago
      • ryanmolden 14y ago
        In addition to what is talked about below, using value semantics (with mutable or immutable objects) can be helpful. Lots of types can be given value semantics and end up more efficient (most people think copying == less efficient, always) due to the lack of pointers and the locality destroying/cache unfriendliness they introduce. In my experience if you see new/delete in C++ code you should be immediately questioning who owns that object, how it is shared and how/when it is destroyed. I can't even count the number of times I have seen one object new up something and then share a raw pointer with N other objects, who then either have to coordinate who calls delete or, the creator itself does so, and you may have use-after-free issues. unique_ptr and shared_ptr, or their moral equivalents, help avoid most of these issues. As a bonus shared_ptr enables weak_ptr, which can also be very handy for non-owning users and breaking cycles in object graphs.
    • betterunix 14y ago
      C++ "smart" pointers do not free you from thinking about memory management; the fact that you are expected to choose between shared_ptr and weak_ptr should be enough to tell you that. Unlike languages with a garbage collector, C++ requires programmers to spend their time trying to figure out if they will create a cyclic data structure, and then also to figure out where that cycle should be broken. That is moderately better than having to figure out when it is OK to free memory and when it is necessary to free memory, but only moderately. Let's put it this way: if you were writing a doubly-linked list, where would you put the shared_ptr, and where would you put the weak_ptr (or would you just give up, use "dumb" pointers, and have destructors free memory)?
      • userulluipeste 14y ago
        It's not necessarily about "smart" pointers. It can be just the use of stack - for all objects.
• betterunix 14y ago
  C++11 introduces new problems. Programmers are expected to know how a lexical closure should capture variables from the enclosing scope -- should it be by reference, or by value? Programmers are also expected to know that when they capture by reference, sometimes they are really supposed to capture by value but with smart pointers (and of course, they are expected to know which kind of smart pointer they need). Instead of fixing the double exception fault, C++11 just punts on the issue and says that no exceptions are ever allowed to propagate out of a destructor (which is another way of saying, "destructors must never signal errors, even for things that are correctable like running out of disk space). That Microsoft would recommend JavaScript or C++ is unsurprising, considering how much business those languages have generated for them and how many programmers who support the Windows ecosystem are only comfortable in one of those two languages.