Prev: Displaying property menu at runtime
Next: Delay Methods
From: Tom Shelton on 20 Jul 2010 16:16 ralph was thinking very hard : > On Tue, 20 Jul 2010 12:22:48 -0600, Tom Shelton > <tom_shelton(a)comcast.invalid> wrote: > > >> Ah... K & R C :) >> >> function(x) : int { >> return x; >> } >> >> Fun stuff that :) I can't remember if the above is completely accurate >> to the original C - but, in my first job I had to work with some old C >> code written on some old motorola unix sysstems... So, I got to play >> quite a bit with some of the old style K&R stuff - but that was almost >> 10 years ago now :) > > Don't remember any C dialects that used a colon in that context. But > there were a ton of compilers back then. > > Normally you would write that as ... > int function(x) > int x; > { > return x; > } That's it. I hadn't seen or worked with that stuff for 10 years... You tend to forget those little details :) > However, int was the default for both arguments and returns, so it > could have just been written ... > function(x) { > return x; > } > Sure, I only put the int in to show the typing :) > Later, "ANSI C" came along which allowed you to make your declarations > in place. ... > int function(int x) { > return x; > } > Yep... Thats the norm today. > It occasionally comes as a surprise to many programmers that there was > no C standard until 1986 (and not universally adopted till several > years after that), and "K&R" never was a true standard though often > labeled as one. However, most compilers consider the K&R as the core > language requirement, and most of what was to become "ANSI C" was > already in use via vendor extensions long before 1986. > That's how many standards evolve... > What fascinated me back then was how quickly "ANSI C" caught on, since > then as now the C community was populated with the most arrogant > pompus obnoxious malaperts ever to grace this planet. (And I should > know, I was one of them. <g>) > > Instead they vented their viciousness against the proper placement of > braces, indents, naming conventions, and editors. Dude... That's programmers in general. Language to most developers is a religion (My self included :)). I've had the oppertunity to work with several in my career, and I'm glad of it. -- Tom Shelton
From: Kevin Provance on 20 Jul 2010 19:16 "dpb" <none(a)non.net> wrote in message news:i245v7$tnj$2(a)news.eternal-september.org... : : I'd still wager the particular piece of code was written after its : author had just been indoctrinated in a defensive programming training : session or read the latest issue of one of the "C/C++ pitfalls" : columns... :) It's from MSFT's CAB SDK, actually. <g>
From: Dee Earley on 21 Jul 2010 04:21 On 20/07/2010 19:31, dpb wrote: > Tom Shelton wrote: >> It happens that dpb formulated : >>> Paul Clement wrote: >>> ... >>>> "If (FALSE)" in C++ evaluates to True or is it an invalid statement? >>>> ... >>> >>> Neither... >>> >>> As noted by somebody else, C++ initially (I don't know about latest >>> Standard) didn't have a Boolean intrinsic type and used the C >>> convention of any nonzero value is TRUE/0 is FALSE. >> >> C++ does define a true boolean now. But, the old convention seems to >> be still alive as far as I can tell. > > I don't think there are enough silver bullets or wooden stakes to ever > slay that particular creature...it is an idiom/convention too ingrained > into C/C++ vernacular to ever die. And, afaik, TRUE is still equated to > nonzero not only to the value of the _one_true_TRUE_ (tm) and will have > to remain because otherwise it breaks almost every C/C++ code in existence. I guess that's why C# became strongly typed and if() expected expressions to be explicitly true or false (e.g. compared to a specific value/range). -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems (Replies direct to my email address will be ignored. Please reply to the group.)
From: Paul Clement on 21 Jul 2010 08:51 On Tue, 20 Jul 2010 12:01:57 -0700, Karl E. Peterson <karl(a)exmvps.org> wrote: � > � > It's still backwards with respect to readability. ;-) � > � � > � Only if your screen is infinitely wide, or you just call functions with � > � very short parameter lists. � > � > Or you use line continuation characters. ;-) � � Generally, no. They make E&C a bit more troublesome. HTH! Works fine for me. :-) Paul ~~~~ Microsoft MVP (Visual Basic)
From: Karl E. Peterson on 21 Jul 2010 12:48
Paul Clement presented the following explanation : > On Tue, 20 Jul 2010 12:01:57 -0700, Karl E. Peterson <karl(a)exmvps.org> wrote: > > � > � > It's still backwards with respect to readability. ;-) > � > � > � > � Only if your screen is infinitely wide, or you just call functions with > � > � very short parameter lists. > � > > � > Or you use line continuation characters. ;-) > � > � Generally, no. They make E&C a bit more troublesome. HTH! > > Works fine for me. :-) You're using a different language, so that's totally irrelevant. -- ..NET: It's About Trust! http://vfred.mvps.org |