101–110 of 115 posts
I still have a copy of it online at: http://old.bertjwregeer.com
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 } };
My gcc required me to put { } around any fields of unnamed unions. [gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC)]
Earlier quoted context omitted.
union { char* x; char* y; }; ... if (/*smth*/) { x = "Hello"; } else { y = strdup("Hello"); } ... if (/*smth*/) { free(y); } It is possible to screw up the condition to calling free(), especially in more involved code.
And how is this different from char* x; ... if (/*smth*/) { x = "Hello"; } else { x = strdup("Hello"); } ... if (/*smth*/) { free(x); } ? Maybe I'm slow, but I don't see how the union makes a difference.
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 } };
It's a C99 feature (I think?) -- designated literals. They're absolutely wonderful.
Earlier quoted context omitted.
What are the odds this turns out to be practical advice for this example? Are you going to write all your loops like that because someone at Intel told you it was a good idea, or are you going to measure it when it's seen to be a problem?
What are the odds this turns out to be practical advice for this example? High. E.g. gcc 4.8.2 vectorizes this on my machine ( -march=native -mtune=native -O3 -ffast-math -ftree-vectorizer-verbose=1 ): for (size_t i = 0; i (a and b have the same length) But doesn't vectorize: for (double *p = a; p (Yes, you can make an extra pointer for b, but just for the sake of the example.) tl;dr: your compiler writer probably kn…
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.
When I was in university, I did something similar in Python. I printed it off in color and brought it to a career fair. One guy loved it excitedly. But I didn't hear back from him :(. And that's the story of how I cam to work in Java ;)
0) Have brought a pen or cell phone.
1) Always get their business card or contact info.
2) When you get someone's business card, always write down where you met them and what you want to ask or show them. Otherwise, you end up with a pile of cards and no memory of who they were from.
2.1) If you actually had them type their email into your phone, sketch out the email, but don't send it.
3) follow up within 3 days or you'll forget.
Earlier quoted context omitted.
I think Peter Van Der Linden would agree. He states in Deep C Programming that the separation of the compiler from the linter, and I assume by extension semantic analysis tools as well, was a mistake in retrospect. It's good to see that compilers like Clang are bringing them back together in a way. One does have to be more careful when writing C but I don't "blame" C for unsafe code. It's the kind of language that as…
Yes lint does exist since 1979 and Ritchie remarks in his notes that it was already a need back then. The problem got worse when C dialects started to appear outside UNIX without Lint. Or the compiler vendors selling it separately of the compiler. The problem with languages that trust the developer is that they are based on a set of false premises, namely: - the team is composed from top skill developers - the team n…
However I think you have some false premises: the Linux kernel is huge, has a fairly high turn-over in contributors, and is written in C. Hardly anyone "knows" the entire code base. I've yet to meet anyone who can even name all of the compile switches... some 1000+ of them. Yet it's hard to argue that it's not useful or impossible to contribute to. I'm not a genius and if I can figure it out I'm sure I can teach others.
Yes, you can write bad code in C. I don't think you can blame C for human error. There are sins of commission and those of omission and the ANSI C specification documents them both quite well. Designing a language that protected an ignorant and uneducated programmer from making mistakes wasn't one of their goals I'm afraid.
Earlier quoted context omitted.
Yes lint does exist since 1979 and Ritchie remarks in his notes that it was already a need back then. The problem got worse when C dialects started to appear outside UNIX without Lint. Or the compiler vendors selling it separately of the compiler. The problem with languages that trust the developer is that they are based on a set of false premises, namely: - the team is composed from top skill developers - the team n…
I don't understand your false premises. I've never had C marketed to me as a language that promised safe, perfect code. It does what it says on the tin. However I think you have some false premises: the Linux kernel is huge, has a fairly high turn-over in contributors, and is written in C. Hardly anyone "knows" the entire code base. I've yet to meet anyone who can even name all of the compile switches... some 1000+ o…
http://www.cvedetails.com/vulnerability-list/vendor_id-33/pr...