tag:blogger.com,1999:blog-7101933101966798446.post7434986810485418584..comments2024-03-28T10:33:06.910-07:00Comments on The View from Aristeia: Status Report on Effective C++11/14Scott Meyershttp://www.blogger.com/profile/05280964633768289328noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-7101933101966798446.post-42643771113279847402014-02-18T11:40:05.929-08:002014-02-18T11:40:05.929-08:00@Emmanuel Thivierge: I believe the only functions ...@Emmanuel Thivierge: I believe the only functions that can be implicitly noexcept are destructors and operator deletes. For all other functions, as far as I know, if you want them to be noexcept, you must declare them that way yourself.Scott Meyershttps://www.blogger.com/profile/05280964633768289328noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-35330923410037234582014-02-18T11:26:42.906-08:002014-02-18T11:26:42.906-08:00Unless it is stated somewhere else, I would add th...Unless it is stated somewhere else, I would add the rules under which a defaulted constructor/operator will be noexcept. It is somethings that i don't know for sure myself. And also specify if the rule are different between defaulted and compiler generated.Anonymoushttps://www.blogger.com/profile/12450004892393024951noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-39995650670796168222014-02-06T10:37:22.811-08:002014-02-06T10:37:22.811-08:00@scott: As you say, the rules of noexcept may look...@scott: As you say, the rules of noexcept may look absurd (they do to me), so it's really hard to reason about them. You're asking the reader to make logical deductions from a crazy premise.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-27968911863270204532014-02-05T17:39:55.905-08:002014-02-05T17:39:55.905-08:00@bartoszmilewski.com: Regarding page 5, line 22, t...@bartoszmilewski.com: Regarding page 5, line 22, the context of the discussion is std::vector::push_back in C++11, and that function must perform a move if it can. In that respect, the code is incorrect. Furthermore, I hope it's clear that the broader discussion is about replacing copy operations with moves when that's possible, and any code that performs unconditional copies will fail that test. So I think it's reasonable to describe that code as incorrect. (It would also fail on move-only types.)<br /><br />Regarding the fact compilers don't statically check noexcept declarations, you don't think the text on page 2, lines 1-2, says that pretty clearly?Scott Meyershttps://www.blogger.com/profile/05280964633768289328noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-71572566411803918272014-02-05T16:42:57.804-08:002014-02-05T16:42:57.804-08:00Maybe you should stress more that unlike, for inst...Maybe you should stress more that unlike, for instance, const, noexcept is never checked by the compiler. Just in case somebody thinks that explicit throw is okay but maybe calling other functions that are not marked noexcept would be caught by the compiler? Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-20948201502898065212014-02-05T15:44:12.551-08:002014-02-05T15:44:12.551-08:00"22 As the comment indicates, the code is inc..."22 As the comment indicates, the code is incorrect. The problem is that *src is an<br />23 lvalue, so this statement would unconditionally copy *src to *dest. That’d have<br />24 been fine in C++98, but in C++11, we want to do a move if we can."<br /><br />I think "incorrect" is too strong here. How about "suboptimal"?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-53638883764527314812014-02-05T09:31:50.998-08:002014-02-05T09:31:50.998-08:00@Ralph Tandetzky: Typo fixed, thanks!@Ralph Tandetzky: Typo fixed, thanks!Scott Meyershttps://www.blogger.com/profile/05280964633768289328noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-24428392021192024612014-02-05T09:31:22.306-08:002014-02-05T09:31:22.306-08:00@Anonymous: Thanks for your comments. I'd be g...@Anonymous: Thanks for your comments. I'd be grateful if you could give a couple of examples of how I can tighten up my exposition, because this Item, like many in the current draft, is longer than I'd like. Regarding the stack only possibly being unwound, bear in mind that a violated noexcept means that the program will terminate; there is no way to prevent that. As such, this is not really any different from C++98's behavior when an exception wasn't caught at all. Under those conditions, the program terminated, and there was no guarantee that the stack had been unwound. As regards comparing C++98 and C++11, I should perhaps have mentioned that this Item will be in a chapter called "From C++98 to C++11." It specifically focuses on C++98 practices that need to be revised for C++11, and in that context, I think it makes sense to discuss changes between the language versions. But in accord with your suggestion to tighten up my writing, I'd be interested to hear what information you think could be condensed or omitted.Scott Meyershttps://www.blogger.com/profile/05280964633768289328noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-89800492415025352972014-02-05T07:05:30.320-08:002014-02-05T07:05:30.320-08:00@Scott Meyers: I see you have covered the `std::ve...@Scott Meyers: I see you have covered the `std::vector` case in the item (I somehow missed it yesterday), which is the most interesting example in the standard of how `noexcept` is about semantics and not optimizations.<br /><br />In the end, presenting `noexcept` as helping the compiler generate better code is like presenting move semantics as avoiding copies. Those are some of the effects of using those tools, and sure faster code will appeal to any C++ programmer, those programmers will hopefully know to not bother with that kind of optimization unless measurement supports it.<br /><br />`noexcept` is part of the interface and it's a contract with the world (not just the compiler, certainly more than just a hint). It is a fundamental property of destructors, enough to guarantee breaking changes in the language, and of some basic operations to the point libraries including the standard one will pick or avoid your code based on it.K-ballohttps://www.blogger.com/profile/02351656486838900931noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-17770919217290112582014-02-05T03:37:51.072-08:002014-02-05T03:37:51.072-08:00Found a typo in the reviewable draft: "chuck&...Found a typo in the reviewable draft: "chuck" of memory. It should probably be "chunk". Anonymoushttps://www.blogger.com/profile/13367110760888056708noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-79711574892843348892014-02-05T01:33:20.116-08:002014-02-05T01:33:20.116-08:00My opinion, entirely on stylistic issues.
a) The e...My opinion, entirely on stylistic issues.<br />a) The exposition needs to be tightened considerably, especially if you're limiting yourself to 300 pages.<br />b) That few functions are candidates for noexcept should be more brutally hammered in. For one, no function that uses third-party code (modulo standard library code?) can be safely marked as noexcept.<br />c) That the stack might not be unwound if there's an exception thrown should be shocking to developers since it breaks a major promise of the exception-handling paradigm. Yes, I understand: don't mark your function as noexcept unless you're really sure what you're doing. However, I can't help but feel that when there's a chink (or gash) in a paradigm books like yours should really emphasize the implications.<br />d) I found the comparisons between C++98 and C++11 distracting. (Mr. Sutter tends to do this, too.) It might be deemed as necessary to warn practicing C++ developers that there's a major change, but surely there's an alternative way to underscore that there are alternatives in the language; after all, most (virtually all?) of C++98 features is still with us, even when there are C++11 features that supersede them. I think Mr. Stroustrup has found a way to do this better, maybe because he is teaching intro to programming with C++.<br /><br />By the way, I love your books. I hope this one is the best yet!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-52595302571625216652014-02-05T01:24:35.497-08:002014-02-05T01:24:35.497-08:00@Scott Meyers: Interesting -- learn something new ...@Scott Meyers: Interesting -- learn something new every day :)<br /><br />I'm surprised that the committee made this change -- it changes the behavior of unmodified C++03 code.Billy O'Nealhttps://www.blogger.com/profile/13423715036990970308noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-35014645290312542552014-02-04T22:04:25.311-08:002014-02-04T22:04:25.311-08:00@Billy O'Neal: Destructors are noexcept by def...@Billy O'Neal: Destructors are noexcept by default. In concept, I should address that in this Item, but that would require spending more time on noexcept expressions, which I'd prefer not to do. I'll have to see what I can do about this, because your point is certainly valid.Scott Meyershttps://www.blogger.com/profile/05280964633768289328noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-57251635714388893532014-02-04T21:30:58.611-08:002014-02-04T21:30:58.611-08:00I would also add that you want to mark destructors...I would also add that you want to mark destructors noexcept. Throwing exceptions in destructors is almost always bad (so you can mark almost all of them noexcept). Even in cases where there is some fatal behavior that can occur in a destructor, often the guaranteed program termination characteristic of marking the destructor noexcept is superior to the potential program termination that occurs if the exception occurs during stack unwinding. (The stack unwinding behavior can appear nondeterministic)Billy O'Nealhttps://www.blogger.com/profile/13423715036990970308noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-56853346214257404762014-02-04T20:33:27.492-08:002014-02-04T20:33:27.492-08:00@K-ballo: Other than uses related to std::move_if_...@K-ballo: Other than uses related to std::move_if_noexcept (which is discussed in the draft Item) and std::swap (also discussed in the Item), do you know of examples where libraries query the noexcept status of a function?Scott Meyershttps://www.blogger.com/profile/05280964633768289328noreply@blogger.comtag:blogger.com,1999:blog-7101933101966798446.post-62751964780591738552014-02-04T19:43:56.626-08:002014-02-04T19:43:56.626-08:00"Why? Because it permits compilers to generat..."Why? Because it permits compilers to generate better code." Not only that, but since it's part of the API and it can be queried, it permits libraries to take different approaches based on the `noexcept` guarantee. An example of this is `std::vector`, which will not move unless the operation is noexcept. Also related, `std::move_if_noexcept`.K-ballohttps://www.blogger.com/profile/02351656486838900931noreply@blogger.com