Live data from Hacker News

Resume in C

gist.github.com

71–80 of 115 posts

Re: Resume in C

#71
post #17

Code review: * The struct members and variables pointing at string literals should be const. * People do break this all the time but typedefs ending in _t are reserved by POSIX. * Your C99 style struct initializers are valid but it's notable that one popular compiler, MSVC, will not like them. * If we are being idiomatic I would suggest pointer arithmetic to iterate instead of using a counter i.

> * Your C99 style struct initializers are valid but it's notable that one popular compiler, MSVC, will not like them. The code compiled fine with MSVC 2013 (simply 'cl resume.c'). No warnings at all.

I think they they implemented it very recently. 2012 will fail.

Re: Resume in C

#72
post #2

--- a/resume.c +++ b/resume.c @@ -118,7 +118,7 @@ void print_job(job_t * job) { } } -int main(int argc, char * argv) { +int main(int argc, char ** argv) { int i = 0; while (jobs[i]) { @@ -127,4 +127,4 @@ int main(int argc, char * argv) { } return 0; -} \ No newline at end of file +}

For those who don't write C, could you explain what is significant about this change? I'm guessing the earlier version was some kind of subtle bug?

You input arguments into your program using argc and argv. argc is number of arguments and argv is the list of arguments.

There is no string in c so you use char pointers instead. But in previous code he used char, which is usually defines a single string, but main actually inputs an array of string so it should have been char* (pointer to pointer of char, or pointer to 'string')

Basically he did something like this in Java

public static void main(String args)

instead of

public static void main(String args[])

Re: Resume in C

#73
post #70

Earlier quoted context omitted.

For those who don't write C, could you explain what is significant about this change? I'm guessing the earlier version was some kind of subtle bug?

char * argv is a pointer to a string (or a single character). char ** argv is a pointer to an array of pointers to strings. The latter is used since it allows for multiple arguments in (the number being `int argc`). This picture shows the second example in terms of pointers: http://www.londonquilters.org.uk/ctext/pic511.gif

Wouldn't second simply segfault when you try to access it?

Re: Resume in C

#74
post #34

Code review: * The struct members and variables pointing at string literals should be const. * People do break this all the time but typedefs ending in _t are reserved by POSIX. * Your C99 style struct initializers are valid but it's notable that one popular compiler, MSVC, will not like them. * If we are being idiomatic I would suggest pointer arithmetic to iterate instead of using a counter i.

> If we are being idiomatic I would suggest pointer arithmetic to iterate instead of using a counter i. Well, the CVE guys need to keep their job.

He's already iterating by using null termination instead of based on array bounds. I am suggesting he do it in the more common way.

On another topic, I have noticed you post this sort of trollish c bashing on almost every hn thread about c. It's fine that you prefer something else, but maybe time to give it a rest?

Re: Resume in C

#75
That's pretty great. It's too bad most HR tools would completely screw that nice formatting, but I'd definitely bring printed copies of that into a dev role interview! That'd break the ice right away.

Re: Resume in C

#77

Code review: * The struct members and variables pointing at string literals should be const. * People do break this all the time but typedefs ending in _t are reserved by POSIX. * Your C99 style struct initializers are valid but it's notable that one popular compiler, MSVC, will not like them. * If we are being idiomatic I would suggest pointer arithmetic to iterate instead of using a counter i.

I think we have bigger problems to address before we get to these minor contrivances.

This resume is not web scale enough. We need to wrap the resume in node.js so it can be non-blocking for big data. It should be written in an esoteric JS variant and transpiled to ES5 because everyone knows ES5 is unreadable. Oh and the storage of his education and job history should really be stored in a NoSQL database like MongoDB that way he can shard asynchronously. When he presents the resume in his interviews it should be wrapped in a webkit container.

Re: Resume in C

#78
post #5

Wow, I didn't know this was valid C code, it's pretty convenient. school_t uiuc = { .school = "University of Illinois at Urbana-Champaign", .location = "Urbana, IL", .program = "BS Computer Science", .started = 1251158400, .left = 1336608000, .accomplishments = { "Minor in International Studies in Engineering, Japan", "Focused on systems software courses", NULL } };

I highly recommend "21st Century C" ( http://shop.oreilly.com/product/0636920025108.do ) as a tour of modern C programming, including use of C99 features. It goes over C tooling (profiling, debugging, testing, cross-platform deployment), and explores C99.

There's a newer edition available which has been published recently:

http://shop.oreilly.com/product/0636920033677.do

Re: Resume in C

#79
post #5

Wow, I didn't know this was valid C code, it's pretty convenient. school_t uiuc = { .school = "University of Illinois at Urbana-Champaign", .location = "Urbana, IL", .program = "BS Computer Science", .started = 1251158400, .left = 1336608000, .accomplishments = { "Minor in International Studies in Engineering, Japan", "Focused on systems software courses", NULL } };

They're used heavily in Linux device drivers, amongst other things - here's just one example:

https://github.com/torvalds/linux/blob/master/drivers/video/...

Re: Resume in C

#80

"They're all while loops because shut up, you're overthinking a joke." Just curious what is wrong with all the while loops ?

Nothing, really.

There's an argument that using a 'for' construct groups together the details of the loop (initialization, the loop condition, iteration update), which can aid readability.

(You don't have to search the loop body to find how things change between iterations)

Of course, nothing forces a for() loop to have iteration behavior entirely dependent on only what's in the 'for'. In my experience this seems to be discouraged, however, preferring to use 'for' only when there is a predictable and simple iteration pattern.

In the end, it's just a matter of preference and style. :)

Post reply on HN