Path: utzoo!attcan!uunet!microsoft!bobatk
From: bobatk@microsoft.UUCP (Bob ATKINSON)
Newsgroups: comp.std.c++
Subject: Re: Packing, Ordering, and Rearranging
Message-ID: <57892@microsoft.UUCP>
Date: 2 Oct 90 15:46:45 GMT
References: <57650@microsoft.UUCP> <57681@microsoft.UUCP> <2311@ux.acs.umn.edu> <57681@microsoft.UUCP> <1990Oct1.074231.8639@zorch.SF-Bay.ORG>
Reply-To: bobatk@microsoft.UUCP (Bob ATKINSON)
Organization: Microsoft Corp., Redmond WA
Lines: 54

(Kent Paul Dolan) writes:
>>	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.


No one denies that a *given* compiler may give you precise control 
over layout. Just don't expect that in general, despite your claims
below, that such bit control will be PORTABLE. The existing ANSI C
std, by its provision for holes in structs and the possibility of 
differeing quanta of bit field grouping explicitly recognizes this
non-portability.  Sure, as you have experienced, it *may* be portable
to *some* other compilers, but this is not mandated by the language.
It *is* language mandates that of concern to us here.


[paragraphs pointing out that control of structure layout is sometimes
usefule deleted]

>    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

*C* does not give you this *guarantee* today!

>    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

But it is precisely the standard that we are talking about, since
the language is absolutely no more than what is written in the
standard.

>Kent, the man from xanth.

	Bob Atkinson
	Microsoft