From: Allin C. <cot...@wf...> - 2007-11-28 00:42:57
|
On Tue, 27 Nov 2007, Hans-Bernhard Bröker wrote: > Allin Cottrell wrote: > > On Tue, 27 Nov 2007, Hans-Bernhard Bröker wrote: > > > > Same difference. Adding a variable at the end of the struct > > > has the same net effect, and the benefit of being less > > > risky. An unsupported variable automatically defaults to > > > zero, but an unsupported function defaults to an invalid > > > function pointer, which is generally unsafe to use. > > > I thought things were set up so that an unsupported function > > defaults to a null pointer (and my proposed code tests for > > that). > > Correct. More to the point, as long as new elements only get > added at the end of the struct, every unsupported member > defaults to a zero of the approriate type. Numeric variables > end up as zero, pointers as null pointers. > > > On the other hand, having the scale variable default to zero > > would not be good at all -- it should really default to 1, > > though I suppose one could work around a broken default of 0. > > Testing for variable == 0 is no harder than testing for function > pointer == 0. Granted; we can assume that scale == 0 means scale == 1. Should I take this comment as a "vote" in favor of handling this issue by means of a new variable in the terminal structure rather than a new function pointer? If so, I have only one other point to suggest to the contrary. That is, Ethan has (I think) alluded to things other than a simple scale factor, that specific terminals might want to provide. A function pointer is inherently extensible, but if we add a variable to handle scale, it's possible we might end up having to add more variables to cope with fancier variants on the basic idea. I'll be travelling from tomorrow till mid-December, so please don't take lack of further responses on this topic to indicate lack of interest! I really would like to see this settled, one way or the other. -- Allin Cottrell Department of Economics Wake Forest University, NC |