Talk:C (programming language)/Archive 10

Archive 5

←

Archive 8

Archive 9

Archive 10

Archive 11

Archive 12

→

Archive 15

POV-based comments regarding object-orientation

The C language doesn't provide built-in support for object-oriented code (nor in fact for several interesting features), though those can be constructed. There are well-known examples of class-structures in C, e.g., X Window System. It would be nice to reduce the persistent intrusion of POV-based edits in this area. Tedickey (talk) 20:06, 11 December 2008 (UTC)

I did not edit any of the article in regard to this area, but I don't agree with you. The current version of the article says: Very limited support for object-oriented programming with regard to polymorphism and inheritance. There is no built-in support at all, I would prefer a sentence like: No built-in support for object-oriented programming. This would be more accurate IMHO. It's the same for generic programming. With C you can do anything you want (C is a very powerful general purpose low-level language), but as C is intentionally "close to the metal", you doin't have much help for any high level constructs such as Object Oriented Programming, Generics, Closures, Garbage Collection, etc... It does not mean that you can not develop frameworks in C to support these features. Hervegirod (talk) 12:51, 17 January 2009 (UTC)

open standard

It is kind of curious to see C# in the open standard article, but not C.

Is there a reason for that ?

If not, could someone who knows a bit about the subject add it there ?

Current C standards apparently don't meet the criteria. Generally, you have to buy a copy, and that's cheaper for some national-body versions than for others. I don't know whether the next C standard (C1x) will qualify as an "open standard." — DAGwyn (talk) 17:58, 6 May 2009 (UTC)

Image copyright problem with File:Kr c prog lang.jpg

The image File:Kr c prog lang.jpg is used in this article under a claim of fair use, but it does not have an adequate explanation for why it meets the requirements for such images when used here. In particular, for each page the image is used on, it must have an explanation linking to that page which explains why it needs to be used on that page. Please check

• That there is a non-free use rationale on the image's description page for the use in this article.
• That this article is linked to from the image description page.

This is an automated notice by FairuseBot. For assistance on the image use policy, see Wikipedia:Media copyright questions. --13:49, 8 February 2009 (UTC)

Pointer alignment

Regarding my addition reverted in rev. 274795659, is not the reference to the WG14 year 2005 draft of the C standard sufficient to substantiate my re-phrasing of the actual paragraph 7 of section 6.3.2.3? --ilgiz (talk) 23:55, 3 March 2009 (UTC)

• The editor who reverted seemed to think that your description was not faithful to the standard.

It is difficult for me to understand your paragraph; you say that the C standard requires such-and-such, but it is not clear whom it requires it of. Is it something a C implementation must make sure happens, or something a programmer must construct his program to conform to? It's not easy to tell from your text, unless one already knows what you're trying to say.

Also, it is not clear to me that the issue is one that ought to be discussed in this article at all. It is not my any measure a central property of the C programming language how it deals with unaligned pointer casts. Language lawyers and professional programmers who care about the theoretical limits of portability need to know these things, but they need to know many more details than a general encyclopedia article can reasonably provide anyway. Everyone else will probably go "huh?" no matter how well this is explained. –Henning Makholm (talk) 01:06, 4 March 2009 (UTC)

• I read your comment as a concern that it is up to the C compiler implementation to go into necessary details of targeted CPUs. But I think the standard had to be adjusted so that it would apply universally. You may already know that some CPUs require word access to occur by an aligned boundary and that the compilers targeted to such CPUs provide ways to adjust the code to the CPU specifics. For example, armcc offers the following measures:

1. stack variable alignment on a boundary of multiple of 8,
2. the __packed qualifier that would make the compiler access adjacent words and combine them into a result,
3. the __align(n) keyword that forces alignment on a multiple of "n".

I think that following the pointer alignment restriction I found in the C standard draft would allow to write portable code. For example, to make the anti-example portable,

char *external_buffer = "abcdef";
uint32_t *internal_data;

internal_data = (uint32_t *)external_buffer;  // UNDEFINED BEHAVIOUR if "the resulting pointer is not correctly aligned"
// Also, *internal_data results in different values on big- and little-endian CPUs.

I would write:

char *external_buffer = "abcdef";

// Apparently, it goes without saying that automatic and static variables are guaranteed to be correctly aligned
uint32_t internal_data1;
uint32_t *internal_data = &internal_data1;

// Alternatively, section 7.20.3 "Memory management functions" guarantees that malloc() returns an address of a super-aligned block
// uint32_t *internal_data = malloc(sizeof(uint32_t)); 

// assuming the network order of the external data and that the protocol stipulates a 4-byte field in the beginning
*internal_data = (((((uint32_t)(external_buffer[0]) << 8) | external_buffer[1]) << 8) | external_buffer[2]) << 8) | external_buffer[3];

It is good that the article can be an educational material. I do not mind if it also presents minor details reflected in the C standard. --ilgiz (talk) 16:12, 4 March 2009 (UTC)

• I think there are several misconceptions in the above. The C standard does not currently include any specific object-alignment aids, and implementations are always required to align the standard types so that they work (which is one reason structs can have internal padding).

It is certainly true that a few target-specific applications need some additional form of alignment control, for example aligning DMA buffers with memory cache lines; in such cases, compilers for those targets virtually always provide nonstandard extensions to do the job.

Alignment of word pointers on sub-word boundaries cannot be supported on many platforms without a high run-time cost for using that facility, and since it is rarely useful (only for picking fields out of a packed record image, which may also have endian issues) the C standards committee has been reluctant to require it be supported by all implementations. — DAGwyn (talk) 18:10, 6 May 2009 (UTC)

• Re: "in such cases compilers for those targets virtually always provide _nonstandard_ extensions to do the job", I only touched on the case when a programmer casts a pointer of granularity 1 to another pointer of higher granularity. I suggested that this often stems from unawareness of the C compiler varieties and targets and of the C standard's section 6.3.2.3, par. 7 that prohibits such casts. I suggested that the cast should be replaced by allocating a properly aligned buffer of the higher granularity and by populating its content. Optionally, I suggested that it might make sense to combine the content transfer with the network-to-host order conversion.

Re: aligning hardware buffers, I am not experienced with this much. If the problem is in creating a buffer with a certain granularity that exceeds the particular C compiler/target's notion of super-alignment in malloc(), it is still possible to allocate a sufficiently large buffer and calculate the low and high addresses satisfying the required granularity. This would keep the code C standard compliant as it would not depend on non-standard keywords.

Re: impossibility of casting "sub-word" addresses to "word" pointers within C standard, this agrees with the above reference to section 6.3.2.3 par. 7. I understand that certain compilers do provide non-standard keywords such as __packed that tell the compiler to generate 2 word accesses, combine the results into one temporary word by rotating/masking these results and resolve *wordP into that temporary word. I am just saying that instead of relying on non-standard features and C preprocessor branching by target, it is possible to write portable bare C code by picking "sub-words" explicitly and putting them into a "word"-aligned buffer. --ilgiz (talk) 22:17, 8 May 2009 (UTC)

"C has a formal grammar"

If the "printed copy" referred to by the description of rev. 281338283 is the "Annex A (informative): Language syntax summary" section of the current standard WG14/N1256, one could mention that section as a reference. I guess the formal grammar does not define the language, its environment and its library, but only serves informative purpose. --ilgiz (talk) 19:16, 2 April 2009 (UTC)

It takes more than a grammar to define a programming language. C does have a formal grammar, but so does virtually every PL. The grammar in the Annex of the standard is derivable from the specifications scattered through the body of the standard. — DAGwyn (talk) 18:15, 6 May 2009 (UTC)

C# not mentioned as related

I don't want to edit this, in case the consensus is that it is too far removed, but I believe C# is based on C++ therefore should be mentioned as a "related language" to C, which started it all. The C# article does say this.KoolerStill (talk) 11:17, 23 April 2009 (UTC)

Huh? "C has directly or indirectly influenced many later languages such as Java, C#, Perl, PHP, JavaScript, LPC, and Unix's C Shell." Chris Cunningham (not at work) - talk 11:58, 23 April 2009 (UTC)

no link to C functions list??

There is a List of C functions with a separate article on each function. I can't see a link to this from this article. Is this deliberate? or is the list destined for deletion? I think it might be a little too detailed for an encyclopedia, but if it is there it should be linked to the main article on the language.KoolerStill (talk) 11:58, 23 April 2009 (UTC)

There are some well-established standard C library functions (currently subsetted for standalone implementations). Beyond that, there are C interfaces to other functions with varying degrees of standardization, and most programmers need to use some of them too. Since the page you mentioned mixes these together, and has many broken links, it doesn't merit inclusion as a reference here. The C article should no more be a master link page for everything related to C than the Oxygen article (if there is one) should link to articles about everything containing oxygen. — DAGwyn (talk) 18:22, 6 May 2009 (UTC)

That's partly why I was wondering about the usefulness of that list. Being a list, it offers no explanations, not even of what library function are. Yet in the article, where that is explained, there is no reference to the list, so the list seems to be orphaned. And more appropriate to a programming handbook than an encyclopaedia. Maybe I'm on the wrong talk for this concern? KoolerStill (talk) 20:41, 8 May 2009 (UTC)

Imperative vs. procedural

In the infobox next to “Paradigm,” C is tagged as being an “imperative (procedural)” programming language. Why are these two attributes not listed separately and independently (i. e., simply separated by commas, rather than one being in parentheses)? Does being either necessarily imply the other, or, conversely, is it impossible to be one but not the other? I’m not a programming language expert, and therefore would like clarification from one of the article’s authors. Thanks! —Technion (talk) 16:36, 2 May 2009 (UTC)

A procedural language is a particular kind of imperative language. Another would be an OOP language (in the C++/Java style). Alksentrs (talk) 16:45, 2 May 2009 (UTC)

According to the Wikipedia article on “Structured programming,” structured programming can also be considered a subset of procedural programming, and yet the tag “structured” is written independently, separated by a comma; according to your logic, the tag would then have to be double-parenthesized and written as “Paradigm: imperative (procedural (structured)).” Why the inconsistency? —Technion (talk) 17:01, 2 May 2009 (UTC)

Interesting point... I think that whilst you can use structured programming in C, it wasn't specifically designed for only structured programming: it has the goto statement, for example. Alksentrs (talk) 17:33, 2 May 2009 (UTC)

The definitions here are quite vague. I was taught in the end of 80's that procedural languages specify algorithms (the procedures leading to results), while non-procedural languages specify goals (SQL and Prolog, for examples, unless you delve deeper into SQL procedural extensions or use Prolog in procedural style). From my point of view, the situation is quite the opposite: Imperative languages (those based on visibly modifying a global state in the course of a computation) are a sub-group of procedural languages. But as I said, the definitions are quite vague. 85.70.62.27 (talk) 17:26, 7 June 2009 (UTC)

Enum deficiency

Without resorting to X-Macros, a C programmer cannot loop across enum values. In the best case, when the minimum and the maximum values for the enum are known and when there are no holes in the definition, a regular for loop will result in a warning that the condition is always true. I wonder if this may theoretically cause a run-time exception or lock-up with C implementations that insist on enum value consistency.

  e_t evar;
  for (evar = e_first; evar <= e_last; evar++) {
    ...
    continue;
    ...
  }

This best-case scenario could probably be rewritten as follows.

  e_t evar;
  for(evar = e_first; ; evar++) {
    ...
    goto next;
    ...
  next:
    if (evar == e_last) {
      break;
    }
  };

--ilgiz (talk) 21:35, 4 May 2009 (UTC)

• Please use this page only to discuss possible edits to the C article, not for programming issues. The C "enum" facility was never meant to provide a compact set that can be iterated over. It was really meant as an alternative to #defined constant names as values of tag fields, and that was largely because it was nicer when using some (really old) debuggers, which would display the names for enum constants but not for cpp macros. — DAGwyn (talk) 18:30, 6 May 2009 (UTC)

• This is almost true. The enum facility is an alternative to macro constants, but additionally provides a way of bounding acceptable values. For example, a function that takes an enum type as an argument enforces passing only values that are part of the enum, in comparison to a function that must take an int (or long, or whatnot) because the macro is typeless. Ajrisi (talk) 13:00, 12 May 2009 (UTC)

• While it is not necessarily good practice to iterate across an enum (because enum values are not always consecutive), a common way of doing it is to have the last value in the enum be something like "MY_ENUM_END" (with MY_ENUM being changed to something more specific). Once that has been done, its fairly easy to use a common 'for' loop. Your code above (2nd part), by the way, is exactly the for loop:

  for(evar = e_first; evar != e_last; evar++) {...}

Remember, whenever possible, avoid goto's like they are the plague. Ajrisi (talk) 13:00, 12 May 2009 (UTC)

• Thanks, ajrisi. Your correction is much shorter but needs to change the enum definition as you mentioned. Going back to my notation, your correction requires adding an artificial boundary element e_past_end to the enum definition, so the condition should look like evar != e_past_end. One cannot get by just writing evar != e_last + 1 as (a) I am not sure about C standard's limitations on arithmetic operations with enum values and (b) e_last + 1 might theoretically cause a run-time error. --ilgiz (talk)

• Spot on - I left it as e_last, assuming that would be his name for what I called MY_ENUM_END. as for != e_last +1, you could do that, if you were sure that the enum values were consecutive, and that e_last+1 did not occur earlier in the list. Here is an example that the e_last + 1 would have trouble with:

 enum {
   E_FIRST = 0,
   E_SECOND = 2,
   E_LAST = 1
 };

You can see that the code would prematurely quit when it did the (evar != E_LAST+1). While it certainly wouldn't meet any form of coding standards, you always have to think "it could happen". Oh, before I forget, enums are internally stored as integers in the C standard (ISO/IEC 9899:1999 6.7.2.2 - The expression that defines the value of an enumeration constant shall be an integer constant expression that has a value representable as an int ) Ajrisi (talk) 13:00, 12 May 2009 (UTC)

I made a couple of changes to the above convo., changing the anonymous edits to show they were written by me. I did indeed write them, I just wanted people to know who to blame later if I was wrong. Thanks - Ajrisi (talk) 13:00, 12 May 2009 (UTC)

why not lang="c"?

Hidden editor comment in article: "Also, present consensus is against lang="c". " May I ask why? Isn't syntax highlighting a good thing? I can see turning it off for the outdated K&R example, but why is it off for the normal "Hello World!" example? --Cybercobra (talk) 23:57, 10 May 2009 (UTC)

Past discussions:

• Talk:C (programming language)/Archive 8#Source language = C formatting
• Talk:C (programming language)/Archive 9#Howcome no syntax highlighting?

Alksentrs (talk) 01:46, 11 May 2009 (UTC)

Personally, I don't like syntax highlighting but, those really aren't good reasons. Mike92591 (talk) 21:17, 11 May 2009 (UTC)

Agreed. It's time to re-think this. If the lang attribute results in poor presentation in certain conditions then that should be brought to the attention of the MediaWiki developers, not hacked around on one of our highest-profile programming language articles. It's there for a reason, and we should use it to provide the greatest semantic value for our readers. Unless there are any new and more valid objections than "it sucked in 2007" and "we agreed that it sucked in 2007" then I'd be happy with adding the lang parameter back. Chris Cunningham (not at work) - talk 14:40, 19 May 2009 (UTC)

Syntax highlighting is great as a personal preference in one's own editor where you can customize it and turn it off (Lord knows I always use it), but it really doesn't have a place in a general purpose, entry level article. - Richfife (talk) 17:41, 19 May 2009 (UTC)

That's a different debate. The question here is not whether or not the <source> tag should have syntax highlighting, but why we're not using the <source> tag's lang attribute to properly mark up source code when that's what it's provided for. If editors disagree with syntax highlighting then they should be arguing with the MediaWiki developers to turn it off on Wikipedia's deployment, not hacking around it by not marking up code correctly in articles. Chris Cunningham (not at work) - talk 15:20, 20 May 2009 (UTC)

Not really. Mediawiki can decide whether or not to provide it, but the decision to USE it is an article to article (or, more likely, a wiki to wiki one). The software is used on many wikis, so the presence of a particular feature doesn't imply it should be used everywhere possible. - Richfife (talk) 19:03, 20 May 2009 (UTC)

I said "on Wikipedia's deployment". Would you agree that if the Wikipedia instance of MediaWiki has syntax highlighting turned on, that this is an implicit endorsement of the use of this feature on Wikipedia articles? Chris Cunningham (not at work) - talk 01:51, 21 May 2009 (UTC)

No, I wouldn't. Making a particular feature available in the underlying software is not an editorial decision. It's a "here it is. You decide if you want to use it" decision. The maintainers of the media wiki software and the people that decide which features to include in an instance have no more editorial decision making power than you or I. - Richfife (talk) 20:12, 21 May 2009 (UTC)

Update

Seeing as there hasn't been any real pushback on this, I'm going to turn syntax highlighting on again. Most of our high-profile programming language articles use it now, so the inconsistency here doesn't seem to be warranted. Chris Cunningham (not at work) - talk 10:51, 3 July 2009 (UTC)

At the very leasti, I think someone should fix the ridiculous choices of colours first. Yellow on gray background is not really "highlighting", more like hiding. — Miym (talk) 14:11, 3 July 2009 (UTC)

That should be brought up with the MediaWiki developers. I have no idea why people think that using this article as a proxy for getting these things changed is a good idea; all it does it reduce the quality of this article. Chris Cunningham (not at work) - talk 14:23, 3 July 2009 (UTC)

Pushing back. Current consensus, which I agree with, is no. I've never seen a book or online C resource use syntax highlighting and unless there's a defined user by user method in preferences of customizing it or turning it off, it's a bad idea. Also, as I mentioned above, MediaWiki and this article are two separate things. The presence of a feature in the software is not an endorsement of its use any particular article. Until syntax highlighting is added to a programming standard and is not an ad-hoc, after the fact creation, it should be kept out of the articles. - Richfife (talk) 14:54, 3 July 2009 (UTC)

Again, that is using this article as a proxy for a personal disagreement with a development decision. This does nothing to improve the software, but does make this article incongruous with those programming language articles which aren't being watched by editors who disagree with said development decision. Chris Cunningham (not at work) - talk 17:27, 3 July 2009 (UTC)

Development decision != editorial decision. No relation whatsoever. The developers of mediawiki do not dictate the use of features available in articles. Why is that so hard? This was discussed 2 years ago: Talk:C_(programming_language)/Archive_8#Source_language_.3D_C_formatting. Have you tried syntax highlighting with all the Wikipedia skins yet? Have you tried it with all browsers? - Richfife (talk) 19:25, 3 July 2009 (UTC)

Also, the problem with trying to "fix" the software is that there IS no right solution to the problem. Everything is going to look bad somewhere. - Richfife (talk) 19:37, 3 July 2009 (UTC)

C programmers need more care ?

The section on syntax about operator evaluation includes the following sentence: "This permits a high degree of object code optimization by the compiler, but requires C programmers to exert more care to obtain reliable results than is needed for other programming languages." Many other languages don't actually specify an order of evaluation for operands, so I would have thought C's approach was far more reliable. I propose that the sentence be truncated to ""This permits a high degree of object code optimization by the compiler." Any objections ? Cadae (talk) 07:11, 27 June 2009 (UTC)

The sentence quoted is not only referring to "order of evaluation", it is also (and perhaps more significantly) referring to the fact that "The evaluations may even be interleaved." Chris Burrows (talk) 12:43, 27 June 2009 (UTC)

In some other languages the presence or absence of interleaving is not even specified (e.g. Pascal) - again the explicit definition in C (that there could be interleaving) is safer than the situation in some other languages. The problem is that the issues vary by language - C# and Java specify an explicit operand evaluation order so sequencing and lack of interleaving are clearly defined, whereas Pascal, Ada, C, C++ and some others don't specify an order of evaluation for all operands. It is therefore inaccurate to say that C programmers have to exert more care than is needed for other programming languages. Perhaps more care than for Java or C#, but not more care than, for instance, Pascal. Cadae (talk) 10:43, 28 June 2009 (UTC)

c language

why calling c language is middle level language —Preceding unsigned comment added by 59.164.2.104 (talk) 15:24, 10 August 2009 (UTC)

Revised ISO/IEC 9899 Committee Draft

JTC1/SC22/WG14's ISO/IEC 9899 page states "The most current draft of the revised C99 standard is available in N1336." Update to links section required. - 204.111.152.29 (talk) 02:34, 19 October 2009 (UTC)

constant pointers

hi,

my question is about constant pointer

Can you make a constant character pointer point to some other string —Preceding unsigned comment added by 122.167.74.225 (talk) 14:26, 20 October 2009 (UTC)

Not really the place for this, but... It depends on where the const is. The const applies to whatever immediately follows it. You can change "const char *" to point to a different string, but you can't change the contents of the string memory it points to. You can not change what memory "char const *" points to, but you CAN change the contents of the memory. "const char const *" menas you can do neither, but some compilers (*cough*microsoft*cough*) emit a bogus warning on that declaration. - Richfife (talk) 16:36, 20 October 2009 (UTC)

"const char *p" = "char const *p" = non-constant pointer to constant char. However, "char * const p" is something different: a constant pointer to non-constant char. And "const char * const p" is a constant pointer to constant char. (Easier to remember if you read these "backwards": "char * const p" = "p is a const pointer to char".) — Miym (talk) 18:47, 20 October 2009 (UTC)

Generic programming completely absent

The article says:

• Only rudimentary support for generic programming

despite being a C programmer that have abandoned C++ for the PODs issues, I must say there is no generic programming whatsoever in C, unless the preprocessor is counted; and since the preprocessor provides no type control whatsoever, counting the preprocessor is not justified. ... said: Rursus (bork²) 10:43, 17 January 2009 (UTC)

It does support a limited form of generic programming with generic pointers; qsort is a good example. Mike92591 (talk) 21:09, 17 January 2009 (UTC)

qsort is not an example of generic programming, rather of first-class functions implemented using function pointers. Adrianwn (talk) 06:44, 6 March 2010 (UTC)

Comma operator links to sequence point?

Under "Operators", there's a group "sequencing" containing only the comma operator, which links to the Sequence Point page. Is this right? While the comma operator is certainly a sequence point, that does not appear to be its primary purpose. From K&R:

Comma operators should be used sparingly. The most suitable uses are for constructs strongly related to each other, as in the for loop in reverse, and in macros where a multistep computation has to be a single expression.

--Mcaruso (talk) 20:44, 24 May 2009 (UTC)

The only functions of the comma operator are to insert a sequence point, and to separate subexpressions for convenience in contexts where multiple things are going on, such as for(p=base,i=0;i<MAX;++p,++i) and if(++p,++i>=MAX). There isn't any name or Wikipedia page for "programming convenience", but there is for "sequence point". — DAGwyn (talk) 02:46, 24 July 2010 (UTC)

Guidance asked for some details about my recent edit

The "minimalism" paragraph talks about the relative ease of implementing compilers that generate efficient machine code, and cites the DEC PDP-11 as a case in point. To expand on the intent of the paragraph I added mention of C compilers for some 8-bit platforms, linking to one that has a Wikipedia page. My two questions are:

1. While the PDP-11's CPU is also 16 bits, the original article seems to stress its 16-bit address space, not the CPU itself; apparently the intent is to stress the compactness of the generated object code as well as access to arbitrary addressable objects. However, the ability to compile efficient object code for simpler CPUs with far less sophisticated instruction sets also testifies to this point. Reading over my edit, though, it seems the juxtaposition of text stressing address space in one case and CPU data size in the other seems possibly confusing. Does anyone have an opinion on this?

2. I am only aware of one such compiler (Aztec_C). My first shot at the sentence said something like, "There is at least one..." That looked awkward, so I changed it to simply "Compliers for..." I can't say with certainty if the plural is actually correct. Does this matter or can the plural wording be considered to be generic and covering both cases?

Rhsimard (talk) 23:21, 19 September 2009 (UTC)

The context was intended to be the compilation environment, not the run-time target, and the initial C implementations were for the PDP-11, which has an address space comparable to the 8-bit platforms that ran Aztec C and ORCA C. Those compilers did not fully implement C89, largely due to size limitations, and fully compliant C99 versions would have to be highly segmented, making them impractical. I have just fixed up the wording to make it clearer. — DAGwyn (talk) 03:01, 24 July 2010 (UTC)