🚀 go-pugleaf

In article <57650@microsoft.UUCP> bobatk@microsoft.UUCP (Bob ATKINSON) writes:
>xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>>jimad@microsoft.UUCP (Jim ADCOCK) writes:
>
>>>One cannot write portable software, and in general take control of the
>>>intimate details of structural layout.
>
>>Successful languages (so far) give complete control where it is demanded
>>by the programmer.  
>
>Jim, I believe, agrees with you that such demands do arise and must be 
>provided for.  He merely points out that such control is NON-PORTABLE and 
>never has been in C++ OR C. From this viewpoint, he argues that therefore
>such explicit control should be the exception rather than the rule; in
>the absence of any explict programmer demands, the compiler should be 
>free to have more control about structure/class layout than is currently
>the case.

Thank you.  I think the suggestion we gravitated towards it that people
who need to bit-twiddle can do so within the confines of an :

extern "C"
{
    ....
}

statement.  Thus, we ensure that C++ doesn't inadvertantly take away any
of that exquisitely "complete" control of bit layout that ANSI-C provides.
[Anyone have the ANSI-C reference handy? :-]

Likewise, by restricting bit-twiddling compatibility to the "C" sections of
code, we ensure that the needs of "bit-twiddlers" don't take away from the
needs of "object oriented" programmers.

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.