2

I've recently come to appreciate the copy-and-swap idiom, and have been using it to implement copy-assignment for any class which manages a resource. So it got me thinking about Standard Library types: does the standard guarantee exception-safe behavior?

For example, consider a class that contains one std::string data member. Ordinarily, I wouldn't have implemented my own copy-assignement, etc., but is this safe? Does the standard guarantee that the std::string data member is left unchanged if the copy-assignment fails? Would it be beneficial to implement copy-and-swap in this case -- or is that just going too far?

Tabber33
  • 535
  • 3
  • 11
  • Given that for all relevant compilers, these are used by thousands of important programs, it would be really embarrassing and critical if these implementations contained such well-known and avoidable flaws... so I'd just assume the stdlib works. –  Nov 19 '10 at 21:26
  • 1
    @delnan: I'd have thought that too, and then I learned how absolutely wretched the Microsoft/Dinkumware implementation of `std::deque` is... – Tabber33 Nov 19 '10 at 21:27
  • @DeadMG: http://stackoverflow.com/questions/4088999/what-the-heque-is-going-on-with-the-memory-overhead-of-stddeque – Mooing Duck Apr 21 '14 at 23:44

2 Answers2

2

The standard specifies explicitely in 'verse' 21.4.1.2. that any other exceptions other than std::bad_length "shall have no effect".

Paul Michalik
  • 4,331
  • 16
  • 18
1

The only reason that copy assignment for std::string would throw is if dynamic allocation failed, in which case you (arguably) are totally screwed anyway. The Standard library is the example of C++ design, and I don't think that they would have overlooked such a thing. I wouldn't go to the trouble of checking Standard types.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • 1
    Arguably indeed. Maybe I'm managing overall heap usage, and I can recover from `std::bad_alloc`. I would want to know if my `std::string` object is in a valid state (e.g., it won't blow up when it goes out of scope). I'm asking if the standard requires it -- you didn't answer my question. – Tabber33 Nov 19 '10 at 21:48
  • @Tabber33: Even in a managed heap, recovering from bad_alloc is a decidedly non-trivial operation. I answered the question - it is going too far. – Puppy Nov 19 '10 at 21:54
  • 1
    I realize the question is pedantic -- so I'll wait for an answer from someone who can appreciate why it's being asked. I'm not debating the merit of handling `bad_alloc` -- it's incidental to the question. – Tabber33 Nov 19 '10 at 22:00
  • @Tabber33: I seriously don't get it. You asked if it was going to far, and I've answered that it is. – Puppy Nov 19 '10 at 22:03
  • 1
    No, you seriously don't get it. I'm asking what the standard says on the matter. Your opinion that it's going too far is duly noted. I like to pretent that there is mission-critical code out there where this would actually need to be considered. It's a valid question. – Tabber33 Nov 19 '10 at 22:06