Talk:cpp/language

Hundreds of references to c++11 and nothing about what it is. why?71.31.147.72 13:56, 16 December 2011 (PST)

interesting point, perhaps there needs to be a cpp/language/history Meanwhile, enwiki:C++11 Cubbi 15:51, 16 December 2011 (PST)

Sections

Splitting the page into sections (like the beginning few links) might be a bit better for consistency's sake. We could also go into a bit more detail about the individual sections and why they're important. For example, we'd have a page on flow control, one on functions, one on types/variables, etc. --- Undeterminant 12:10, 26 February 2012 (PST)

I agree that this page is getting a little long, but I'm not sure that it's an obvious candidate to be broken up into subsections. If there are arguments for making it much longer, I think breaking it into subsections would be useful. For the current length, I wonder if having a table of contents at the top with anchor links to the different sections would help? Nate 13:20, 26 February 2012 (PST)

I'd be a little cautious about the moving the subsections into different pages. This page in its current form serves very well as an index of all language-related content we have. The first few sections are there probably because there wasn't any obvious way to categorize them. Having said that, I think that there are other options. For example, the detailed explanation could live in a separated page. There's one thing to note however. If you want to put general information about flow control or other subject, the regular Wikipedia or Wikibooks might be a better choice. They most probably already have a high quality article on the subject. Why not put a link to their resources instead of trying to invent our own? After all, the wiki systems are almost the same. -P12 16:03, 26 February 2012 (PST)

For going into detailed explanations, should we break down sections more like the standard (Basic Concepts, Standard Conversions, Expressions, Statements, ...) or in a more tutorial format (basic statements, flow control, data types, ...). Doing so would make things easier from an authoring perspective, as the question of: Is a section for this written yet? is easy to answer. On the other hand, breaking down in more of a tutorial format makes it easier on readers. I'm not sure it is a *big deal*, since the standard is not laid out much differently than how I would lay out a tutorial. --tgockel 11:52, 6 March 2012 (MST)

I would love to see this break up into several large-ish pages with multiple links on each. Looking at the Standard for guidance, I think it could be similar, but not quite. Here are the standard's chapters and how I would place them in wiki form

• 3.Basic Concepts -> page of links (type, scope, lifetime, value category, alignment)
• 4.Conversions -> include into Expressions (and keep next to casts, as we do now0
• 5.Expressions -> page of links (operators, conversions)
• 6.Statements -> page of links (if, switch, for, while)
• 7.Declarations -> include into Statements (a declaration is a statement)
• 8.Declarators -> include into Statements (which could be "Statements and Declarations" then)
• 9.Classes -> page of links
• 10.Derived Classes -> include into Classes
• 11.Member access -> include into Classes
• 12.Special member functions -> include into Classes
• 13.Overloading -> not sure, perhaps make Functions (before Classes) and fill it with the function-related stuff from Declarators and with this.
• 14.Templates -> page of links
• 15.Exceptions -> probably deserves a page of links
• 16.Preprocessor -> page of links (which we already have)

That would give us 8 big pages, which could be laid out with little sub-headings just like the Main page. --Cubbi 10:29, 28 February 2013 (PST)

I'm starting to like the idea of breaking this page up into smaller chunks and making this page a "summary" page with fewer details. We use that pattern in other sections on the site, and it seems to work -- so why deviate from it here?

• It does push the envelope of what we cover to include things other than APIs, but as long as there is interest in adding that content and it's language standard stuff, it seems like it's a good fit.
• As far as wikipedia goes, I feel like there's a good case for having cppreference host technical content that would be out of the scope of wikipedia. Let's link to what's on wikipedia when appropriate and add detailed descriptions for stuff that's missing.
• Regardless of whether we want to add subpages, it seems reasonable to leave the content on a single page but reorganize it into the hierarchy proposed by Cubbi. --Nate 18:30, 28 February 2013 (PST)

I really like the Cubbi's prototype. P12 11:51, 5 March 2013 (PST)

Yeah, I do too. I say ship it. -Nate 17:00, 5 March 2013 (PST)

I didn't even finish the first draft! In a few days. --Cubbi 18:34, 5 March 2013 (PST)

I think User:Cubbi/Sandbox/language still needs a lot of work, but it can move in cpp/language now. Everyone okay with that? --Cubbi 08:47, 27 March 2013 (PDT) ... guess it's okay, I'll go for it then. --Cubbi 10:12, 29 March 2013 (PDT)

Looks good! (Sorry about the delay; I've been sick.) --Nate 06:18, 30 March 2013 (PDT)

i can't found discussion page or create it !!

hi guys !

i have a problem in discussion page in Arabic language , my problem is i can't add topic in the discussion page , and i get the following error :

the input is the same in the black page ( i try to translate the error from Arabic) *[^\x00-\x7F].* #Non ascii usernames/articles are not allowed

Hi. I've fixed the problem with discussion pages. -- P12 04:05, 21 April 2012 (PDT)

Declaration or declarations?

I get a feeling that we should use singular for descriptions of declarations. The page lists components of the C++ syntax, so function declaration already encompasses all ways to declare a function. Function declarations, on the other hand, seems to imply that there are at least two entirely different ways to declare a function. Using singular would also be consistent with other usage on the page, for example specifiers, special member functions, operators, etc. -- P12 10:39, 9 May 2012 (PDT)

FWIW, the standard uses plurals: "8.3.5 Functions [dcl.fct]" and "8.4 Function definitions [dcl.fct.def]" --Cubbi 10:51, 9 May 2012 (PDT)

There is also a smallish matter of presentation. It seems (a little) difficult to read a bullet item like:

• function declaration declares a function

...because the words run together. Not a lot, but it looks a little awkward, right? It looked like a lot of the bullets tried to take the form of sentence fragments, like:

• if executes code conditionally

...which seems a little easier to parse. In that vein, these are also a little more sentence-y:

• function declarations declare functions
• a function declaration declares a function

Alternatively, a delimiter might also make this a little clearer:

• function declaration - declare a function

Lots of options...--Nate 12:10, 9 May 2012 (PDT)

Umm, okay. I'm not native English speaker so I can't decide what's better anyway. Maybe the best option is just leave as is. This is insignificant issue, it's probably good idea not waste time on it. -- P12 14:23, 10 May 2012 (PDT)

Info about main() function

it would be nice if one could add some info about how the main() function should look: what parameter types, what return type, and what is standard defined, what is implementation specific... thanks! --87.148.222.140 13:19, 12 January 2013 (PST)

I've added some links for program start/termination. This language section might start to get a bit unwieldy if we keep throwing things into it, however -- it might be worth thinking about high-level organization, or possibly limiting the scope here. --Nate 12:15, 13 January 2013 (PST)

Suggestion

This is more logical:

Default constructor Destructor Copy assignment - Copy constructor Move constructor(C++11) - Move assignment(C++11)

Than the current

Default constructor - Copy constructor Copy assignment - Destructor Move constructor(C++11) - Move assignment(C++11)

agreed and updated --Cubbi (talk) 14:15, 18 November 2014 (PST)

Where is the page for injected-class-name ?

cpp/language/scope mentions injected-class-name, but it doesn't have detailed explanation. --124.166.231.149 21:03, 19 December 2014 (PST)

Zero initialization missing from main page?

How come zero initialization is not listed on main c++ page in the initialization section?

because it is nested under static initialization.. but indeed the list here didn't quite match the navbar layout, updated. --Cubbi (talk) 10:31, 13 August 2015 (PDT)

auto specifier

there is some code

void f1(auto); // use auto in parameters, OK in GCC without any TS options
               // but it seemed to mark a feature of TS on auto specifier page?
void f2(auto...); // use "auto parameter pack" in parameters, also OK in GCC
 
auto lambda = [](auto...){} // also use in lambda and apper in standard example

but I can't find these features on any page of [function declaration, auto specifier, parameter packs, variadic arguments or lambda expressions]

The first two are errors in gcc, unless you omit -pedantic-errors (never omit it) demo. They are valid in Concepts TS (but not yet C++20) so gcc compiles that with -pedantic-errors -fconcepts: demo. The third one is just a C++14 lambda. --Cubbi (talk) 10:17, 22 September 2017 (PDT)

shall use add it into lambda page?Yaossg (talk) 02:50, 23 September 2017 (PDT)

add what, the C++14 generic lambdas? It's there, in "If auto is used as a type of a parameter", in the description of template form of operator() (where you can find "[](auto a) { return a; };"), --Cubbi (talk) 17:11, 24 September 2017 (PDT)

lambda capture

I found this example in standard

int j;
auto x3 = []()->auto&& { return j; }; // OK: return type is int&

it captured nothing! how does it worked? maybe it was a bug of standard doc?if it really was, how can I report it?

Why should it capture anything? demo --Cubbi (talk) 10:17, 22 September 2017 (PDT)

This particular example has been confusing people for a while now, not realizing that the declarations are meant to be namespace-scope. See e.g. this and this T. Canens (talk) 12:10, 22 September 2017 (PDT)

PR for refactoring of the Initialization section

See User:Radix/cpp/language#Initialization section refactoring.

(I had to replace {{rl}} with direct links; that should be changed back on merge.)

ping

Adding current draft to references

Would it be OK to add references to current draft (https://eel.is/c++draft) to "References" sections in addition to references to published standards? If yes, should they be added at the beginning or end? Example of what it might look like for cpp/language/scope:

• Current draft (https://eel.is/c++draft):

• 6.4 Scope [basic.scope]

• C++17 standard (ISO/IEC 14882:2017):

• 6.3 Scope [basic.scope]

• C++14 standard (ISO/IEC 14882:2014):

• 3.3 Scope [basic.scope]

• C++11 standard (ISO/IEC 14882:2011):

• 3.3 Scope [basic.scope]

• C++98 standard (ISO/IEC 14882:1998):

• 3.3 Declarative regions and scopes [basic.scope]

— Radix (talk) 09:46, 3 May 2020 (PDT)

I think it's helpful. However, sections and titles may be unstable and are required to be updated later. --Fruderica (talk) 18:31, 3 May 2020 (PDT)

Move "Lambda expression" under "Expressions"?

Pros:

• A lambda expression is an expression, not a function.
  • The Draft defines lambdas under [expr].
• Rebalances the first and second columns.

Cons:

• Concept of "lambda expression" is very close to concept of "function": readers might want and/or expect to find it there.

— Radix (talk) 22:51, 13 May 2020 (PDT)

I think lambdas naturally group with functions, same as how throw groups with Exceptions. Also, mimicking the standard chapter numbering is not really a benefit, a lot of it is due to language-lawyering and history. Many pages here are composed from breadcrumbs scattered hundreds of standard's pages apart (which in part is why "ref std" is often problematic on core pages) --Cubbi (talk) 07:31, 14 May 2020 (PDT)

Rename "Basic concepts" to something else?

Potentially, "concepts" might get misinterpreted as named sets of requirements. Wouldn't something like "basic notions" ot just "basics" (like in the standard) be better? — Radix (talk) 11:15, 28 November 2020 (PST)

Your concern seems reasonable. I'd vote WF ("Weakly For") changing this subtitle. Another name to be considered could be "Foundations" (?) .) --Space Mission (talk) 13:47, 28 November 2020 (PST)

Template:cpp/language/navbar_content has "General topics" — Radix (talk) 16:10, 28 November 2020 (PST)

"Compound types" links to "class/struct types"

On the popup menu when mouse hovers over the navigation bar "C++/C++ language" at top, there's a item "Compound types" under "Types", which however links to "struct/class types". Don't know how to fix, please help. 62.216.93.144 13:15, 15 March 2022 (PDT)

Huh, that was weird, fixed. --Ybab321 (talk) 15:06, 15 March 2022 (PDT)