Namespaces
Variants
Views
Actions

Talk:cpp/language

From cppreference.com

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)

Contents

[edit] 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)

[edit] 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)

[edit] 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:
...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:
Alternatively, a delimiter might also make this a little clearer:
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)

[edit] 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)