TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The Descent to C (2013)

156 pointsby x-spalmost 4 years ago

12 comments

smcameronalmost 4 years ago
&gt; (In fact, that&#x27;s what array[i] means – the language defines it to be a synonym for *(array+i).)<p>To really drive home the primitiveness of C arrays, should probably also mention that, because addition is commutative, you <i>could</i> also write<p><pre><code> i[array] </code></pre> and somewhat surprisingly, it will compile, and work, and it means &quot;*(i + array)&quot; which is equivalent to &quot;*(array + i)&quot;<p>But nobody really does that, because that would be kind of insane.
评论 #28404003 未加载
评论 #28406285 未加载
评论 #28410135 未加载
评论 #28410039 未加载
评论 #28416835 未加载
评论 #28406514 未加载
评论 #28406180 未加载
评论 #28405596 未加载
Animatsalmost 4 years ago
It&#x27;s not inherent in C being a low-level language that it has such a painful memory model. It&#x27;s a consequence of having to fit the compiler into a really tiny machine by modern standards. Originally, there were no function prototypes.<p>I once proposed a backwards-compatible way out for C.[1] Basically, you get to talk about arrays as objects with a length, even if that length is in some other variable. And you get slices and references. It was discussed enough to establish that it could work, but the effort to push it forward wasn&#x27;t worth it.<p>Slices are important. They let you do most of the things people do with pointer arithmetic. Once you have size and slices, you can still operate near the memory address level.<p>[1] <a href="http:&#x2F;&#x2F;www.animats.com&#x2F;papers&#x2F;languages&#x2F;safearraysforc43.pdf" rel="nofollow">http:&#x2F;&#x2F;www.animats.com&#x2F;papers&#x2F;languages&#x2F;safearraysforc43.pdf</a>
评论 #28411350 未加载
评论 #28413339 未加载
nihilist_t21almost 4 years ago
Hey! The author wrote PuTTY!<p>That was a very informative read. I feel like I am the exact target audience: I&#x27;m coming from a programing background steeped in C# and I&#x27;m learning C from the K&amp;R book.
评论 #28404158 未加载
评论 #28390378 未加载
dangalmost 4 years ago
Some past threads:<p><i>The Descent to C</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15445059" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=15445059</a> - Oct 2017 (2 comments)<p><i>The Descent to C</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8127499" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8127499</a> - Aug 2014 (15 comments)<p><i>The descent to C</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7134798" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7134798</a> - Jan 2014 (230 comments)
AceJohnny2almost 4 years ago
&gt; <i>So why is C like this, anyway?</i><p>Worth mentioning that C is over 40 years old, and was designed to be easily portable across a range of machines that had less compute power and memory than today&#x27;s smaller microcontrollers.<p>As a result, a lot of things were left undefined, or were designed in a way to be <i>easy to implement</i> rather than <i>easy to program for</i>.<p>There existed other programming languages that were better, but their compilers weren&#x27;t as broadly available, and their better features came at the cost of speed, which at the time was a premium.
评论 #28409766 未加载
评论 #28413345 未加载
aidenn0almost 4 years ago
Some nitpicks with the article:<p>1. Much of section 2 is wrong except the part about arrays representing contiguous objects. The rest is largely an implementation detail.<p>Zeta C and Vacietis work considerably differently, as allowed by the standard<p>In addition there are many (mostly obsolete now) architectures in which, when you convert a pointer to an integer, you can&#x27;t perform arithmetic and convert back because a pointer isn&#x27;t just an integer address; it could represent segments or support hardware tags.<p>&gt; C will typically let you just construct any pointer value you like by casting an integer to a pointer type, or by taking an existing pointer to one type and casting it so that it becomes a pointer to an entirely different type.<p>To be fair, they do say &quot;typically&quot; in here, but these behaviors are (depending on the case) all either implementation defined or undefined; the C standard specifies a union as the only well-defined way to type-pun to non character types.<p>&gt; The undefined-behaviour problem with integer overflow wouldn&#x27;t happen in machine code; that&#x27;s a consequence of C needing to run fast on lots of very different kinds of computer, which is a problem machine code doesn&#x27;t even try to solve<p>Some architectures trap on integer overflow, which I suspect is the reason why integer overflow is undefined rather than implementation defined. Certainly compilers <i>today</i> take advantage of the fact that it is undefined to make certain useful optimizations, but from what I can tell of the history that&#x27;s not why it was undefined in the first place.
评论 #28406999 未加载
zzo38computeralmost 4 years ago
I use C because I think that it is good (some improvements could be made, but the other programming languages which try to make C better tend to make many things worse in my opinion; I like many (but not all) of the features of (Digital Mars) D, though). I think that the worst feature of C is the confusing syntax for types. (Maybe the way to make a better one might be like &quot;LLVM with macros&quot;, although there are a few problems with LLVM too.)<p>Some compilers and libraries, such as GNU, do have some improvements. For example, in GNU you can make zero-length arrays (which I use sometimes), ?: without anything in between (which I use often), and some other things.<p>They say there is no object-oriented programming in C. Well, C doesn&#x27;t have object-oriented features, although you can still do some limited object-oriented stuff in cases where it is useful. For example, there is the stream object (called FILE); GNU has a fopencookie function to write your own implementation of the stream interface too, even though standard C doesn&#x27;t have that.<p>Object-oriented programming is good for some things but too often is overused in modern programming, I think. You shouldn&#x27;t need object-oriented programming for everything.<p>It is true that some of the undefined behaviour stuff is too confusing and perhaps should be changed; in some cases the compiler has options to control these things, such as -fwrapv (which I often use).<p>I like the string handling of C; you can easily skip some from the beginning, and can sometimes use the string functions with non-text data too, and it doesn&#x27;t use Unicode.<p>It says &quot;C lets you take the address of any variable you like&quot;, but this is not quite true. There is a &quot;register&quot; command which means that you cannot take the address of something.<p>I think that many things in C (both things that they mention and some that they don&#x27;t) (including pointer arithmetic, no bound checking, untagged unions, string handling, not using Unicode, setjmp&#x2F;longjmp, etc) are often advantages of C.
adamrezichalmost 4 years ago
great article, very informative and easy to read. I wish I would&#x27;ve known about this when I was learning C&#x2F;C++ (around the time it was published no less), coming from higher-level languages like C# and PHP.
评论 #28406146 未加载
DannyB2almost 4 years ago
The following is NOT a criticism of C. Just pointing out different problem domains.<p>&gt; Modern high-level languages generally try to arrange that you don&#x27;t need to think<p>&gt; or even know – about how the memory in a computer is actually organised<p>Modern high-level languages try to arrange that you don&#x27;t need to focus on the irrelevant. If you&#x27;re working on, say, an accounting system, memory layout is not part of the problem you are trying to solve.<p>For certain applications, C is simply too low level.<p>A language is too low level when it forces you to focus on the irrelevant.<p>For low level operations you probably cannot beat C.
评论 #28411390 未加载
评论 #28416006 未加载
评论 #28409159 未加载
markhahnalmost 4 years ago
Surprise: there&#x27;s a whole bunch of different reality under your the convenient illusions of your &quot;high level&quot; programming language.<p>Hardware is the reality. It&#x27;s not very much like the Java or Python programming model. We shouldn&#x27;t hide this from programmers.
评论 #28410559 未加载
1vuio0pswjnm7almost 4 years ago
&quot;The Python interpreter is written in C, for example.&quot;<p><a href="https:&#x2F;&#x2F;github.com&#x2F;RustPython&#x2F;RustPython" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;RustPython&#x2F;RustPython</a>
评论 #28411101 未加载
评论 #28413874 未加载
globular-toastalmost 4 years ago
&gt; No object orientation<p>I feel like C exists at a level below such concepts. Simply being able to define a function `void do_stuff(struct mystruct *obj)` opens the door to object-oriented style programming. A lot of people seem to define OOP by the presence of superficial stuff like inheritance, polymorphism etc, but really those are additional concepts that aren&#x27;t useful for every program. The real difference is mutating state on the heap. So you could say C <i>is</i> an object-oriented language, by default, because it doesn&#x27;t stop you doing this stuff, unlike a higher-level language like Clojure which simply doesn&#x27;t have mutation (for the most part). Or you could say C is a functional language because if you don&#x27;t explicitly pass pointers then you get copies. Really it&#x27;s both and it&#x27;s neither. It&#x27;s whatever you want it to be.
评论 #28405290 未加载
评论 #28406197 未加载