Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Passing values from structure arrays to a generic geometrical mean function Date: Sat, 28 Jan 2017 13:01:36 -0800 Organization: None to speak of Lines: 79 Message-ID: References: <8abfc054-e7c3-498c-a7b4-8e7471f57ac6@googlegroups.com> <0a48658d-968a-4ddf-8c3e-5a856e298ec1@googlegroups.com> <87lgtwxxjp.fsf@bsb.me.uk> <3a8dc13f-3e11-4e38-9717-152d7ee7666d@googlegroups.com> <8737g4xgtk.fsf@bsb.me.uk> <87y3xvv237.fsf@bsb.me.uk> <5abf342b-6381-4b6e-b77d-2ffb3cc31666@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="4f5353bf08e7d034cfc50822033a818b"; logging-data="21955"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19syQ85yfJAkxPunOk5Vjb5" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:nHDvNrGEdhVw6WVf+SRGEvNZKqA= sha1:kb8vZadU0IkKWzgMX7kuahs6ojs= Xref: csiph.com comp.lang.c:102660 Malcolm McLean writes: [...] > You need to think it terms of bit-based programming. Bit-based programming > says the data is bits, the high-level concepts languages sometimes build > over the bits a superstructure we can ignore without doing any damage, > as long as we are aware what the bits are and what they mean. > > In your case, the bits are doubles in the machine native format (probably > 64 bit IEEE). You've got a structure with about a dozen (my count is 19) > of them, and, fortunately, no other data types. If we declare an > array we have N blocks of 19 doubles > > {19 doubles}{19 doubles} .... {19 doubles} You're dealing with objects (variables, struct members, array elements) and their values. Bitwise representation is just a low-level mechanism for implementing those values. The compiler takes care of the bitwise representation for you, precisely so you don't have to think about it. > Do not get confused between buffers and arrays. Arrays have data in them, > the array is your data. The buffer is just memory where you can put > data if you have it. More nonsense. Alla, Malcolm has his own personal definition of the word "array" that contradicts its actual meaning in C. I strongly suggest you ignore it. If you want to think about the terminology, it's best to think of "array" as an adjective, not as a noun. (The same applies to "pointer".) If you talk about "arrays", you risk ambiguity. Instead, we have array types, array objects, array values, and array expressions. A "buffer" is just a term for an object (almost certainly an array object) used to hold values. What Malcolm calls a "buffer" is an array object, or equivalently an object of array type. At a given moment, some elements might have meaningful values and others might not; you need to keep track of that. Malcolm nonsensically denies that such an array object is "an array", and insists on using the word "array" to apply only to the meaningful contents of an array object (if I understand his usage correctly). (An "array value" is the value of an array object, consisting of the values of the elements of the array object. C doesn't provide many operations on array values, so the concept of an "array value" isn't often used.) > Now, assuming we want the geometrical mean of cash, cash is always > the first member of the group. So take the first 8 bytes, treat as a > double, skip 18 doubles (18 * 8 bytes), get the next one, and so on, > up to N. If we want the geometrical mean of ar, same drill, except > it is always the second member of the group. So we can skip 8 bytes, > take 8 bytes, then skip (18 * 8) bytes as before. Or we can take > ther start or the array, skip 8 bytes, take the double go back to the > start, skip (19 *8 bytes), or the entire structure, skip 8 bytes, > take the double, and so on. It doesn't really matter, but method two > is often a bit easier. > > offsetof simply tells you how many bytes to skip. If your data structures are well designed to enable what you want to do with them, you won't have to think about bits and offsets; you'll just refer to elements and members of your data structures, by index or by name. There are some cases where offsetof() can be useful, but I don't believe the problem you're working on (which I admittedly haven't taken the time to understand) is one of them. I suspect, Alla, that by using offsetof() you may have programmed yourself into a hole. It may be that continuing to dig is still the best option, but I don't think you'll be satisfied with the result. But take that with a grain of salt, since I haven't paid very close attention to the details of what you're doing. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"