Jump to content

Talk:C (programming language)/Archive 17

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 10←Archive 15Archive 16Archive 17

Why are characters and booleans irelevant to C programming?

Referencing https://en.wikipedia.org/enwiki/w/index.php?title=C_(programming_language)&diff=930371741&oldid=930367380&diffmode=source

@Fbergo: Why are booleans and characters irelevant to C (programming language)? --Kreyren (talk) 11:40, 12 December 2019 (UTC)

  • They are not irrelevant, and both are already mentioned in the first paragraph of the Data Types section. This article is already quite long for wikipedia (WP:TOOLONG), repeating information is not an improvement. Your tutorial-like sections on basic types only made the article less readable. The article should not be a language tutorial (WP:NOTTEXTBOOK). Fbergo (talk) 14:39, 12 December 2019 (UTC)

Assuming incorrect use of print formatted in an example

Based on https://en.wikipedia.org/wiki/Talk:C_(programming_language)/Archive_8#%22Hello,_world%22_example as referenced in the current page (https://en.wikipedia.org/enwiki/w/index.php?title=C_(programming_language)&diff=930286305&oldid=930286262) as:

<!-- READ THIS BEFORE YOU EDIT! If you think there is a better way, first see talk page archive No. 8 for why. If you still want to change it, discuss it first. --> 

#include <stdio.h>

int main(void)
{
    printf("hello, world\n");
}

Looks like wrong use of pritnf where

print formatted (printf) is designed to work with a provided format as referenced on https://en.wikipedia.org/wiki/Printf_format_string#Syntax meaning that the correct code should look like: 

#include <stdio.h>

int main(void)
{
    printf("%s\n", "Hello world");
//         ^^^^^^ - Notice format string for printf used
}

This should be updated for all printf mensions in this article. --Kreyren (talk) 23:19, 11 December 2019 (UTC)

A printf format string need not have parameter format specifications. Adding them where not needed is distracting to the reader. --A D Monroe III(talk) 00:56, 26 June 2020 (UTC)

Source

In private conversation with Bjorn Sjostrup, he confirmed that previous compilers from other coders were considered as sources for good ideas, as was the norm for the time: we were building an industry, and the patent rights now claimed should be carefully examined as non-original work: bubble sorting and bitmapped fonts were part of this for sure, because I worked on them! — Preceding unsigned comment added by 90.197.51.50 (talk) 22:49, 7 July 2020 (UTC)

That's a start. You might be able to find a reliable source. Private conversations aren't that. TEDickey (talk) 22:56, 7 July 2020 (UTC)

TempleOS

I agree that the IP's effort (diff) to add HolyC (linked to TempleOS) to the infobox is WP:UNDUE. In fact I can't think of a DUE way of mentioning HolyC or TempleOS at this article but any long-term C coders (hi Guy Macon) might like to review the stunning achievement of TempleOS (it's crazy but a magnificent achievement with, for example, JIT-compiled HolyC as the shell language) and think about what articles could link to it. Johnuniq (talk) 00:10, 26 July 2020 (UTC)

(I am mostly an assembly-language programmer, but I can code in C if I have to.)
HolyC: not to be confused with Holy See. :)
It certainly does simplify things if the system's features are explicitly instructed to you by God...
You can run it in a virtual machine: [ https://eleni.mutantstargoat.com/hikiko/holy-days-temple-os ]
Rosetta Code has a category for programs written in HolyC: [ https://rosettacode.org/wiki/Category:HolyC ]
Alas, the one thing HolyC isn't is a variation of the C programming language. If you look at the description here:[1] you will see that it is a new programming language with some similarities to C. --Guy Macon (talk) 00:58, 26 July 2020 (UTC)
Thanks for the links. Johnuniq (talk) 01:40, 26 July 2020 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion:

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 14:18, 19 October 2020 (UTC)

About the Hello World Example

I think that the hello world example should be like this: 

#include <stdio.h>
int main(){
    printf("%s\n""Hello World!");
    return 0;
}

—ThesenatorO5-2 (talk • contribs) 09:38, 25 June 2020 (UTC)

That's incorrect too and will most likely result in a runtime crash. — Preceding unsigned comment added by Brett Alexander Hunter (talk • contribs)
  • Hello world are examples of minimal standard-compliant code that perform the specific task of printing a message on the device's display/output. The code currently on the article is correct and requires no additional complications. Fbergo (talk) 15:53, 25 June 2020 (UTC)

As things stand right now, your second example will result in a compiler warning, won't it? You specifically indicate an 'int' return value but return nothing. That's anything but 'standard-conforming' as you call it.

Brian was brilliant at educating in that book. The way he told you something but also left off tidbits and crumbs for the lesson coming up.

The actual purpose of hello world is to get your environment up and running.

Cheers. — Preceding unsigned comment added by Brett Alexander Hunter (talk • contribs)

It should be like this. 

#include <stdio.h>
int main(){
    printf("%s\n", "Hello World!"); // Note that the two args should have a , between.
    return 0;
}

01:05, 19 August 2020 (UTC)ThesenatorO5-2argue with me

Nah, we should stick to the minimal version. There is no reason to break the string into two arguments. - MrOllie (talk) 01:14, 19 August 2020 (UTC)

In The ANSI C Programming Language book by the inventors of C Brian Kernighan and Dennis Ritchie, the example they used was as follows: 

#include <stdio.h>

main()
{
  printf("hello, world\n");
}

Although I must say that in order to get that to compile I had to make it "int main()" rather than just main. Thunderblood101 (talk) 21:12, 17 January 2021 (UTC)

Even int main(void), and with return 0; at the end. — Vincent Lefèvre (talk) 21:27, 17 January 2021 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion:

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 06:41, 30 June 2021 (UTC)

Pointer values

Pass-by-reference is simulated in C by explicitly passing pointer values.

'Pointer values' is specifically ambiguous. Suggest 'addresses' instead. Also: 'pass-by-reference' seems new. The accepted terms are 'call by reference' and 'call by value' (with a third method unused but for Algol - 'call by name'). Also: it's not really 'simulated' either, is it? It's done. — Preceding unsigned comment added by Brett Alexander Hunter (talk • contribs) 01:18, 6 August 2020 (UTC)

arrays

I started to revise the text about arrays because it was outdated, slightly incorrect, and partially misleading. (As background info: I am a member of the ISO working group for C and contributor to GCC.) Martin.uecker (talk) 08:25, 21 November 2021 (UTC)

Italics

@Chumpih: I don't think MOS:TERM applies to this edit. It says A technical or other jargon term being introduced is often being mentioned as a word rather than (or in addition to) playing its normal grammatical role, but in this case it is neither a technical term (rather, it is a proper name) nor is it being mentioned as a word. If the name of the language were 'Python' rather than 'B' I doubt anyone would write "A successor to the programming language Python". Ruбlov (talk • contribs) 15:25, 21 April 2022 (UTC)

@Rublov, Given these are the introductions of the terms, as opposed to references to the terms, perhaps the italicisation is warranted. Chumpih t 15:41, 21 April 2022 (UTC)
Actually, on further consideration, you're probably right. Apologies. Chumpih t 16:00, 21 April 2022 (UTC)

Order of sentences in the opening paragraph

Is there a good reason why the opening paragraph starts with “commonly in …” then one “decreasingly in …” then more “commonly in …”? I found this order slightly confusing. Osalbahr (talk) 01:39, 31 May 2022 (UTC)

It's likely imperfect, as you identify. WP:DIY. Then perhaps WP:BRD or perhaps subsequent changes if your edits don't quite hit the mark. Chumpih t 21:24, 31 May 2022 (UTC)

"C(programming language)" listed at Redirects for discussion

An editor has identified a potential problem with the redirect C(programming language) and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 August 16#C(programming language) until a consensus is reached, and readers of this page are welcome to contribute to the discussion. Steel1943 (talk) 21:09, 16 August 2022 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for speedy deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for speedy deletion:

You can see the reason for deletion at the file description page linked above. —Community Tech bot (talk) 19:08, 18 August 2022 (UTC)

popularity contests

A recent edit confuses popularity (a weakly-defined, subjective term) with widely-used. Sources such as the two most recently proposed are unconvincing TEDickey (talk) 22:05, 1 August 2022 (UTC)

I consider that the newly added claim ("though decreasingly") has no place in the lead: it only makes it longer by stating a dubious and unsourced perception. Blog sources shouldn't even be considered, per WP:RS. The article, and in particular its opening paragraph, should describe the language throughout its entire existence, not "C nowadays" or "C in recent years", per MOS:RELTIME. Fbergo (talk) 22:26, 1 August 2022 (UTC)
so perhaps we could have previously for application development ? Point being that there doesn't appear to be evidence to suggest that C remains widespread for that purpose, former glories notwithstanding. Chumpih t 22:58, 1 August 2022 (UTC)
"It has found lasting use in operating systems, device drivers, protocol stacks, and application software". Lasting refers to the duration of usage of the language in each software product/project, not that the use is widespread or prevalent. GIMP, the open source graphics editor, is written and maintained in C since 1998. GIMP alone serves as refutation to "C is no longer used for application development" or "C found use for application development in the past, but not recently", even though many other examples certainly exist, but are hard to track as most commercial applications do not advertise or expose their programming language. Fbergo (talk) 23:41, 1 August 2022 (UTC)
Well, it's a good point: GIMP desktop application project started 24 years ago did indeed choose C as the implementation language, and that application has proven excellent and popular. And prior to Visual C++ (1993) a lot of significant Windows application programming was done Petzold style, using C almost exclusively. Here's the thing - for device drivers, protocol stacks, operating systems, embedded systems, utilities, C remains a solid player; for applications, not so much. We should differentiate - hence some language like formerly in applications or decreasingly in applications when noting C's use in these fields. And that includes applications on web, mobile, desktop, smart TV. There are a few areas where C remains popular for applications, e.g. Automotive, and yes, GIMP is glorious. But they're in the minority. Nobody is stating "C is no longer used for application development", but C's use in applications has decreased massively since the 1990's. Even Qt is in C++. Some evidence on language choice for contemporary development is here. Chumpih t 06:09, 15 August 2022 (UTC)
@Tedickey: It's not certain that widely used is a well-defined term, either. The 'popularity' measure from Tiobe is a well-recognised attempt to show the trends in program language momentum / traction / funding or whatever. Now, here's the problem: any statistic can be questioned. For example, Git hub languages trends for pull requests is only for open-source, or it's too web-specific, or it's just for hobbyists. Recent links that show C absent from 'popular language for desktop application development' are deemed unsubstantive. So to turn this on its head, is any information available to show that C remains comparatively popular for application development? Chumpih t 22:50, 1 August 2022 (UTC)
Reliable sources are verifiable. Adding comments which are not verifiable doesn't go in the right direction. TEDickey (talk) 07:47, 18 August 2022 (UTC)
Hmmm. Wise words. So where does that leave us? Chumpih t 08:21, 18 August 2022 (UTC)
In the absence of any comments or evidence to the contrary, or any evidence-based retort to comments from a few weeks ago, perhaps the 'dubious' tag can be removed. Chumpih t 22:35, 3 September 2022 (UTC)

Pointers to pointers

I'm starting this discussion because of the ongoing edit war. I think we can agree that the section on pointers doesn't need a full example showing the use of pointers-to-pointers or a subsection just for pointers-to-pointers. At the same time, I think sentence or two pointing out that pointers-to-pointers are a thing would be nice. There are similar sentences talking about void pointers, character pointers and struct pointers already. @Fbergo @Pmk456 What do you guys think? Erinius (talk) 22:50, 5 October 2022 (UTC)

Hi, the added section (which I removed) appears to be an attempt to promote a link to a particular course as a citation, so WP:CITESPAM. The language in which it was written is inadequate for Wikipedia ("when we declare a pointer to pointer...": We?). A short sentence about pointers to pointers could be added to the Pointers section, but I think this article does not need any more code examples. Fbergo (talk) 11:43, 6 October 2022 (UTC)
Yeah, the language was inadequate and the whole subsection was a bit excessive. Thanks for the feedback, I added in a short little sentence which should be fine. Erinius (talk) 17:35, 6 October 2022 (UTC)

Delete the K+R example code

Should we delete the example of K+R C with the commented-out int types? Perhaps an example of this isn't necessary. Also, having recently looked at a first edition "C programming language", the function definitions and declarations include int, even though it may not be strictly required. Chumpih t 19:56, 12 October 2022 (UTC)

I'd rather keep the example, as it is of historical interest on the development of the language and integrates well with the section text around it. The code comments are a bit too verbose, and could probably be shortened a little. Fbergo (talk) 00:58, 13 October 2022 (UTC)
Indeed, the comments are too much. But the concern is that this is the first significant example in the text, and it shows code that while technically acceptable to some early versions of the compiler, it is not idiomatic and representative of examples that would appear in K+R. The fact that the int type was once optional in the first version perhaps doesn't warrant an example.
Or if there should be an example of early-style C code, perhaps one illustrating the function argument typing method would be more appropriate, i.e. arguments and types come on lines after the function name in the definition. Chumpih t 09:10, 22 October 2022 (UTC)

Wiki Education assignment: Linguistics in the Digital Age

This article was the subject of a Wiki Education Foundation-supported course assignment, between 11 January 2023 and 11 May 2023. Further details are available on the course page. Student editor(s): ManD01n (article contribs).

— Assignment last updated by Nurbekyuldashov (talk) 01:52, 9 May 2023 (UTC)

Delete the "middle-level language" part

It's bound to cause confusion on to the nature of C as somewhere between a high-level and low-level language, especially since Low-level programming language #Assembly language names it as a high-level language. One could also argue that middle-level is a fairly vague term that could have a lot of different interpretations. Gvv57348 (talk) 18:06, 11 December 2022 (UTC)

WP:DIY You may have a good point, IMHO. Chumpih t 20:14, 11 December 2022 (UTC)
BTW, WP has articles Low-level programming language and High-level programming language, but no such thing for middle level (this could have possibly been WP:OR). — Vincent Lefèvre (talk) 14:13, 12 December 2022 (UTC)
The only way you can @Gvv57348xv has 108.75.76.176 (talk) 04:17, 14 May 2023 (UTC)

C is a system language, not general purpose

C has system facilities. Any language with low-level facilities should not be use for general-purpose programming. It bakes in dependencies, results in lock in (which C does), and also results in inflexibility.

C also has many primitive facilities like pointers and defines which really have no place in general-purpose programming. Ian.joyner (talk) 20:12, 13 May 2023 (UTC)

I see you put this on Talk:C++ as well; it is generally wrong, and I'll reply to both comments here. General-purpose programming language is a specific term contrasted with domain-specific languages. C is a general-purpose programming language and you will find this present in nearly any source that discusses it. For instance, the very first sentence of K&R (2nd ed.) says "C is a general-purpose programming language." (page 1; also a near identical sentence is in the preface on p. xi).
The Uses section is a mess and needs some serious cleanup, but it's valid to discuss how it is used; C is widely used outside of systems programming contexts, though, so this change would also be invalid there. Wikipedia is an encyclopedia and not a manual; it would be inappropriate for the article to present an opinion on where C should be deployed in wiki-voice.
It might be appropriate to present opinions on current usage of C (and C++, in that article). There are several experts in the field who have expressed concerns specifically related to memory safety with the wide deployment of programs written in C and C++—this is far from a universally held opinion though. Note that this would require more research to incorporate; my off-the-cuff anecdote isn't enough, and any change would want to assess appropriate sources (ideally, highly trustworthy secondary sources, especially ones that provide general overviews of the state of the art, such as instructional textbooks). Dylnuge (Talk • Edits) 17:29, 1 September 2023 (UTC)

"Only the last member stored is valid"

In the "overview" section, under "User-defined (typedef) and compound types are possible" Unions are mentioned as "Union is a structure with overlapping members; only the last member stored is valid."

This is not a fair or accurate statement according to the C standard. I believe this may have been written confusing the C standard for the C++ one, in which accessing a union member that was not most recently written to is strictly undefined.

The C standard explicitly allows "type-punning" using unions, but carefully promises that reinterpreting the bit-representation of one type to another may result in an invalid or trap representation.

The following is pulled directly from the C17 standard. It lies in a footnote under section 6.5.2.3.3:

"If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called “type punning”). This might be a trap representation."

The mention of unions should probably be edited to something like "Union is a structure with overlapping members; it allows multiple data types to share the same memory location".

I will leave this note here for a few weeks and if no one objects I will make the edit. WillisHershey (talk) 21:28, 25 September 2023 (UTC)

Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Talk:C_(programming_language)/Archive_17&oldid=1235257014"