Live data from Hacker News

C Programming Puzzlers

stevenkobes.com

21–30 of 32 posts

Re: C Programming Puzzlers

#21

Stopped at #3. It seems incorrect. The answer states that foo returns x to the power of n. But I ruled that answer out since any 0 or negative n is going to return 1. edit: added emphasis

You could have ruled it out from the function signature alone:

    int foo(int x, int n);
This cannot be x^n, nor n^x or x*n.

Re: C Programming Puzzlers

#22
post #20
post #6

Earlier quoted context omitted.

These are not the problem with C. Things like a lack of support for functional programming constructs and more powerful manipulation of structs (e.g. iterating over fields and inspecting variable types) would be much more improvement to C than minor cosmetic changes that would hide the details that this quiz asks about.

You've obviously know very little about the motivation of Go then...

Go was obviously created in response to the problems with C; I was stating that this exercise in particular isn't demonstrative of those problems.

Re: C Programming Puzzlers

#24

In the answer to 9 I don't see why 'Evaluating ++i + ++i would produce undefined behavior'

There's no http://en.wikipedia.org/wiki/Sequence_point between the two increments, so the standard allows the compiler to do pretty much anything, even http://catb.org/jargon/html/N/nasal-demons.html. The way I've heard it, these operators were added to take advantage of pre- and post-increment hardware support in the PDP-11 (forty years ago!), and everyone just knew what would happen, but ANSI later wanted compilers to have enough latitude to take advantage of other hardware which behaves differently.

Re: C Programming Puzzlers

#25
post #18
post #11

Earlier quoted context omitted.

It was not only possible to initialize arrays like that in C89, that method is often referred to as "C89-style". Also, let's not forget what the C standard says about integer sizes, which is that A) It is guaranteed that sizeof char == 1 B) It is guaranteed that the following holds true: sizeof char So it's always completely unrealistic to assume anything about the size of these types on any system, except for the gu…

A char might always be one byte but one byte isn't necessarily 8 bits. I'm often puzzled by the fact that the size of basic datatypes isn't platform independent. If I need to count to x I, more often than not, need to count to x on all platforms. Yet for some reason that is something that varies on platform. Yes, there are of course times when this is useful but that should be the exception (right?). And apparently t…

I think the idea originally was that int would usually be the preferred "natural" size for arithmetic on any given platform. Longer sizes are available when you need greater range, and smaller sizes are available when you're trying to conserve memory, but both may be slower than int (because of the possible need for multiple-word arithmetic in the longer sizes, and the possible need for sub-word operations in the smaller sizes).

So int is for things like loop indices, where efficiency of arithmetic is more important than size in memory.

Re: C Programming Puzzlers

#26
post #18
post #11

Earlier quoted context omitted.

It was not only possible to initialize arrays like that in C89, that method is often referred to as "C89-style". Also, let's not forget what the C standard says about integer sizes, which is that A) It is guaranteed that sizeof char == 1 B) It is guaranteed that the following holds true: sizeof char So it's always completely unrealistic to assume anything about the size of these types on any system, except for the gu…

A char might always be one byte but one byte isn't necessarily 8 bits. I'm often puzzled by the fact that the size of basic datatypes isn't platform independent. If I need to count to x I, more often than not, need to count to x on all platforms. Yet for some reason that is something that varies on platform. Yes, there are of course times when this is useful but that should be the exception (right?). And apparently t…

[deleted]

Re: C Programming Puzzlers

#27
post #18
post #11

Earlier quoted context omitted.

It was not only possible to initialize arrays like that in C89, that method is often referred to as "C89-style". Also, let's not forget what the C standard says about integer sizes, which is that A) It is guaranteed that sizeof char == 1 B) It is guaranteed that the following holds true: sizeof char So it's always completely unrealistic to assume anything about the size of these types on any system, except for the gu…

A char might always be one byte but one byte isn't necessarily 8 bits. I'm often puzzled by the fact that the size of basic datatypes isn't platform independent. If I need to count to x I, more often than not, need to count to x on all platforms. Yet for some reason that is something that varies on platform. Yes, there are of course times when this is useful but that should be the exception (right?). And apparently t…

[deleted]

Re: C Programming Puzzlers

#28

In the answer to 9 I don't see why 'Evaluating ++i + ++i would produce undefined behavior'

There's no http://en.wikipedia.org/wiki/Sequence_point between the two increments, so the standard allows the compiler to do pretty much anything, even http://catb.org/jargon/html/N/nasal-demons.html . The way I've heard it, these operators were added to take advantage of pre- and post-increment hardware support in the PDP-11 (forty years ago!), and everyone just knew what would happen, but ANSI later wanted compiler…

Just when I thought (after completing the puzzles) that C is reasonably reasonable language, I learn that the execution order of 'f()+g()' is unspecified. Wow!

Re: C Programming Puzzlers

#29

Stopped at #3. It seems incorrect. The answer states that foo returns x to the power of n. But I ruled that answer out since any 0 or negative n is going to return 1. edit: added emphasis

You could have ruled it out from the function signature alone: int foo(int x, int n); This cannot be x^n, nor n^x or x*n.

"You could have ruled it out from the function signature alone" - kindly elaborate.

Re: C Programming Puzzlers

#30

Earlier quoted context omitted.

You could have ruled it out from the function signature alone: int foo(int x, int n); This cannot be x^n, nor n^x or x*n.

"You could have ruled it out from the function signature alone" - kindly elaborate.

The return type is too small
Post reply on HN