On Wed, 18 Dec 2013 13:11:58 +1100, Chris Angelico wrote: > On Wed, Dec 18, 2013 at 12:33 PM, Steven D'Aprano <st...@pearwood.info> > wrote: >> On Tue, 17 Dec 2013 19:32:20 -0500, Roy Smith wrote: >> >>> There's very few mysteries in C. >> >> Apart from "What the hell does this piece of code actually do?". It's >> no coincidence that C, and Perl which borrows a lot of syntax from C, >> are the two champion languages for writing obfuscated code. > > I thought APL would beat both of them, though you're right that the > International Obfuscoted Python Code Contest would be a quite different > beast. But maybe it'd be just as viable... a competent programmer can > write unreadable code in any language. > >> And "What does 'implementation-specific undefined behaviour' actually >> mean in practice?", another common question when dealing with C. > > You mean like mutating locals()? The only difference is that there are a > lot more implementations of C than there are of Python (especially > popular and well-used implementations). There are plenty of things you > shouldn't do in Python, but instead of calling them > "implementation-specific undefined behaviour", we call them "consenting > adults" and "shooting yourself in the foot". > >> And most importantly, "how many asterisks do I need, and where do I put >> them?" (only half joking). > > The one differentiation that I don't like is between the . and -> > operators. The distinction feels like syntactic salt. There's no context > when both are valid, save in C++ where you can create a "pointer-like > object" that implements the -> operator (and has the . operator for its > own members). > >>> You never have to wonder what the >>> lifetime of an object is, >> >> Since C isn't object oriented, the lifetime of objects in C is, um, any >> number you like. "The lifetime of objects in <some language with no >> objects> is ONE MILLION YEARS!!!" is as good as any other vacuously >> true statement. > > Lifetime still matters. The difference between automatic and static > variables is lifetime - you come back into this function and the same > value is there waiting for you. Call it "values" or "things" instead of > "objects" if it makes you feel better, but the consideration is > identical. (And in C++, it becomes critical, with object destructors > being used to release resources. So you need to know.) > >>> or be mystified by which of the 7 signatures of Foo.foo() are going to >>> get called, >> >> Is that even possible in C? If Foo is a struct, and Foo.foo a member, I >> don't think C has first-class functions and so Foo.foo can't be >> callable. But if I'm wrong, and it is callable, then surely with no >> arguments there can only be one signature that Foo.foo() might call, >> even if C supported generic functions, which I don't believe it does. > > Well, okay. In C you can't have Foo.foo().
Hah, well according to Paul Smith's example code you can. So either: - it's possible to be an experienced C programmer and still have fundamental gaps in your knowledge about basic concepts like dotted function calls; - or Paul's sample code was not what he claimed it to be; - or maybe the whole thing is undefined and we're all right! C both does and doesn't allow Foo.foo() function calls, *sometimes at the same time*. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
