Talk:cpp/language/value initialization
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{};
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)
- I started implementing this. The lowest-numbered post C++14 DR happened to be against implicit conversions, so cpp/language/implicit_cast is the first page with DRs merged --Cubbi (talk) 12:30, 4 August 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)
- 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)
This case in the syntax seems to be missing?
Class { T member{}; };
Yeah boi (talk) 09:44, 21 October 2020 (PDT)
[edit] Value init really got DR'd?
The DR stuff totally eludes me, but if it's true, then we should probably remove the (C++03) from cpp/language and cpp/language/default_initialization, and I guess remove value init as a "new feature" of C++03 from cpp/language/history. On a separate but related note, I really don't think we should be writing phrases like "since DR 543", that means absolutely nothing to a non lawyer coder and nothing useful for mid-level lawyers like myself; I think the sentence works just fine without it. --Ybab321 (talk) 03:41, 4 November 2021 (PDT)
- I've removed the example regarding CWG DR 543, and moved the note to the Defect Report section. I'm going to check all mentions of C++03 and change the wording to treat value-initialization as a DR against C++98 instead of a new feature of C++03, since (1) it is added by CWG 178, which is in the list of DR issues (2) compilers do not exhibit old behavior in any mode (3) it doesn't makes sense that `int()` has indeterminate value. --D41D8CD98F (talk) 02:00, 7 November 2021 (PST)
[edit] Example appears to have aggregate initialization
In the example "T1" appears to be an aggregate and the usage of "T1 t1{}" then should use aggregate initialization based on how it's described here, the aggregate initialization then appears to state that for mem1 it should copy-initialize from an empty initializer list which has nothing specifying zero initialization. --Reductor (talk) 16:45, 10 June 2023 (PDT)