4 ms·
> If compilers were to unpredictably remove copies, and thus remove pairs of copy/move constructor & destructor calls, they might break your code. But they are
by MaxBarraclough 6y ago
> If compilers were to unpredictably remove copies, and thus remove pairs of copy/move constructor & destructor calls, they might break your code.
But they are permitted to do exactly this. This is one of the unusual things about copy-elision in C++. The standard says that under certain circumstances, the compiler is permitted (but not required) to elide a copy operation even if this causes a change in observable program behaviour.
* https://en.wikipedia.org/wiki/Copy_elision https://en.wikipedia.org/wiki/Copy_elision
* https://en.cppreference.com/w/cpp/language/copy_elision https://en.cppreference.com/w/cpp/language/copy_elision (the article referenced by the post)
- ncmncm 6y agoThey are permitted in certain cases, not in others. It is proposed to widen the former list for C++23. All this is an argument for "rule of zero": write your classes in a way that the default copy and move constructors and destructor do the right thing. That gives the compiler latitude to do the right thing in places that it otherwise could not. Some code obliged to do extra work will be able to do less of it when compiled with a compiler that knows C++23, provided you have followed rule of zero.
- pjmlp 6y agoThis is the kind of nuances that make it increasingly hard to look at C++ code and be sure of its semantics, without diving into compiler flags and standardese.
- MaxBarraclough 6y agoNot to mention the paywalled C++ standards documents. People say A few hundred dollars is nothing to a professional software engineer, but few C++ developers actually buy it, so the legalese they consult is often not the letter of the law but a proxy like cplusplus.com, replete with the occasional error.
- pjmlp 6y agoThere are the drafts, but even if final standards were available for free, this kind of knowledge is too fine grained to keep all in head across language revisions. I bet many ISO committee members aren't able to answer "what are the semantics of this code" with looking into the standard. And there lies the problem, it is not possible as contractor jumping into a foreign code base to be certain of everything that is going on there. Now imagine the task of upgrading a codebase to a newer compiler and language version, while assuring everything keeps working the same way.
- ncmncm 6y agoNo one is obliged to pay "a few hundred dollars" to see the text of ISO 14882. The Final Draft International Standard online is guaranteed to differ from the formal Standard only on the title page. But cppreference.com is generally easier to understand.
- MaxBarraclough 6y ago> "a few hundred dollars" Care to explain the scare quotes? ISO charge 198CHF, [0] which is $210 USD. ANSI charge $250. [1] > The Final Draft International Standard online is guaranteed to differ from the formal Standard only on the title page. Do you have a source for that? From what I can tell the differences are expected to be minor, but that's as far as the guarantee goes. If what you say is true, why would anyone ever both paying for the completed document, and why would ISO expect to derive profit from paywalling it? > cppreference.com is generally easier to understand Sure, I'm not saying it's a worthless website, far from it, but errors can and do creep in. [0] https://www.iso.org/standard/79358.html https://www.iso.org/standard/79358.html [1] https://webstore.ansi.org/Standards/ISO/ISOIEC148822020 https://webstore.ansi.org/Standards/ISO/ISOIEC148822020
- ncmncm 6y ago> Care to explain the scare quotes? Because nobody not contractually obligated needs to pay it. Some entities allow themselves to be so obligated, but you are not obliged to mimic them. > ...why would ISO expect to derive profit from paywalling it? ISO is an old organization. For paying it, as with the "Dine and Dance" sign on the hotdog stand, you can if you want to. > From what I can tell the differences are expected to be minor, but that's as far as the guarantee goes. That is as far as ISO goes. But SC22/WG21 goes the rest of the way. ISO has no authority to change the text from the FDIS in any way that affects the agreed-upon meaning of the text. In practice this means no changes at all. SC22/WG21 is not obliged to publish its FDIS, but is allowed to. It does; not all WGs do. Cplusplus.com is, unfortunately, garbage. All we can do about that is say so. While cppreference.com is not guaranteed to be precisely accurate, you are overwhelmingly less likely to misunderstand it than the Standard, so you come out well ahead. Anywhere it and the Standard differ, your compiler is likely to differ, too.
- partiallattice 6y agoOne tough thing about rule of zero classes is that many to most end up having an implicit 'the object has not been moved from' precondition on methods. The classic example is a class with a unique_ptr member that is never null except after move, so none of the methods have null checks. I understand why the committee was unable to get destructive moves into the standard, but I do think that is one thing Rust got right that I really wish C++ had.
- MaxBarraclough 6y agoAgree. Can't really blame C++ for it being difficult to retrofit something like that. It's akin to the lack of const in Java: they'd add it if it were practical to do so.
- tragomaskhalos 6y agoPeople bang on about borrow checking etc but really it's move semantics that's the million dollar idea in Rust - it just obliterates a huge Gordian knot of complexity in one stroke
- ncmncm 6y agoIn Rust you cannot write a move constructor. That proves limiting. But Rust move construction, also, cannot fail, which is liberating. Rust cannot abandon backward compatibility with itself, so will increasingly be stuck with old choices, like C++, and will soon be fully as complex and infuriating. But it will, like C++, remain usually more useful than alternatives.