Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c Subject: Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Date: Wed, 02 Nov 2011 19:58:49 -0400 Organization: Friends of the Galactic Collective Lines: 156 Message-ID: <8da31c1488f133b-a55b2@gmail.com> References: <4eaf2d0a.428076930@text.giganews.com> <0ee04144-b156-4404-adfd-6444d87d330d@j36g2000prh.googlegroups.com> <4eb034b1.495574475@text.giganews.com> <946df905-acf5-42e2-9a29-a6c3e166ca1e@w7g2000yqc.googlegroups.com> <4EB05AB6.4030304@verizon.net> <73de4aea-4923-413a-9f69-7ad5f96b968f@s2g2000yqd.googlegroups.com> <76b3ff1c-9ccf-4bb6-b0dd-7fdcfcdb91b1@r7g2000vbg.googlegroups.com> <43b0f2d3-d2e7-4330-a7d2-4a71a4bb12fd@m19g2000yqh.googlegroups.com> <04026baf-46f1-488f-bd01-31eebf7039ea@n13g2000vbv.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="iyFSt7Y7BGsyUke8Uoi8DA"; logging-data="22291"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/jAPzAPO1oDEIJDkTg3rAl" User-Agent: nn 6.7.3 Content-Length: 5821 Cancel-Lock: sha1:XjXr2g62iJI9LFL+l3QsoOdl7zQ= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:12563 On Wed, Nov 02, 2011 at 12:09:54PM -0700, nroberts wrote: > On Nov 2, 10:14 am, Malcolm McLean > wrote: > > On Nov 2, 5:22 pm, nroberts wrote: > > > > > > > > > > > > > > > > > On Nov 1, 6:35 pm, James Kuyper wrote: > > > > > > On 11/01/2011 05:16 PM, nroberts wrote: > > > > > > > On Nov 1, 1:46 pm, James Kuyper wrote: > > > > >> On 11/01/2011 03:59 PM, nroberts wrote: > > > > >> ... > > > > > > >>> and has nothing to do with syntax. Structures and arrays are in no > > > > >>> way interchangeable whether you are writing in C, C++, BASIC, or > > > > >>> Brainfuck. > > > > > > >> No one has suggested that they are interchangeable. Only that data which > > > > >> can be stored as a single array of structures can also be stored as a > > > > >> single structure by converting each member to an array. > > > > > > > 2+2 = 27? > > > > > > > Unless you're making a completely pointless statement ... > > > > > > Richard Harter's point was precisely that it's significantly more > > > > complicated iterating through the arrays in a structure than through an > > > > array of structures. > > > > > Because *C* has a bias in that direction.  I was trying to understand > > > that assertion because it seems like nonsense to me, and now everyone > > > wants to pretend it was never made.  That's fine.  If you guys want to > > > make nonsensical assertions and then pretend you were making sense the > > > whole time it's no problem with me, I'll just remain unconvinced. > > > > We've got ten employees, each with name, payroll id, and salary. > > > > we can represent the data like this > > > > typedef struct > > { > >   char name[64]; > >   int id; > >   float salary; > > > > } EMPLOYEE; > > > > EMPLOYEE employees[10]; > > or like this > > > > typedef struct > > { > >   char name[10][64]; > >   int id[10]; > >   float salary[10]; > > > > } EMPLOYEES; > > > > EMPLOYEES employees; > > > > The two methods hold the same data, and have the same access > > characteristics - iterating through the list is done in O(N) time, > > random access is in O(constant) time, searching for the maximum salary > > takes O(N) time, etc. Theya are logically equivalent. > > I thought nobody was saying that!!!! > > The truth is that they are not at all logically equivalent. The > difference between the two is 100% logical. > > > The only > > difference is the way the employees are laid out in memory. > > There could be no difference in how they're laid out in memory, the > difference is in their *logical* structure--completely the opposite of > what you're saying. I can write the statements to access a field in > English and the difference is still there: > > Get the N'th employee from the employee's array and access its id > field. > Get the ids field from the employees structure and access its N'th > element. > > No matter what syntax I use that is specific enough for talking to a > computer, I'm still going to have to access the elements in different > manners. Talk of computer programming and you talk of "manners"? I must have died and gone to hell. > > The first way is better for C, but that's largely because of C's > > syntax. We can imagine language x where you can declare arrays of > > records, and all the fields are contiguous, and this is transparent to > > the user. You'd use a syntax like field(employees, i, salary) *= 1.1; / > > * increment employee's salary by 10 % */ > > > > The second method has certain advantages. For instance, if we want the > > average salary, we have an array of floats ready to be passed to a > > generic mean() function. > > Not in language X. In language X you're using the field() syntax. > You've essentially got an array of structures in language X no matter > what you might want and you're writing your generic mean function to > use binder expressions like: mean(field(employees, _1, salary)). You > can do this in C by the way though not at quite that high level > (you'll be writing custom functions to serve as binder expressions). The cowardly lion might have a thing or two to say about that. > > With the first method, ypu've got to either > > write an special mean_employee_salary() function, use a temporary > > buffer, or fake up the "field" syntax using a stride, offset, and some > > pointer jiggery-pokery. > > Which is all "language X" is. You could write it in C as a macro and > then still access the underlying memory. It's all going to depend > upon the needs of your program. > > All you're doing here is arguing for abstractions. You're not showing > that C's syntax forces you into one form of data expression or > another, you're saying that it would be nice to be able to manipulate > your data at a higher level than structures and arrays. There's > nothing stopping you from doing that in C and there's nothing that > makes it more or less difficult except perhaps a lack of utility > functions in the standard library, which is not a syntax issue. What isn't a syntax issue? > It is true that there are many languages at higher levels than C that > support the kind of expressions you're talking about. C++ in fact > provides much of the functionality you want here, or at least better > facilities to create it. But when you get to this point you're no > longer talking about structures and arrays, you're talking about even > higher level concepts. I do agree that abstractions can be a > wonderful thing, but this is clearly not a C specific issue. Duh. We're talking about basic computer science. Your 'victorian' values blind you to the truth of this reality. Oh, shit. Did I say that on the record? Regards, Uncle Steve -- My robot girlfriend can beat up your robot girlfriend.