Namespaces
Variants
Actions

Talk:c/language

From cppreference.com

Contents

[edit] Sections

I read the Discussion for http://en.cppreference.com/w/cpp/language, studied Cubbie's edit of March, 2013, and followed the evolution from prototype to current version. I would like to implement a similar table of contents for http://en.cppreference.com/w/c/language so that the C version has an appearance similar to the C++ table of contents. Newatthis (talk) 07:28, 6 June 2014 (PDT)

C definitely needs attention, I would recommend starting with a sandbox version (as I did). Don't try to copy C++, even the parts that look similar may be fundamentally different in detail (type declarations, the meaning of cvr-qualifiers, even the syntax of if/then and while loops) --Cubbi (talk) 08:33, 6 June 2014 (PDT)
I understand that C is not C++. To start and to avoid "contamination," I intend to learn the table structure used in the C++ version but use the topics and links that already exist in the C version of this page. But first, I need to find something to read about the sandbox. Newatthis (talk) 08:59, 6 June 2014 (PDT)
I developed a sandbox version (first draft). Newatthis (talk) 05:42, 8 June 2014 (PDT)

[edit] Presenting C

How exactly would you like to see the C language presented here? I understand from earlier feedback that you do not want a tutorial, granularity, nor looking too much like C++. On the FAQ I read, "a complete online reference" and "a good specification of C" but not "things that are implicitly clear to an experienced programmer." Also I found, "we try to keep things simple and clear for a programmer looking for reference of a feature he already knows." Which begs the question, if a programmer already knows a feature, why would she/he read cppreference? Could you offer a little elaboration on your thinking about presentation? Perhaps then I can proceed along a suitable path. Newatthis (talk) 04:16, 18 October 2014 (PDT)

I think that looking like C++ layout-wise is okay (although I'm not happy with some things there, like accessibility of the built-in operators), it's the C++-centric topics that would make it look amateurish to a serious C programmer. As for why programmers use cppreference, knowing something doesn't mean being an expert: there are details, common gotchas, recent changes, interactions with other parts of the language. It just means not needing a tutorial. Someone familiar with ADL at my work was surprised by the cancellation effect of members, went to cppreference and didn't see that mentioned because it was lost in the flow of the text (I made that part more visible in response to that feedback). Someone else at work (a committee member, even), very familiar with operator new, forgot that it can't be replaced in a namespace, and it was faster to enter operator new in the cppreference search bar and Ctrl-F cpp/memory/new/operator_new for "namespace" than open up the standard at 3.7.4.1[basic.stc.dynamic.allocation]. A lot of people familiar with the library functions come to see what side effects happen (invalidations, allocations, thread safety) when they call the function, or what limitations does it have. Many people come to see what changed in recent standard revisions in the language features they know well. Do you use references in your daily work? Do others around you? Listen to their feedback. --Cubbi (talk) 09:14, 18 October 2014 (PDT)
Many thanks. You have shared much for me to think about. I shall combine these thoughts with your feedback about the my first draft of a TOC which I offered on my sandbox page. Predicting that someone may forget a detail, like not replacing new in a namespace, sounds like a guessing game; drawing a line between inclusion and exclusion of a detail will vary with the skill level and memory abilities of the writer. One contributor may think that nobody will forget whatever, while another may recall forgetting that detail and decide to include. I had hoped for a path with a little more determinism. I must press the pause button and think some more about how to make a contribution. Newatthis (talk) 07:42, 20 October 2014 (PDT)

[edit] string literals

I am studying the recently contributed TOC for core C language features. The Standard gives to string literals its own clause 6.4.5. Clause 6.4.4 Constants does not include string literals. The TOC seems to imply that string literals are a form of constants. Should "string literals" not be indented in the TOC? Newatthis (talk) 06:24, 25 December 2014 (PST)

they are indeed a form of constants. I've updated the naming to reflect that. --Cubbi (talk) 09:39, 25 December 2014 (PST)

[edit] do while

This entry currently links to the C++ page - wip. Newatthis (talk) 13:49, 17 January 2015 (PST)

now links to C --Cubbi (talk) 14:47, 17 January 2015 (PST)

[edit] Initialization, Functions

Why put these two topics in separate sections? In the C Standard, both topics appear in sub-clause "Declarations?" Newatthis (talk) 04:18, 28 January 2015 (PST)

because this wiki attempts to be a language reference rather than an inferior knock-off of an ISO document. Navigation and grouping here serves different purposes (it is loosely based on operational semantics, while the layout of the standard is dictated by the formal grammar) --Cubbi (talk) 07:36, 26 June 2015 (PDT)

[edit] signal handling

What is the thinking behind having the entry "signal handling" on this language page? Isn't signal handling a part of the library, as in signal.h? Newatthis (talk) 04:14, 26 June 2015 (PDT)

it's a major, yet specific topic in C programming, a kind of thing perfectly suitable for language/Miscellaneous category. The library facilities that support it are indeed already described under c/program#Signals (although a significant chunk of signal() belongs here as it briefly describes the interaction of the C abstract machine with async signal handlers). This will also mention how signals interact with syscalls, and other practical aspects. --Cubbi (talk) 07:36, 26 June 2015 (PDT)