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

C puzzles

gowrikumar.com

Post reply on HN
Print view View original

81–90 of 97 posts

Re: C puzzles

#81

Post by Koshkin »

btilly wrote: post #32
CapacitorSet wrote: post #3

I really dislike his choice of coding style. Compare: int CountBits (unsigned int x ) { static unsigned int mask[] = { 0x55555555, 0x33333333, 0x0F0F0F0F, 0x00FF00FF, 0x0000FFFF } ; int i ; int shift ; /* Number of positions to shift to right*/ for ( i =0, shift =1; i > shift) & mask[i]); return x; } as opposed to: int countBits (unsigned int x) { static unsigned int mask[] = { 0x55555555, 0x33333333, 0x0F0F0F0F, 0x0…

Really, are we going to argue about the One True Formatting style? A 2 space indent is more compact. A 4 space indent is more readable for older people. Putting braces around blocks on their own lines highlights blocks. Putting braces inline is again more compact. Outdenting declarations highlights an important piece of information. Keeping them in line focuses on blocks. And so on. None of these choices are particul…

> A 2 space indent... A 4 space indent...

I have been wondering for a while now why is it that everybody is stuck with this typewriter/punchcard mentality and assumes that only a fixed-width (non-proportional) font could be used to display program code on a computer screen. Would it not be more appropriate, in this century, to realize that since indentation (and spacing in general) is essentially something that only pertains to the graphical representation of program's code, it should be left to the editor/viewer software (and its user) to set, given a single tab or space character, the number of pixels (or inches or any other unit of length) that should be used to represent the indentation or white space? This should have nothing to do with the width of a character, and therefore using modern proportional fonts should be just as convenient and natural as it is when using a word processor.

Re: C puzzles

#82

Post by hatsunearu »

innocenat wrote: post #44
mikeash wrote: post #14

Earlier quoted context omitted.

There's no #include first, so you get an implicit prototype for malloc. With an implicit prototype, the function is assumed to return int. The cast then converts the returned int to int*. This works on 32-bit where int is the size of a pointer, but on 64-bit with 32-bit ints, the top half of the pointer gets chopped off and you end up with a nonsense value. This is why it's considered bad form to cast the result of m…

Oh so he meant to say Intel 64/amd64. IA-64 is Intel Itanium. I just skipped it because I know nothing about IA-64 at all.

Worked on my x64 machine and my IRC's. I googled it (just google parts of the introducing text) and apparently it's related to IA-64 architecture specifics.

Re: C puzzles

#83

Post by adekok »

Fifer82 wrote: post #12
CapacitorSet wrote: post #3

I really dislike his choice of coding style. Compare: int CountBits (unsigned int x ) { static unsigned int mask[] = { 0x55555555, 0x33333333, 0x0F0F0F0F, 0x00FF00FF, 0x0000FFFF } ; int i ; int shift ; /* Number of positions to shift to right*/ for ( i =0, shift =1; i > shift) & mask[i]); return x; } as opposed to: int countBits (unsigned int x) { static unsigned int mask[] = { 0x55555555, 0x33333333, 0x0F0F0F0F, 0x0…

I prefer the one who takes a dedicated line for the `{`. It leaves me the ability to group together chunks of related functionality, whereas the latter method throws out that option instantly.

This is a religious war. :( For me, having a screen full of (mostly) blank lines containing { and } is terrible. It means that the information density of the screen is low, to the point of being useless.

Re: C puzzles

#84

Post by gowrikumar »

bogomipz wrote: post #63

These are interesting. Does anyone know if the explanations are provided anywhere? Or at least what the insight into the why of some of these?

Some of the questions have a pointers to the reading material. I will try to get the answers updated this week.

Re: C puzzles

#85

Post by gowrikumar »

CapacitorSet wrote: post #3

I really dislike his choice of coding style. Compare: int CountBits (unsigned int x ) { static unsigned int mask[] = { 0x55555555, 0x33333333, 0x0F0F0F0F, 0x00FF00FF, 0x0000FFFF } ; int i ; int shift ; /* Number of positions to shift to right*/ for ( i =0, shift =1; i > shift) & mask[i]); return x; } as opposed to: int countBits (unsigned int x) { static unsigned int mask[] = { 0x55555555, 0x33333333, 0x0F0F0F0F, 0x0…

I have had prepared slide set explaining the algorithm a while back here. May be useful for understanding the code: http://www.slideshare.net/gkumar007/counting-bits-presentati...

Re: C puzzles

#86

Post by keithnz »

sdegutis wrote: post #58
GrinningFool wrote: post #4

Fun stuff , thanks for posting it. I've been getting back into C lately, iterating through implementing common algorithms from scratch. In spite of the kinds of easy to make mistakes that are highlighted on the site, I'm finding it to be a lot of fun - not having my hand held by frameworks that try to stop me from shooting myself in a foot is refreshing and brings back that feeling of "I can build whatever the hell I…

You know, I have a love/hate relationship with C kind of like what you described. In general I hate how hard it is to use and how easy it is to make gigantic mistakes in it. But on the other hand it's so raw and pure that it makes it a fun challenge. Recently I decided to write a SNES-era video game in C using SDL2, so we'll see how that goes. Maybe my mind will change as I make progress on that front.

Part of my projects, I write C for embedded devices. It's actually not so hard if you adopt common idioms for doing things. Most of the puzzle type problems go out of their way to cause problems. Things like the MISRA C coding standard will keep you out of most trouble, though I ignore some of their advice.

Re: C puzzles

#87

Post by _RPM »

For the hello-out one, it's because stderr isn't buffered output, while stdin is. You can change this by calling setbuf(stdout, NULL);

Re: C puzzles

#88

Post by Fifer82 »

lisper wrote: post #51
bryondowd wrote: post #47

Earlier quoted context omitted.

If all { and } are on their own lines, then it modestly simplifies the ability to visually scan from one to its match because they appear on the same column with nothing between them.

But if your code is properly indented then you can do the same thing with the first character in the line containing the open brace: if (foo) { | blah; | blah; | blah; | blah; | blah; | blah; | blah; | blah; | blah; }

I honestly think it may just be something physical in the brain!

That style, especially in other languages with callback hell, feels tight. I can't breathe...

That feeling of can't breathe is far far more of a potent dagger in the heart, than simply scrolling one extra mouse wheel in a Class.

The open and airy, instantly identifiable shape of the code is just like the fresh sea air.

An old friend at work used to call that style "NotepadOpenBinaryFileStyle". The reason that stuck with me was due to its accuracy!

Re: C puzzles

#89

Post by lisper »

Fifer82 wrote: post #88
lisper wrote: post #51

Earlier quoted context omitted.

But if your code is properly indented then you can do the same thing with the first character in the line containing the open brace: if (foo) { | blah; | blah; | blah; | blah; | blah; | blah; | blah; | blah; | blah; }

I honestly think it may just be something physical in the brain! That style, especially in other languages with callback hell, feels tight. I can't breathe... That feeling of can't breathe is far far more of a potent dagger in the heart, than simply scrolling one extra mouse wheel in a Class. The open and airy, instantly identifiable shape of the code is just like the fresh sea air. An old friend at work used to call…

Heh, I have a similar visceral reaction to the "open" style: what a waste of precious screen real estate. Now my eyes have to scan a much bigger area in order to see all the relevant information, and I might even have to waste time scrolling around to find what I'm looking for that I would not have had to if only all that unnecessary white space were eliminated.

Putting the brace on the same line also makes it easier to grep for function definitions.

So why not:

    if (
        x>y
       )
    {
      code;
      ...
     }
    }
(I've actually seen that in real code.)

Re: C puzzles

#90

Post by ndesaulniers »

mikeash wrote: post #52
innocenat wrote: post #44

Earlier quoted context omitted.

Oh so he meant to say Intel 64/amd64. IA-64 is Intel Itanium. I just skipped it because I know nothing about IA-64 at all.

He might have meant IA-64. The problem is likely to appear on any 64-bit architecture where int is smaller than a pointer, which is most (or all?) of them. Depending on the compiler and such, big discussion below if you're interested in boring details.

inserts big discussion for those interested

https://nickdesaulniers.github.io/blog/2016/05/30/data-model...

Post reply on HN