Namespaces
Variants
Views
Actions

Talk:cpp/language/value initialization

From cppreference.com

The "T object{};" syntax is not guaranteed to give value initialization: if T has an initializer-list constructor but no default constructor, it will be list-initialized.

Edited, thank you for pointing that out. --Cubbi 03:31, 26 July 2013 (PDT)

"In all cases, if the empty pair of braces {} is used and T is an aggregate type that is not a class type with a default constructor (until C++14), aggregate-initialization is performed instead of value-initialization." Surely "an aggregate type that is not a class type with a default constructor" must be an array? To have no default constructor (not even a deleted one), T would need a user-defined constructor and therefore would not be aggregate type...? --124.168.32.191 02:33, 24 December 2014 (PST)

The example in CWG 1324 (which changed this wording after C++11) is:
struct B {
   B(const B&) = default;
};
B b{};
--Cubbi (talk) 06:57, 24 December 2014 (PST)

The page suggests that if empty braces are used on an aggregate class with a default constructor, then in C++11, the result is value-initialization. I think that is no longer true since 1301 was accepted into DR...? Surely the modified C++11 wording means that, even in C++11, empty braces on an aggregate type always cause aggregate-initialization? gubbins (talk) 04:59, 16 June 2015 (PDT)

This is a general cppreference issue: should DRs be documented under the prior standard revision (which is how gcc and clang treat them), or should they be documented under the next standard revision (which is how ISO treats them, someone on StackOverflow called this approach "--unreasonably-pedantic"). The practice so far, more or less, has been that DRs that fix errors that no compiler could ever implement (typos, self-contradictions, impossibilities) are applied to the text that shows up under the previous standard's tag, while the DRs that change the behavior of a fully compliant compiler, like CWG 1301 here, are applied under the next standard's tag. I find it useful to be able to look at a reference and see what I can expect of a compiler that says "C++11" on it (and in this case, there are two perfectly valid behaviors, depending on when the compiler was released). Perhaps it makes sense to merge all DRs into previous standard tags (this page would sure become simpler!) in the main text of all cppreference pages, and document all behavior-changing DRs in the Notes section. --Cubbi (talk) 06:21, 16 June 2015 (PDT)
I agree with your last suggestion. I think that on this site, "C++11" should mean "the behaviour you expect from an up-to-date release of a fully compliant compiler when you run it in C++11 mode", which means applying all DRs (unless you work for ISO!). I think that's the most useful and most natural interpretation - I come here to find out what gcc should do with --std=c++11 turned on, and if gcc does something else, then I see whether newer gcc builds have fixed the problem. Older compiler releases may behave differently if they pre-date a DR, just as they may behave differently if they pre-date a bug fix or pre-date the full implementation of part of the standard.
We could even have a dedicated section called "Standardisation changes" or similar, which appears only on pages requiring it, and documents behaviour-changing DRs? I think the info might get a bit lost in Notes. gubbins (talk) 16:09, 16 June 2015 (PDT)
I was thinking to start with Notes, since a few pages already did something like that, e.g. std::regex_traits::isctype, although I don't think any sane implementor would've followed the pre-DR rule in that case, that one doesn't need to be highlighted), but thinking further, I agree that Notes are not technically the right place for normative specs (Notes are for usage, rationales, implementation details, alternatives, and other stuff not in the standard). The new section could use some sort of compact table-like representation (as compact as the invalidation rules at std::vector), with, say, three columns: DR number (CWG1301, linking to cwg-defects.html), standard revision it modified (C++11), one-liner description. Don't need to be detailed, since it's by definition outdated info; interested readers can follow the link. Also, "Standardization changes" is a little vague, why not just "Defect reports"? It would be good to know what User:Nate or User:P12 think, too. --Cubbi (talk) 19:13, 16 June 2015 (PDT)
"Defect reports" is good. My only reservation is that some readers will not understand exactly what that means. Is it possible to link to some page briefly explaining, or have a template insert a few simple words like "Defect Reports are changes to the standard after it was published; this section lists Defect Reports that modified the behaviour described on this page" or something? gubbins (talk) 21:21, 16 June 2015 (PDT)