Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Descent to C (2013)

chiark.greenend.org.uk

Post reply on HN
Print view View original

21–30 of 96 posts

Re: The Descent to C (2013)

#21

Post by lifthrasiir »

smcameron wrote: post #4

> (In fact, that's what array[i] means – the language defines it to be a synonym for *(array+i).) To really drive home the primitiveness of C arrays, should probably also mention that, because addition is commutative, you could also write i[array] and somewhat surprisingly, it will compile, and work, and it means "*(i + array)" which is equivalent to "*(array + i)" But nobody really does that, because that would be k…

If array were, say, uint32_t* then what `*(array + i)` would do is actually `(intptr_t)array + i * 4` and not `(intptr_t)array + i`. If array were uint16_t* then it's `(intptr_t)array + i * 2`. In short the way the pointer arithmetic gets translated greatly depends on the type of the pointee and thus is not as primitive as it can be.

Re: The Descent to C (2013)

#22

Post by dahfizz »

bachmeier wrote: post #10
smcameron wrote: post #4

> (In fact, that's what array[i] means – the language defines it to be a synonym for *(array+i).) To really drive home the primitiveness of C arrays, should probably also mention that, because addition is commutative, you could also write i[array] and somewhat surprisingly, it will compile, and work, and it means "*(i + array)" which is equivalent to "*(array + i)" But nobody really does that, because that would be k…

> nobody really does that, because that would be kind of insane Yeah. That's why people don't do things in C. It's more like most C programmers probably weren't aware of this. After your comment, we'll start to see C codebases everywhere with that.

I learned of this in college. Most C programmers know how C arrays work.

Re: The Descent to C (2013)

#23

Post by tialaramex »

colejohnson66 wrote: post #12
bachmeier wrote: post #10

Earlier quoted context omitted.

> nobody really does that, because that would be kind of insane Yeah. That's why people don't do things in C. It's more like most C programmers probably weren't aware of this. After your comment, we'll start to see C codebases everywhere with that.

This “trick” has been know at least as far back as 2008: https://stackoverflow.com/questions/381542/with-arrays-why-i...

It's actually spelled out in K&R in more technical language:

"The array subscripting operation is defined so that E1[E2] is identical to *(E1+E2). Therefore, despite its asymmetrical appearance, subscripting is a commutative operation."

(my emphasis)

Re: The Descent to C (2013)

#24

Post by lifthrasiir »

colejohnson66 wrote: post #12
bachmeier wrote: post #10

Earlier quoted context omitted.

> nobody really does that, because that would be kind of insane Yeah. That's why people don't do things in C. It's more like most C programmers probably weren't aware of this. After your comment, we'll start to see C codebases everywhere with that.

This “trick” has been know at least as far back as 2008: https://stackoverflow.com/questions/381542/with-arrays-why-i...

One of the very first IOCCC winners used the trick in 1984 (1984/anonymous):

    int i;main(){for(;i["]

Re: The Descent to C (2013)

#25

Post by dahfizz »

jimbob45 wrote: post #14
adamrezich wrote: post #11

great article, very informative and easy to read. I wish I would've known about this when I was learning C/C++ (around the time it was published no less), coming from higher-level languages like C# and PHP.

How is C# higher-level than C? I'm not aware of anything you can do in C that you can't do in C# as a first-class feature. Edit: I define the level of a language as the lowest-possible feature. I guess others define level as the highest-possible feature? I don't really know who's right here.

C# has exceptions, OO classes / interfaces, `unsafe`, etc. Lots of features that make it a higher level language than pure C.

Re: The Descent to C (2013)

#26

Post by tialaramex »

PEJOE wrote: post #9
globular-toast wrote: post #7

> No object orientation 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't useful for every program. The real difference is mut…

That you can do functional or OOP in C does not make C either kind of language, it just means that C is flexible enough that you can make the computer do things the way you want it to, no matter what that means, and other languages purposefully prevent you from doing what you might want to do. C++ is object oriented not because it has compile time support for polymorphism or any of that other bad programming practice…

Hmm. In what sense do you believe that class has a code section that "lives" on the stack or heap?

On a modern system you can't usually do that because of W^X rules (also on a non-x86 modern system the performance would be abysmal if you tried because why waste transistors supporting something only crazy people would want?)

So perhaps notionally in the abstract machine if I have sixteen Clowns in a C++ vector there are sixteen copies of the Clown method squirt_water_at() in the vector too, but I assure you all the compiler emits is one copy of squirt_water_at() for Clowns, to the text segment with the rest of the program code, and maybe if Clowns are virtual, a pointer to a table of such functions lives with each Clown just in case there are Jugglers and LionTamers in the vector too - although compilers can sometimes figure out a rationale for not bothering.

Re: The Descent to C (2013)

#27

Post by lebuffon »

smcameron wrote: post #4

> (In fact, that's what array[i] means – the language defines it to be a synonym for *(array+i).) To really drive home the primitiveness of C arrays, should probably also mention that, because addition is commutative, you could also write i[array] and somewhat surprisingly, it will compile, and work, and it means "*(i + array)" which is equivalent to "*(array + i)" But nobody really does that, because that would be k…

Interesting. Looks like Forth. :-)

Re: The Descent to C (2013)

#28

Post by kzrdude »

lifthrasiir wrote: post #21
smcameron wrote: post #4

> (In fact, that's what array[i] means – the language defines it to be a synonym for *(array+i).) To really drive home the primitiveness of C arrays, should probably also mention that, because addition is commutative, you could also write i[array] and somewhat surprisingly, it will compile, and work, and it means "*(i + array)" which is equivalent to "*(array + i)" But nobody really does that, because that would be k…

If array were, say, uint32_t* then what `*(array + i)` would do is actually `(intptr_t)array + i * 4` and not `(intptr_t)array + i`. If array were uint16_t* then it's `(intptr_t)array + i * 2`. In short the way the pointer arithmetic gets translated greatly depends on the type of the pointee and thus is not as primitive as it can be.

I think it depends on the coder if it makes more sense to them to write out the scale by element size or not. For me, the `+` is just pointer arithmetic and of course an addition in number of elements (so I don't think of the scaling at all).

Just saying that "actually it's just array + i" makes more sense - for me(!).

Re: The Descent to C (2013)

#29

Post by jakeva »

lifthrasiir wrote: post #24
colejohnson66 wrote: post #12

Earlier quoted context omitted.

This “trick” has been know at least as far back as 2008: https://stackoverflow.com/questions/381542/with-arrays-why-i...

One of the very first IOCCC winners used the trick in 1984 (1984/anonymous): int i;main(){for(;i["]

what does this program do? i compiled it and ran it and got no output. i hope i haven't fork bombed myself or something

Re: The Descent to C (2013)

#30

Post by Koshkin »

jimbob45 wrote: post #14
adamrezich wrote: post #11

great article, very informative and easy to read. I wish I would've known about this when I was learning C/C++ (around the time it was published no less), coming from higher-level languages like C# and PHP.

How is C# higher-level than C? I'm not aware of anything you can do in C that you can't do in C# as a first-class feature. Edit: I define the level of a language as the lowest-possible feature. I guess others define level as the highest-possible feature? I don't really know who's right here.

In the same way as C is a higher-level language compared to assembler.
Post reply on HN