Talk:C (programming language): Difference between revisions

Revision as of 04:52, 2 July 2025

Latest revision as of 05:21, 25 August 2025

(24 intermediate revisions by 12 users not shown)

Line 24:

}}

{{archives|bot=MiszaBot I|search=yes|age=100|dounreplied=yes}}

== Mention of C allowing various memory allocations schemes ==

{{u|Jochen Burghardt}} [https://en.wikipedia.org/w/index.php?title=C_(programming_language)&diff=prev&oldid=1183993545 removed] this section on C allowing various memory allocation implementations:

:{{tq|C permits the use and implementation of different [[C dynamic memory allocation|memory allocation]] schemes, including a typical {{code |lang=c |malloc}} and {{code |lang=c |free}}; a more sophisticated mechanism with [[Region-based memory management|''arenas'']]; or a version for an [[kernel (operating system)|OS kernel]] that may suit [[direct memory access|DMA]], use within [[interrupt handler]]s, or integrated with the [[virtual memory]] system.}}

With the edit summary {{tq|"malloc is not built in in C, but a library function, and could be provided for every other language in a similar way"}}. It's actually not true that you can do this in every other language, it depends on directly manipulating and storing pointers for one thing, which most languages do not do. The passage doesn't say malloc is part of C itself, in fact it implies the opposite - it lists malloc as one possibility. I disagree with this removal. [[User:DIYeditor|—DIYeditor]] ([[User talk:DIYeditor|talk]]) 19:49, 7 November 2023 (UTC)

:As I understand the title of this article, it is about the C programming language itself; there is a different article [[C standard library]]. "{{tq|The passage doesn't say malloc is part of C itself}}" - this is the reason why I think it shouldn't be discussed here, but at [[C standard library]]. As a side remark, <code>malloc</code> can be implemented as is in every language that supports pointers, and with slight modifications in every language that supports arrays (having arbitrary type casts in the language will increase user convenience). - [[User:Jochen Burghardt|Jochen Burghardt]] ([[User talk:Jochen Burghardt|talk]]) 11:58, 8 November 2023 (UTC)

::Please stop edit warring to restore your preferred version.

::We can wait for input from more people. [[User:DIYeditor|—DIYeditor]] ([[User talk:DIYeditor|talk]]) 13:17, 8 November 2023 (UTC)

:::I didn't edit [[C (programming language)]] after my above reply. The anonymous IP 193.162.48.193 vandalized an article part that is unrelated to our above discussion, and I assure that it wasn't me. Admittedly, my 2nd revert might have violated a strict interpretation of [[WP:BRD]]; however, I gave a long justification in my edit summary. Waiting for opinions from other people is ok for me. - [[User:Jochen Burghardt|Jochen Burghardt]] ([[User talk:Jochen Burghardt|talk]]) 14:05, 8 November 2023 (UTC)

::The goal of this the overall section is to explain and justify the wide adoption of C as a systems programming language. The section in question states that C permits choice in dynamic memory allocators - a good justification, since operating systems and similar often control memory for other processes. Options range from the usual {{code|stdlib.h}} to very machine-specific ones. This flexibility is a feature of the language. Only one of the choices pertains to the standard library and its {{code|malloc}} - the others do not - and indeed there is already a link in the debated section to [[C dynamic memory allocation]].

::If there are improvements to be made, then let's make them! But I agree with {{u|DIYeditor}} and disagree with the removal. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 20:18, 8 November 2023 (UTC)

== Duplicate sections on related languages - merge? ==

Line 45 ⟶ 30:

Should we consider these as duplicates, and merge them to one ___location? Or are we happy with the different emphasis on the somewhat similar content, and leave well alone? Or Perhaps replace the first section with a sentence and keep the latter section? Or something else? [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 05:29, 26 April 2024 (UTC)

:IMO duplicate info should almost always be eliminated. These sections should be merged. ... There is lots of duplicate info throughout the article that bloats the length without adding value. I think the article has become crufty since it has been edited a zillion times by a zillion people. Needs refactoring :) [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 12:10, 11 July 2025 (UTC)

== C is a compiled language ==

Line 53 ⟶ 40:

::{{re|Jkudlick|Johnuniq|Chris.temp.level.0}} I think that "designed to be compiled" already present in the LEDE is sufficient. — [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 12:00, 20 July 2024 (UTC)

:::Agree. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 14:34, 20 July 2024 (UTC)

:::Originally intended to be compiled, yes. Originally designed to be compiled, sure. But that was decades ago. Is it still designed to be compiled? IMO that's arguable. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 12:07, 11 July 2025 (UTC)

:I worked at a company that sold a product with a C interpreter. C is typically compiled yes. But it doesn't have to be. In fact, any language can be either compiled or interpreted. IOW, there is no such thing as a compiled language or interpreted language. There are languages and there are compilers and interpreters that accept input in some language. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 12:05, 11 July 2025 (UTC)

::No, some languages must not be compiled. This is the case of shell scripts, for which any syntax error must not yield an error as long as the corresponding line is not attempted to be executed. — [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 12:11, 11 July 2025 (UTC)

::Technically, it may be correct that any language can be "compiled" or interpreted. However, it is extremely misleading to claim that there is no distinction between compiled languages and interpreted languages. As Vincent Lefèvre pointed out, shell scripts should not yield an error as long as the corresponding line is not "attempted to be executed". The only feasible way to "compile" such a language would be to bundle an interpreter into a binary with the language. Some languages are clearly designed to be interpreted. Languages with a eval function like Javascript and Python would require an entire interpreter or JIT compiler to be bundled into the executable if such a function was called with a runtime value. [[User:Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO|Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO]] ([[User talk:Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO|talk]]) 03:06, 18 July 2025 (UTC)

:::Note however that Perl is a compiled language with an <code>eval</code> function. The whole compilation step is done before execution of the script or of the eval'ed code. Contrary to purely interpreted languages, any syntax error is detected, even if the corresponding code would not be reached during execution.

:::EDIT: And in Perl, it is possible to call functions before their declaration/definition (this would not have been possible if Perl scripts were interpreted).

:::— [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 17:48, 19 July 2025 (UTC)

::::Perl is not really compiled. Perl 6 (aka Raku) converts to Parrot bytecode, which is interpreted. Thus, Perl 6 (aka Raku) is bytecode interpreted, which is how Java and Python work, as well. Perl 5 supported an internal bytecode. Perl 4 and below generate a parse tree before interpreting. You can correct me if I am incorrect about perl; however, I do not think that I am.

::::Compilation is about code generation. If machine code is never generated, then the implementation is interpreted. If machine code is generated while the program is running, then the implementation is JIT compiled. If machine code is generated before the program is ran, then the implementation is AoT compiled.

::::Most interpreted languages can be implemented with a JIT compiler, for example, Javascript. However, AoT compilation and JIT compilation are very different. [[User:Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO|Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO]] ([[User talk:Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO|talk]]) 23:24, 19 July 2025 (UTC)

:::::Compilation is the process of converting a program from one representation to another - if source code is turned into bytecode, that is still compilation. [[User:MrOllie|MrOllie]] ([[User talk:MrOllie|talk]]) 00:05, 20 July 2025 (UTC)

::::::Yes, and even machine code of an actual processor is interpreted, either in hardware by the processor itself or in software by an emulator. — [[User:Vincent Lefèvre|Vincent Lefèvre]] ([[User talk:Vincent Lefèvre|talk]]) 14:04, 20 July 2025 (UTC)

== Remove <nowiki>{{harvtxt}}</nowiki> templates? ==

Line 82 ⟶ 81:

:But what are "standard Cites"? 😀 There is no such thing in Wikipedia and everyone does what they want anyway. [[User:Elrondil|Elrondil]] ([[User talk:Elrondil|talk]]) 02:58, 13 June 2025 (UTC)

::Ah, true, true! [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 06:39, 13 June 2025 (UTC)

== Holy c needs to be added as a dialect ==

. [[User:Tankfarter|Tankfarter]] ([[User talk:Tankfarter|talk]]) 05:38, 28 July 2025 (UTC)

== Energy Usage ==

This whole section is absolutely bizarre:

Originally, C was popular mostly due to being easier to use than other programming languages.[citation needed] Currently, C is popular mostly due to speed, efficiency, low memory usage, and simplicity.[citation needed] C uses approximately one-eightieth the energy that Python, Perl, and PHP do.[17] On average, C uses less energy than Fortran, despite Fortran being faster on average.[citation needed]

But this line in particular:

C uses approximately one-eightieth the energy that Python, Perl, and PHP do.[17]

Is particularly problematic, as it gives the reader the understanding that C always uses 1/80 of the energy of the other listed languages, when in fact, it uses this while running these specific benchmarks, which have very little (if anything) to do with the real-world use of a language.

Let's take Python for example. Which Python? Python 3.13? Python 2.6? CPython 3.13? Pypy 3.8? C as compiled with what? A "typical" C implementation of a given program probably does use substantially less energy than a "typical" Perl equivalent, but stating 1/80 based on some benchmarks makes no sense.

The entire section reads as something you would read on a website comparing Linux distros where it's clear the author has no idea what they're talking about. [[Special:Contributions/196.211.140.249|196.211.140.249]] ([[User talk:196.211.140.249|talk]]) 08:55, 21 August 2025 (UTC)

:That was added at [[Special:Diff/1301098576|02:36, 18 July 2025]] and should probably be removed. I doubt sites.google.com is a [[WP:RS|reliable source]]. Also, the [[WP:LEAD]] is supposed to be a summary of what is in the article. The lead should not be used to add ideas. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 09:13, 21 August 2025 (UTC)

:Lets not pretend that C uses the same energy usage as Python. The Cython website claims benchmarks where Cython beat the reference implementation of Python in speed by a factor of 95. Even Cython, which few Python users use, uses more energy than typical C program equivalents. Almost all Python users use the reference implementation, which is well known for wasting CPU time, RAM, electricity, etc. Obviously, 95 is higher than the 80 times energy usage increase stated; however, the difference between 95 and 80 can be attributed to the fact that speed is not the same as energy usage.

:Somewhere else on the internet, I saw something where someone got a 75 times speedup in the training of a neural network by rewriting their Python to C, while using the same machine learning library. However, I do not remember where I saw that. [[User:Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO|Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO]] ([[User talk:Lxvgu5petXUJZmqXsVUn2FV8aZyqwKnO|talk]]) 20:07, 24 August 2025 (UTC)

::The point, which has not been acknowledged, is we don't cite [[WP:USERGENERATED|user-generated sources]] in any instance. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;🌈&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 20:11, 24 August 2025 (UTC)

::This was returned with a [[WP:ARXIV]] preprint, which is another kind of user-generated source, so that's not any better. Kindly secure agreement on this talk page before reinserting any variation of this claim. [[User:MrOllie|MrOllie]] ([[User talk:MrOllie|talk]]) 21:29, 24 August 2025 (UTC)

:::@[[User:MrOllie|MrOllie]], I looked via Google Scholar and thought I saw another version of the paper published somewhere on Harvard's webspace, but I clicked in and saw it was just another arXiv portal or something, whoops. Sorry for the confusion. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;🌈&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 01:05, 25 August 2025 (UTC)

:In many implementations, C compiles directly to machine code that runs directly on the target procsssor. Many other languages are either JITting, or use bytecodes which are considerably less efficient. While C is far from unique in producing machine code, it is totemic in doing so, and engineers choose C for its close-to-machine output. Perhaps words should go in the lede (or elsewhere) to extol this close-to-machine benefit of the language, perhaps alongside comparisons to other compiled languages. I don't think citing 80x or similar is wise, given how context-dependent such figures will be. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 22:48, 24 August 2025 (UTC)

::That's more or less what the third paragraph of the lead is doing. [[User:MrOllie|MrOllie]] ([[User talk:MrOllie|talk]]) 01:10, 25 August 2025 (UTC)

:::Yes, sort of. The 'designed to be compiled' part in lede para 3 is fine, but perhaps we should have words that spell out what that implies in terms of efficiency. This would be alongside other compiled languages, and in contrast to other languages which rely on interpreters, JIT, bytecodes, etc. [[User:Chumpih|<span style="text-shadow: 2px 2.5px 3px #448811bb">Chumpih</span>]] ^{[[User talk:Chumpih|t]]} 05:21, 25 August 2025 (UTC)