Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!mips!pacbell.com!tandem!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.std.c++ Subject: Re: Packing, Ordering, and Rearranging Message-ID: <1990Oct1.074231.8639@zorch.SF-Bay.ORG> Date: 1 Oct 90 07:42:31 GMT References: <57650@microsoft.UUCP> <57681@microsoft.UUCP> <2311@ux.acs.umn.edu> <57681@microsoft.UUCP> Organization: SF-Bay Public-Access Unix Lines: 87 hopper@ux.acs.umn.edu (Eric Hopper) writes: > imad@microsoft.UUCP (Jim ADCOCK) writes: > Stuff deleted >>My claim is that the needs of "C++" "object-oriented" programming and "C" >>"bit-twiddling" will continue to diverge in the future, and we need to >>separate these two needs. Extern "C" would serve to tell compilers which >>set of needs are being met. >> >>In an extern "C" section, ANSI-C constraints would be met for ANSI-C >>constructs. Outside of an extern "C" sections, those constraints might >>not be applicable. > > I don't think that this will be the case. As more and more programs >are written in C++ that there will be more of a demand for 'bit-twiddling', >particularily if operating systems and the like are written in it. > > I don't think structure declarations that demand precise control >over placement of the bits within memory should be relegated to a patch-up >contruct like 'extern "C" {', they should be part of C++. > > I also think that the default method of member ordering should be >changed, it would cause confusion, and may make older code harder to port. >So I think that a 'packed' keyword ought to be added to the C++ language. > > I think Kent made a very good point earlier when he said that >currently popular languages all allow you to have a fair amount of precise >control over the machine beneath the language. If C++ turns into a 'school' >language in which you are not allowed control over such things as structure >member placement I think we'll see a loss of popularity, and portability. Thanks, Eric. I was a bit bemused to see an earlier followup claiming that FORTRAN, COBOL, and C didn't give exact control over structure layouts; I've written programs in all three that did bit by bit creation of multikilobyte records. I've done a LOT of raster graphics, that required the ability to set bits in scan line long records on a 2^16 bit scan line with a little header block and lots of data blocks. Putting the bits "where the compiler liked" would have caused plotter controller failure. I also got (what a treat) to port tens of thousands of COBOL and FORTRAN written 2400' 9track data tapes from a 36 bit machine to a 32 bit machine using C to take the records apart and put them back together bit by bit to reconstruct e.g. floating point numbers in new machine formats, and change 6 bit FIELDATA characters to 8 bit EBCDIC. I had to be able to depend exactly on the layout of the COBOL records and FORTRAN records and arrays, and be able to declare corresponding records layed out exactly the same way in C, which I got to declare bitfield by bitfield. Some of the proposals seen here for C++ would leave it impossible to guarantee that a structure laid it's bitfields over the properly corresponding bits of a record read as a stream of bytes into a union, where the record could have been, as mine were, written on a different word size computer with different numeric formats and byte bit-lengths. Lacking this capability, one would be forced to an assembly language I/O package, hardly the goal one sought when choosing to program in an OOPL. Saying that programming in a higher level language than C should also force you to program in a lower level language to get the job done seems counterproductive to me. It is true that I used real vendor implementations, rather than the minimalist virtual implementations implied by the standards, but in now almost 30 years of programming, I've never failed to have control to the bit level of how my data was laid out, and I'd be horrified to have a supposedly serious language standard suggest that that was no longer a valid programming need or a worthwhile goal to achieve. It's been needed to do the job on too many projects to count, from OS writing to high end graphics to business bean counting to game construction to telecommunications bit pushing to data base design and implementation. (Yes, I've done all those.) [ By the way, Eric, your news posting software is broken; it stuck the message ID in the Followups-To: line instead of the Message-ID: line (well, that's how it showed up here), which made answering unnecessarily interesting; you might try to get that fixed. ;-) ] Kent, the man from xanth. -- Unemployable graphics guru.