A somewhat "Meta" comment - I think the project to convert c to python is doomed. Idiomatic c is far ahead of what you can do with Python, in terms of low level power and pointer arithmetic. You would have to "guess" what the programmer was probably trying to do with a piece of code, and a mechanical translator would always miss forest for the trees. On Sep 19, 2011 5:41 PM, "Edward K. Ream" <[email protected]> wrote: > Recent work on Leo's new beautify-c command reminds me just how much I > despise the C language. > > 1. The Gnu indent program has a gazillion options, but apparently > *none* of them automatically insert curly brackets in code such as > this, taken from gperf-cc.c:: > > if (*str == *s && !memcmp (str + 1, s + 1, len - 1)) > return &wordlist[index]; > > The Gnu code and documentation talk out of both sides of their mouth > regarding how much of C indent actually does know about. > > In order for c-to-python to work properly, this must be changed to > something like:: > > if (*str == *s && !memcmp (str + 1, s + 1, len - 1)) > { > return &wordlist[index]; > } > > After quite a bit of work, beautify-c now does this. Yes, this means > that beautify-c *does* understand a bit of C. The parsing is flimsy, > and done at the token level. > > 2. Here is a cute C gotcha, taken from http://en.wikipedia.org/wiki/Indent_style > > A statement mistakenly inserted between the control statement and the > opening brace of the loop block turns the body of the loop into a > single trip:: > > for (int i = 0; i < total; i++) > whoops(bar); /* repeated total times */ > { > only_once(); /* Programmer intended this to be done total > times */ > } //for (i) <-- This comment is no longer valid, and is very > misleading! > > The compiler probably should issue a warning about this, especially in > situations, as shown, where the compound statement does not start with > any declarations. Maybe there already is such an option, buried in > the gazillions of gcc options... > > 3. The gnu indent program comes with a fairly complete set of > regression tests. They test that the present version of indent > generates the same output as the previous version did. This is better > than nothing, but these tests are in no way unit tests because they > test the program as a whole rather than testing the individual units > of the code. > > The tests are written as shell scripts, presumably because there > really isn't any framework in the Gnu project for unit testing C > code. To be fair, the Gnu project began life decades before unit > testing was invented. Still, the testing frameworks for Gnu indent > sucks by modern standards. One has more than the suspicion that C's > crappy qualities ensure that this will never change. > > All this highlights the major challenge in using larger units as the > unit of programming. The larger the units, the less flexible they > tend to be and the more difficult it is in practice either to > understand them or to use them constructively. > > However, these "challenges" do not mean that the project is a bad > idea. Indeed, this new point of view has already given Leo the > beautify-c and c-to-python commands. So maybe the "larger units" act > as more of an inspiration or catalyst rather than an actual source of > working code... > > Edward > > -- > You received this message because you are subscribed to the Google Groups "leo-editor" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]. > For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en. >
-- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
