61–70 of 88 posts
maybe the biggest improvement in c programming over the last decade is valgrind, making purify-like debugging available to everyone. it's completely removed a whole class of annoyingly hard to fix bugs from my code.
And that's without the commercial tools such as Coverity.
>> The C version is functional but will probably make more experienced C programmers cringe. Oh boy. This looks like the type of C code I write. Could some experienced C programmer please point out what parts are cringe inducing ?
Not being a experienced C programmer by any measure, but this doesn't look right to me: https://github.com/thraxil/boggle/blob/master/boggle.c#L92 struct foo f() { struct foo f; return f; } isn't returning a stack-allocated struct a bad idea?
#include
struct foo { char space[1024]; };
struct foo f()
{
struct foo f;
printf("address of f is %p\n",&f);
return f;
int main()
{
struct foo g;
g = f();
printf("address of g is %p\n",&g);
return 0;
produces this output:
address of f is 0x7fbfffec30
address of g is 0x7fbffff050
Earlier quoted context omitted.
One can always write proper C programs without Valgrind: it is "just" a ( really useful) debugging tool. The utility of it is that instead of spending days trying to track down any mallocs missing frees, one can just run Valgrind to find them and their locations straight away.
I guess what my grandparent said, albeit in a slightly dismissing tone, is that relying on tools like Valgrind or Purify to produce good code makes for weak programmers. The days spent trying to track down missing frees can be reduced to hours with practice, and the programmer skilled in this hunt is less likely to forget the free in the first place. (As opposed to the programmer relying on Valgrind and not caring mu…
I absolutely love writing C. Up until late 2011, it was by far the language I used the most. I am now learning Lisp (not exactly, I'm using Lisp in SICP), and use Python more than before. One thing I realized, is that reading C is more tedious than code in other languages. Sure that's a gross generalization and is not true for every piece of code out there. However, I find I have less troubles picking up a Python pro…
The problem with the C preprocessor is that it's sat in a "sour spot" where it's often possible to use it for a task but only by bending it so far that the result is pretty ugly and not very comprehensible. If the preprocessor were less powerful it would be obvious you needed to use a different tool; if it were more powerful it wouldn't result in ugly messes; but it's sat in the sour spot in the middle. (Make is anot…
I absolutely love writing C. Up until late 2011, it was by far the language I used the most. I am now learning Lisp (not exactly, I'm using Lisp in SICP), and use Python more than before. One thing I realized, is that reading C is more tedious than code in other languages. Sure that's a gross generalization and is not true for every piece of code out there. However, I find I have less troubles picking up a Python pro…
The one thing that I have trouble with in Python projects is that it can be very difficult to figure out where the actual object is from that is being imported. from somedir.somefile import objectX Then when you go to somedir.somefile you find out objectX is nowhere to be found only to figure out later that it is dynamically created and added to that namespace and it can be imported in the file you've been reading be…
The inspect module doc page is of great help: http://docs.python.org/library/inspect.html
I started with assembly language and I thought C was heaven. Of course, there are easier languages, there are more powerful languages, there are fancier languages and whatnot. I like Python and I adore Lisp. But I still love C most. C is the sweet spot where I can extend my programs to do high-level stuff while still keep my hands down on the actual hardware I'm programming. I like that a lot, probably because I grew…
My intro course in college was run this way as well and to this day, I'm very glad to have started my career bottom up instead of top down...
Earlier quoted context omitted.
Tools only created to solve the lack of safe constructs in C. C made lots of sense in the context it was developed, but the world would be better if we had safer systems programming languages. Valgrind, purify and friends are required to C, the same way Java requires IDEs, to improve language usability. Have said this, the new trend in having static analysis tools integrated in the development process, like Clang, Ec…
C is popular, good enough, portable, and fast. Skilled C programmers do not need profilers, bounds checkers and memory leak detectors. They help some people, though, no doubt. When size and speed matters, as in Operating Systems, C has won and continues to win the survival of the fittest competition. Almost all the programs I use are C (and/or C++): bash, linux, perl, firefox, awk, sed, grep, apache, mysql, etc. I as…
- Donald Knuth (wrote a study on profilers)
- Rob Pike (wrote a profiler, 'though for FORTRAN)
- Brian Kernighan (used a profiler to double the speed of his AWK interpreter)
I wonder who you consider a skilled C programmer, if not K from K&R.
It's funny, because I recently tackled this exact same problem in Python as well. And guess what my first step was? Writing a prefix tree implementation, in order to use the exact same approach the author took in C. It never seriously occurred to me to do it any other way. It may be because I recently got into C as well after spending years with only Python, but honestly I think I would have done the same thing befor…
Well I didn't get back into C and last time I had to solve a similar problem typed: from Bio.trie import trie
I started with assembly language and I thought C was heaven. Of course, there are easier languages, there are more powerful languages, there are fancier languages and whatnot. I like Python and I adore Lisp. But I still love C most. C is the sweet spot where I can extend my programs to do high-level stuff while still keep my hands down on the actual hardware I'm programming. I like that a lot, probably because I grew…
Reading DJB's code can be both awesome in that his code is written clearly and neatly, yet at the same time it can be an excercise in frustration because he has foregone most of the standard library and written his own (especially string management, which is superior, in my humble opinion), so it can look foreign or weird to people looking at it. The source to qmail/daemontools is a pleasure to read though and having…