🚀 go-pugleaf

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.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
--
Unemployable graphics guru.