Fun With C++ [Beginners Stay Away, Lest Ye Be Corrupted]
Quote:Original post by Nitage
While it's interesting that it can be done, I agree with Harb Sutter that it shouldn't be done.
That is true of many details of C++.
Language lawyers can legally inject code into a class that uses templates. They can abuse the lack of strict type checking to legally expose details that are meant to be ignored. They can legally abuse macros, legally abuse the many forms of new, and legally abuse just about any other feature you can imagine.
Write to be understood.
If the process is best understood using simple constructs, write it simply. If the process is best understood by a language-lawyer technique, then use it, but acknowledge that few people will understand the nuance and that it likely will become a source of bugs.
Quote:Original post by NitageAs do I.
While it's interesting that it can be done, I agree with Herb Sutter that it shouldn't be done.
I don't believe any good ever comes from using the object rebirth techinque.
"Here be dragons." indeed!
With all due respect to those raising legitimate issues, I think you're missing the point. The title was "Fun with C++", not "Sober production code in C++".
Fun thread. Good intentions; bad results. This is why I both love and hate C++ sometimes. I can appreciate the subtlety and creativity of attempting a solution like this, along with the understanding that the known caveats make this generally not worth it. However, I know plenty of people who would look at this, say, "GOOD IDEA!" even with the caveats listed and down the rabbit hole we go. Later, there will be this witch hunt for, "why does this mysteriously not work anymore? Why can't Microsoft make a compiler that generates good code??? etc etc.." [grin]
Quote:Original post by Nitage
It allows a reasonable copy constructor/assignment operator to be defined for classes with const member variables (and reference member variables).
An assigment operator for classes with const members? Isn't that actually a violation of const correctness?
As with most things in C++, everything is useful sometimes.
I believe boost::variant is implemented using this technique, and I would be extremely surprised if other parts of boost WEREN'T. I'm not saying you should go out and use it all over the place, or even anywhere at all for that matter. But there's always a use case.
I believe boost::variant is implemented using this technique, and I would be extremely surprised if other parts of boost WEREN'T. I'm not saying you should go out and use it all over the place, or even anywhere at all for that matter. But there's always a use case.
Quote:Original post by cache_hitNope, a quick google tells me:
As with most things in C++, everything is useful sometimes.
I believe boost::variant is implemented using this technique, and I would be extremely surprised if other parts of boost WEREN'T. I'm not saying you should go out and use it all over the place, or even anywhere at all for that matter. But there's always a use case.
Quote:All members of variant satisfy the strong guarantee of exception-safety.which means it can't possibly use what I'd call the object rebirth technique. It would almost certainly use the copy and swap idiom.
Frankly I'd be very surprised if any parts of boost used it.
Oh and I understand perfectly well that this thread had to word "fun" in the title. Just bear in mind that what some people consider fun, others simply cringe at.
Quote:Original post by iMalcQuote:Original post by cache_hitNope, a quick google tells me:
As with most things in C++, everything is useful sometimes.
I believe boost::variant is implemented using this technique, and I would be extremely surprised if other parts of boost WEREN'T. I'm not saying you should go out and use it all over the place, or even anywhere at all for that matter. But there's always a use case.Quote:All members of variant satisfy the strong guarantee of exception-safety.which means it can't possibly use what I'd call the object rebirth technique. It would almost certainly use the copy and swap idiom.
Frankly I'd be very surprised if any parts of boost used it.
Oh and I understand perfectly well that this thread had to word "fun" in the title. Just bear in mind that what some people consider fun, others simply cringe at.
Yes, but the way boost::variant implements the strong guarantee is by using a backing store of memory allocated on the heap. Besides, there's certainly ways to augment the above code to provide the strong guarantee. Just saying that they use the technique doesn't mean they use those exact 2 lines of code with no try/catch wrappers and error handling in case of exceptions.
This comes from the documentation of boost::variant.
Quote:
Since variant manages its content on the stack, the left-hand side of the assignment (i.e., v1) must destroy its content so as to permit in-place copy-construction of the content of the right-hand side (i.e., v2). In the end, whereas v1 began with content of type T, it ends with content of type U, namely a copy of the content of v2.
The crux of the problem, then, is this: in the event that copy-construction of the content of v2 fails, how can v1 maintain its "never-empty" guarantee? By the time copy-construction from v2 is attempted, v1 has already destroyed its content!
Read on to learn the solution to the problem. I haven't actually looked at the source code, but it sure sounds to me like they're doing this. Definitely in the case where both sides of the assignment contain the same type, and highly similar in the case where they aren't.
Edit: Got confused with various types of "guarantees". Boost.variant actually does not provide the strong guarantee on assignment from what I can tell
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
