In article <2218@ux.acs.umn.edu> hopper@ux.acs.umn.edu (Eric Hopper) writes:
| Some people may argue that it is up to the compiler to make your
|code efficient. I would kindly direct them to some very nice languages that
|do this for you. Pascal, and FORTRAN are good examples. I personally don't
|like either of those languages because the compiler may be arbitrarily wrong
|(as far as efficiency is concerned), and you don't have enough control over
|the produced code to fix it.
|
| Making the structure packing rules too complex would bring you too
|far away from the machine you are programming, and make it impossible to
|preform some optimizations yourself. This is not what C, or C++ is about.

I think these arguments would be fine if we were still talking about C.
But, If one is using inheritence and encapsulation, then significant compiler
optimizations are required.  One cannot have Bob create a base class, and
Diane create a derived class, and give each intimate control of the structure
that results.  One cannot write portable software, and in general take control
of the intimate details of structural layout.  Certainly, there are going
to be situations where the programmer is going to want to take the bull by
the horns, and tell the compiler precisely what the layout should be.  Maybe
in some situations, the programmer is going to want to use an "asm" directive
and lay down some particularly tight, hand written code.

But make such fine-grained control the default ???

This would prevent the compiler from customizing the code generated for a
given usage, for the unusual case where the programmer needs to take over
manual control.  The programmer can stil sieze control where necessary,
by turning off optimizations, or using pragmas, or whatever.  Let the compiler
optimize the usual cases, and save the humans to optimize the really special
cases.

jimad@microsoft.UUCP (Jim ADCOCK) writes:
>
>One cannot write portable software, and in general take control of the
>intimate details of structural layout.

Huh?

Probably the three languages in which most ported code in existance today
is written are COBOL, FORTRAN, and C, and each gives _exquisite_ control
over data "structure" layouts, through COBOL's RECORD, FORTRAN's ARRAY and
EQUIVALENCE, and C's struct, bitfield, and union functionalities.

Successful languages (so far) give complete control where it is demanded
by the programmer.  There is no particular reason to think a language
without such facilities will succeed over the long term, so why design one?

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

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.

>Kent, the man from xanth.

 Bob Atkinson
 Microsoft

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.

In article <1990Sep21.130531.7437@zorch.SF-Bay.ORG>, 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.

> Probably the three languages in which most ported code in existance today
> is written are COBOL, FORTRAN, and C, and each gives _exquisite_ control
> over data "structure" layouts, through COBOL's RECORD, FORTRAN's ARRAY and
> EQUIVALENCE, and C's struct, bitfield, and union functionalities.

COBOL forces you to take control over layout down to the 'character'
level, because COBOL is historically about describing layout on paper
forms.  If you _want_ the compiler to manage layout for you, you have
to use SYNCHRONIZE, which is a pain and (according to a friend of mine
a couple of years ago who did a lot of COBOL coding) isn't portable, in
the sense that you have to move it around for different machines.
Maybe the current COBOL gives you layout control to the bit level; the
version I last used didn't.

So far from giving you "exquisite" control over data structure layout,
the Fortran 77 standard says nothing about how big an integer is except
that INTEGER and REAL are the same size.  Some Fortran compilers support
size controls such as INTEGER*1, INTEGER*2, INTEGER*4, REAL*{4,8,16},
COMPLEX*{8,16,32}, but those are extensions and are not in the standard
language.  Some Fortran compilers even make INTEGER*2, REAL*4 the default,
which is out-and-out wrong according to the standard.  The Fortran 77
storage model is in terms of two kinds of "storage units":  integer and
real take 1 (plain) storage unit, complex and double precision take 2
(plain) storage units, and character*N variables take N character storage
units.  If you overlay character storage units and (plain) storage units,
you haven't got "exquisite control" over layout, you have a non-conforming
program whose behaviour is undefined.  And then there is the well-known
problem of
 REAL X
 DOUBLE PRECISION D
 COMMON /C/ X, D
which may or may not work depending on your machine's alignment requirements;
there is no way to say "put these in the best order so that alignment is
satisfied".  (Fortran 90 MODULEs provide a better way.)

So far from providing exquisite control over layout, C doesn't even define
things like how big an 'enum' is nor let _you_ say.

If you want an example of a standardised language which _does_ provide
control over storage control, look at Ada.

> Successful languages (so far) give complete control where it is demanded
> by the programmer.  There is no particular reason to think a language
> without such facilities will succeed over the long term, so why design one?

Fortran, COBOL, and C have managed ok so far...
--
Fixed in the next release.

In article <3827@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes...
>the Fortran 77 standard says nothing about how big an integer is except
>that INTEGER and REAL are the same size.
  It says nothing about size period.  FORTRAN on pdp-11's, Harris machines,
and many others had different sized integers and reals.

david

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. [...]
>
> Bob Atkinson
> Microsoft

While your statement is true, it is very misleading.  It is due to the lack
of a standard when exercising such precise control that makes programs
non-portable, not the existence of such code in a program.  If you'll pause
to reflect a momoment, you'll realize that every area in a language that
allows the vender to make a decision on how to bridge a gap between cause
and effect results in a potential portability problem.

It is unfortunate that the smaller the gap, the more artificial the
language.  And, as we all know, some architectures will suffer greatly from
the ridiculous (to that system) demands placed on it by such a language.
Smalltalk-80 is a prime example of the wonders of portability purchased with
the pain of poor performance (how's that for aliteration :-).

I feel that it is possible to elimate the gap in the standard w.r.t.
structure layout without loosing any performance - especially if a new
keyword is used (e.g. 'exact struct foo { ... };').  Altering or adding to
the behavior of an existing keyword is not wise - it may break existing
applications.


- Tim Iverson
  uunet!xstor!iverson

In article <204@xstor.UUCP>, iverson@xstor.UUCP (Tim Iverson) writes...
>While your statement is true, it is very misleading.  It is due to the lack
>of a standard when exercising such precise control that makes programs
>non-portable, not the existence of such code in a program.  If you'll pause
>to reflect a momoment, you'll realize that every area in a language that
>allows the vender to make a decision on how to bridge a gap between cause
>and effect results in a potential portability problem.

  No, even truly 'portable' extentions cause portablity problems.  Take the
Cray for instance.  It has no 'char' datatype and can address only a word
(bytes do not exist).  To address a character, the low order (32 on a Cray 2)
bits of an address point to the word of the character and the top three bits
(63:61 - ignored by the hardware) are the character offset from the beginning
of the word.

  As you might guess all character resultion is done is software.
        if ( c[n] == 'a' )
will take a lot more cycles than a 1.0 / f.  As a result any non-aligned
manipulations are very, very slow.

  Now take, the average brainless programmer that micro-'optimizes' his or her
code to 'save' memory in structures.  They 'know' that with

        struct a {
                char one[ 2 ];
                int  two;
        };

the size if the structure is

        sizeof( struct a ) == 2 + sizeof( int )

And takes advantage of this packing.  Now Cray has two options.  Break the
code or produce very, very slow code.  If the standard requires it to be
packed, i.e. the code is defacto portable, it still is a portablity nightmare;
Cray is forced to produce very slow code.  Blech.

  The micro programmer that cries, "I never thought it was going to be ported
to a Cray!"  Just hasn't hasn't worked very long.  Also it is interesting to
note that this 'optimization' will actually slow any machine with a 32 or 64
bit bus (all mainframes, mini's and most workstations) by causing all sorts of
non-aligned references and writes.

  The ONLY time that there is a real need for the programmer to understand
the underlying structure layout is when the programmer is dealing device
drivers and whatnot.  The need to save memory (aka 640k) is better addressed
by a make-structures-very-tight switch on the compiler.

david paul hoyt | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet

In article <2275@ux.acs.umn.edu> dhoyt@vw.acs.umn.edu writes:
>In article <204@xstor.UUCP>, iverson@xstor.UUCP (Tim Iverson) writes...
>>[no std => not portable (usability-wise)]
>
>[std => not portable (speed-wise)]
>
>  The ONLY time that there is a real need for the programmer to understand
>the underlying structure layout is when the programmer is dealing device
>drivers and whatnot.  The need to save memory (aka 640k) is better addressed
>by a make-structures-very-tight switch on the compiler.

Actually, 90% of what I write has to interface with with the real world, so
I consider the "works" option to be far more important than the "speed"
option; it's highly annoying to have to tune a program's structures every
time I switch compilers, simply because every vender tries to be different.

For strange machines that have such costly restrictions on alignment, such
as the Cray, I would mind less having to do a little work to bring the speed
up than I would mind having to work to make it go at all (i.e. *first* turn
the key, *then* step on the gas).

Tell me, which is more important to your management: "it works", or "when
it works, it'll be fast"?

>david paul hoyt | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet

- Tim Iverson
  iverson!uunet!xstor

In article <206@xstor.UUCP>, iverson@xstor.UUCP (Tim Iverson) writes...
>In article <2275@ux.acs.umn.edu> dhoyt@vw.acs.umn.edu writes:
>Tell me, which is more important to your management: "it works", or "when
>it works, it'll be fast"?
>- Tim Iverson
  When it works, it will be cost effective.
david

In article <57681@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
  Stuff deleted
>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"
>{
>    ....
>}
>
  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.

Have fun,
UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper   (Eric Hopper)
     __                    /)                       /**********************/
    / ')                  //                         * I went insane to   *
   /  / ______  ____  o  //  __.  __  o ____. . _    * preserve my sanity *
  (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_  * for later.         *
Internet:              />                            * -- Ford Prefect    *
hopper@ux.acs.umn.edu </  #include <disclaimer.h>   /**********************/
--
--
Nils_McCarthy mtymp01@ux.acs.umn.edu rutgers!umn-cs!ux.acs.umn.edu!mtymp01
"The wonders of modern technology..."
:-) :-) :-)

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.

In article <57858@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Reading the ANSI-C spec, I do not see any promises of the "precise" control
>being referred to.  I see instead, great latitude provided to compiler
>writers in order to allow efficient code be generated on a given machine.
>Perhaps you can clarify what constraints provided by the ANSI-C spec meet
>your ideas of "precise control" ?

 I can't see any references to that, the point is, is that you can do
it. A given structure member IS garunteed to come after a previous strcture
member, and most compiler vendors tell you the sizes of their various
fields, and their padding rules. Wala! You can declare structures that will
be packed in a particular fashion.

 The argument that this is non-portable is silly. Of course it isn't
portable. There are occaisionally VERY good reasons to do it though, and the
issue that doing so isn't portable becomes moot. If strange structure
packing were stuck in C++ it may not be possible anymore to do these
neccesary, non-portable things.

 If C++ becomes a language in which you can't do things, it will
become useless.

Have fun,
UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper   (Eric Hopper)
     __                    /)                       /**********************/
    / ')                  //                         * I went insane to   *
   /  / ______  ____  o  //  __.  __  o ____. . _    * preserve my sanity *
  (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_  * for later.         *
Internet:              />                            * -- Ford Prefect    *
hopper@ux.acs.umn.edu </  #include <disclaimer.h>   /**********************/

Sorry Kent. I have no control over my news posting software. I'll send a
note to the sysadmin though.

--
--
Nils_McCarthy mtymp01@ux.acs.umn.edu rutgers!umn-cs!ux.acs.umn.edu!mtymp01
"The wonders of modern technology..."
:-) :-) :-)

In article <2311@ux.acs.umn.edu| hopper@ux.acs.umn.edu (Eric Hopper) writes:

| 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.

Exactly what packing would this keyword imply, and also what object model
would it imply?

| 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.

Reading the ANSI-C spec, I do not see any promises of the "precise" control
being referred to.  I see instead, great latitude provided to compiler
writers in order to allow efficient code be generated on a given machine.
Perhaps you can clarify what constraints provided by the ANSI-C spec meet
your ideas of "precise control" ?

(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

In article <2321@ux.acs.umn.edu| hopper@ux.acs.umn.edu (Eric Hopper) writes:
| I can't see any references to that, the point is, is that you can do
|it. A given structure member IS garunteed to come after a previous strcture
|member, and most compiler vendors tell you the sizes of their various
|fields, and their padding rules. Wala! You can declare structures that will
|be packed in a particular fashion.
|
| The argument that this is non-portable is silly. Of course it isn't
|portable. There are occaisionally VERY good reasons to do it though, and the
|issue that doing so isn't portable becomes moot. If strange structure
|packing were stuck in C++ it may not be possible anymore to do these
|neccesary, non-portable things.

Not to worry, I don't believe any C++ compiler is going to keep you from
doing these things.  Clearly, C++ compilers over the short term will be
highly motivated to remain closely compatible to earlier C compilers.
The issue in my mind is should the C++ language standards explicitly
prevent any compiler from doing anything else *but* be strictly "C"-like
forever more?

As before, to pad the way you want, you'll need to understand a particular
compilers paddings rules to be able to trick the packing the way you
want.  And, when doing virtual functions, virtual bases, multiple inheritence,
etc, you'll also have to understand how a particular compiler organizes those
things, and where and how they hide the 'nasty bits' like vtable ptrs,
vbase accessing etc.

My position is to let the language standard specify the language, and let
marketing forces [aka "customers"] specify the compiler implementations
-- which may need to evolve as we learn more about object oriented programming.

In article <1990Oct3.061708.10391@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>... The convenience of compiler writers should not
>be an issue. Whether something is possible at all, or only
>possible with an NP complete computation, is admissible as an
>argument, but not the compiler writer's mere convenience, where
>that is gained at the expense of the compiler user.

This fine idealistic viewpoint ignores the realities of the standards
world.  A standard is useful only if it is widely accepted.  It cannot
become widely accepted without support from compiler writers.  Trying
to ram things down the compiler writers' throats with standards simply
does not work; all it does is eliminate the usefulness of the standard.

(Actually, it doesn't work for a more fundamental reason:  the compiler
writers tend to be more involved with language standards than the users
are, so standards committees are mostly unlikely to approve ideas that
a majority of compiler writers strongly disapprove of.)

Compiler-writer convenience may be gained at the expense of the user,
but compiler-writer inconvenience is *always* at the expense of the
user, because users are the ones who are using and paying for the
compilers, and they will buy and use cheap, fast, available compilers
rather than expensive, slow, yet-to-be-released ones every time.
--
Imagine life with OS/360 the standard  | Henry Spencer at U of Toronto Zoology
operating system.  Now think about X.  |  henry@zoo.toronto.edu   utzoo!henry

henry@zoo.toronto.edu (Henry Spencer) writes:
> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>>... The convenience of compiler writers should not
>>be an issue. Whether something is possible at all, or only
>>possible with an NP complete computation, is admissible as an
>>argument, but not the compiler writer's mere convenience, where
>>that is gained at the expense of the compiler user.
>
>This fine idealistic viewpoint ignores the realities of the standards
>world.  A standard is useful only if it is widely accepted.  It cannot
>become widely accepted without support from compiler writers.  Trying
>to ram things down the compiler writers' throats with standards simply
>does not work; all it does is eliminate the usefulness of the standard.

I offer the Ada language as an absolute counterexample to your argument.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

In article <1990Oct6.133425.12773@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>>... A standard is useful only if it is widely accepted.  It cannot
>>become widely accepted without support from compiler writers.  Trying
>>to ram things down the compiler writers' throats with standards simply
>>does not work; all it does is eliminate the usefulness of the standard.
>
>I offer the Ada language as an absolute counterexample to your argument.

I wasn't aware that Ada was useful.
--
Imagine life with OS/360 the standard  | Henry Spencer at U of Toronto Zoology
operating system.  Now think about X.  |  henry@zoo.toronto.edu   utzoo!henry

henry@zoo.toronto.edu (Henry Spencer) writes:
> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>> henry@zoo.toronto.edu (Henry Spencer) writes:
>>>... A standard is useful only if it is widely accepted.  It cannot
>>>become widely accepted without support from compiler writers.  Trying
>>>to ram things down the compiler writers' throats with standards simply
>>>does not work; all it does is eliminate the usefulness of the standard.
>>
>>I offer the Ada language as an absolute counterexample to your argument.
>
>I wasn't aware that Ada was useful.

Well, I wrote a moderately interesting set of packages in it to support
graph theory research, so it hasn't been completely useless to me, at
least.

Ada tends to support the "if it ever makes it past the damned compiler,
it will run just fine" school of program implementation, as opposed to C,
which supports the "rolling around in concertina is fun, really" school
of programming.

I haven't decided yet where C++ falls in that spectrum, but so far the
barbed wire is winning out.

In any case, the amount of pain cause to compiler writers by the Ada
standard is a matter of record; many claimed it was impossible to write
an efficient compiler.  Yet now, hundreds exist, without compromises
with the compiler standard's requirements having been done in the name
of easing the compiler writers' lives.

My opinions on Ada's visibility rules, and other intense obscurities,
on the other hand, aren't printable.

All I can say is, C++ seems headed down the same slippery slope of a
language too unintuitive for widespread use.  I just wish, for both
Ada and C++, that comprehensibility of the rules had been made a
paramount goal.  The nicest thing about Pascal and Modula-2 is that
a moderately experienced programmer can fairly easily intuit what a
piece of code is doing.  I don't find that true for Ada or C++, and
it took me far too long to get that comfortable with C.  Ossified
synapses, probably.

Sigh.  Off to the language wars.  This isn't worth following up.

Try really hard not to do so.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

Reader who have lost track of what we're discussing in this notes flame are
reminded that my original suggestion was simply that the first sentence starting
on the 15th line of page 173 of ARM be removed.  My reasoning being that
the requirement that the addresses of members be ordered, without requiring
those members be contiguous, is not very useful to C++ programmers.  If the
language did require members be contiguous [kind of difficult, in the presence
of nasty bits like vtable or vbase ptrs] then having ordered addresses would
be useful.  But the language doesn't promise that.  If someone has examples
where knowing the address order of members in a labeled section is useful
without requiring the members be contiguous, I'd be interested in knowing it.
In the strict sense, "higher address" only means something within the context
of the contiguous elements of an array, anyway.  [I don't intend to imply
that ordering in arrays be removed :-]  In an extern "C" construct, presumably
you know you don't have nasty bits, and to maintain compatibility with your
C compiler your C++ compiler needs to place members "next" to each other
and at increasing addresses.

Some respondents have insisted to do practical programming, they need to be
able to assume a compiler places members next to each other.  Fine, I don't
disagree with these needs, its just that the language already does not
promise members be "next" to each other.  Insisting members be next to each
other would disqualify many interesting object models, so there are also some
good reasons not to add this constraint to the language.  My position is
simply that given the language does not guarantee members be "next" to each
other, it doesn't make much sense to require them be ordered with respect to
address.  So I suggest that the sentence on the 15th line of page 73 be
removed, and that packing order be left to be determined by the needs and
demands of customers.  Personally, at least in the near term, I believe
customers are going to insist on maintaining close compatibility with "C"
compilers, because a lot of "C++" programmers are going to continue to use
"C" coding practices.  I just don't believe this should be enshrined in the
language definition, where it might prove a nuisance at some future date.
The counterposition is, heck, just leave the 15th line of page 73 in for now,
nobody can really make any good use out of it anyway.  And then, if and
only if, it proves a nuisance in the future, we'll just have to revise the
language spec.  I'm just sorry this discussion has generated so much more
heat than light.

[PS: I am not Microsoft]

>>>... A standard is useful only if it is widely accepted.  It cannot
>>>become widely accepted without support from compiler writers.  Trying
>>>to ram things down the compiler writers' throats with standards simply
>>>does not work; all it does is eliminate the usefulness of the standard.
>>
>>I offer the Ada language as an absolute counterexample to your argument.
>
>I wasn't aware that Ada was useful.

  Too bad your not aware.  Ada is a far better language that C ever will
be.  Unfortunately it never acquire the critical mass of devoted fanatics,
such as yourself, that is apparently needed for widespread use and approval.
I am quite happy with the precise specification and enforcement of the Ada
standard, where as the C language didn't even evolve into a standard until
quite late in is life.  Unfortunately for ANSI C there was quite alot of
commonly use pratices that made the resultant language less useable that
what might have otherwise been produced, so now we are stuck with a
language that is just a series of compiler-writer hacks.

  I also appears that C++ is heading down the same path, too bad I had
been hoping for better.

        -- Brian --

In article <77210007@hpcljms.HP.COM>, brians@hpcljms.HP.COM (Brian
Sullivan) writes:
|> >>>... A standard is useful only if it is widely accepted.  It cannot
|> >>>become widely accepted without support from compiler writers.  Trying
|> >>>to ram things down the compiler writers' throats with standards simply
|> >>>does not work; all it does is eliminate the usefulness of the standard.
|> >>
|> >>I offer the Ada language as an absolute counterexample to your argument.

The DoD contracts I worked on never used Ada.  In fact, of the proposals I saw,
only one was in Ada.  (I no longer work in the DoD contracting arena.)

|>   Too bad your not aware.  Ada is a far better language that C ever will
|> be.  Unfortunately it never acquire the critical mass of devoted fanatics,
|> such as yourself, that is apparently needed for widespread use and approval.
|> I am quite happy with the precise specification and enforcement of the Ada
|> standard, where as the C language didn't even evolve into a standard until
|> quite late in is life.  Unfortunately for ANSI C there was quite alot of
|> commonly use pratices that made the resultant language less useable that
|> what might have otherwise been produced, so now we are stuck with a
|> language that is just a series of compiler-writer hacks.
|>
|>   I also appears that C++ is heading down the same path, too bad I had
|> been hoping for better.
|>

There appear to be fanatics on both sides.  Sigh.

Comparing C and Ada is a little bit unfair.

C allows a programmer to have close control over the underlying hardware.
This is a little dangerous and requires responsible programmers.  It results
in very fast code.  C is basically an assembler with a good macro library. :-)

Ada was written to increase protability, promote package reuse, and help
minimize potential bugs (through strong typing, etc).  It is acceptable for
embedded systems ONLY if the compiler implementation is of good quality.  I
have seen Ada compilers that produce poor performing systems and I have seen
compilers that produce better code than optimized VAX FORTRAN.

C++ is an object-oriented language that capitalizes on the large base of C
programmers.

Ada is an object-based language.  It does not support inheritance.


IMHO, there appears to be a need for all three languages.  They all have
benefits and flaws.  Lets not turn this into a religious war.


Trivia:
The company I used to work for was one of the four finalists in the Ada
competition (blue proposal) and still performs USAF compiler validations.

Can anyone guess the company?  (Its in any Ada book.)


-- Gordon     (gordon@meaddata.com)

In article <ROLAND.90Aug20193125@wookumz.ai.mit.edu> roland@ai.mit.edu (Roland McGrath) writes:
+In article <1233@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
+
+   You can definitely specify what you want the exact layout of a struct to be
+   in C and have it be obeyed and have it be portable.  People do it all the
+   time.  Now if only this were possible in C++. :-(
+
+Since this newsgroup is about the standard for C++, I'll assume you are talking
+about standard-conforming implementations of C as well.  In this context, your
+assertion is patently false.  Given the definition:
+
+struct
+  {
+    int elt0;
+    int elt1;
+  } foo;
+
+any of the following layouts are entirely permissable within standard C:
+
+0: elt0
+4: elt1
+
+0: elt0
+8: elt1
+
+0: elt0
+1000000:elt1

Roland points out (quite correctly) that a standard conforming C compiler
is allowed to insert arbitrary amounts of space between. one member and
the next.

Still, I my comment was *not* about just the subset of the aspects of
the behavior of C compilers which are "standard conforming" aspects.
Rather, my comment was meant to include general reality, and not just
"standard comformant" reality.

The reality I'm speaking of is that given:

 struct s { long elt0; long elt1; } object;

it will be true (for all machines and compilers I care about) that:

 (char *) &object.elt1 == ((char*) &object.elt0 + 4)

In fact, much (so called) "portable" code is written so as to make exactly
this kind of assumption.  I see nothing wrong with that.  It gets the job
done, even if it isn't "required" by the standard.

How many compilers do you know of that put arbitrary glops of empty space
in between struct members?
--

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

In article <1407@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>In article <ROLAND.90Aug20193125@wookumz.ai.mit.edu> roland@ai.mit.edu (Roland McGrath) writes:
>+In article <1233@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>+
>+   You can definitely specify what you want the exact layout of a struct to be
>+   in C and have it be obeyed and have it be portable.  People do it all the
>+   time.  Now if only this were possible in C++. :-(
>+
>+Since this newsgroup is about the standard for C++, I'll assume you are talking
>+about standard-conforming implementations of C as well.  In this context, your
>+assertion is patently false.  Given the definition:
>+
    .
    .
Rest of article deleted.
>
>Roland points out (quite correctly) that a standard conforming C compiler
>is allowed to insert arbitrary amounts of space between. one member and
>the next.
>
>Still, I my comment was *not* about just the subset of the aspects of
>the behavior of C compilers which are "standard conforming" aspects.
>Rather, my comment was meant to include general reality, and not just
>"standard comformant" reality.
>
>The reality I'm speaking of is that given:
      .
      .
      .
>
>How many compilers do you know of that put arbitrary glops of empty space
>in between struct members?

 This whole discussion is about making rules for structure packing
more complex. I think that as long as the rules for a particular compiler
are known, it's O.K. There are definate speed advantages to knowing the
layout of your structure.

 I don't think the abstraction should get in the way of you making
the most efficient possible code, no matter what the 'portability' issues,
or whatever else are.

 Some people may argue that it is up to the compiler to make your
code efficient. I would kindly direct them to some very nice languages that
do this for you. Pascal, and FORTRAN are good examples. I personally don't
like either of those languages because the compiler may be arbitrarily wrong
(as far as efficiency is concerned), and you don't have enough control over
the produced code to fix it.

 Making the structure packing rules too complex would bring you too
far away from the machine you are programming, and make it impossible to
preform some optimizations yourself. This is not what C, or C++ is about.

Have fun,
UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper   (Eric Hopper)
     __                    /)                       /**********************/
    / ')                  //                         * I went insane to   *
   /  / ______  ____  o  //  __.  __  o ____. . _    * preserve my sanity *
  (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_  * for later.         *
Internet:              />                            * -- Ford Prefect    *
hopper@ux.acs.umn.edu </  #include <disclaimer.h>   /**********************/

--
--
Nils_McCarthy mtymp01@ux.acs.umn.edu rutgers!umn-cs!ux.acs.umn.edu!mtymp01
"The wonders of modern technology..."
:-) :-) :-)

It seems that the discussion about packing currently needs some refinement
in the area of semantics.  I've always used 'packed' to mean that there is
no padding inserted into a struct (i.e. it's a WYSIWIG struct).  And,
'ordering' has always meant bit placement within a byte and byte placement
within a word.  So what seems to be under discussion here is really a
combination of packing and rearranging fields within a struct.

Both packing and ordering are highly desirable for the simple reason that
as the language (C/C++) stands now, it cannot deal *transparently* with the
real world.  This is due solely to the lack of rigor in the specification
for the definition of a struct - the compiler is allowed too much latitude
in the physical layout of a struct.

Your common intelligent programmable electric toaster device often (always?)
requires strange and arcane packing and bit fiddling to get data into and
out of the controlling interface.  Almost invariably, this results in
several routines to read in the data and stuff it into a structure, rather
than just reading it into the structure.  The same is true for many programs
that must import or export data.

If the language had constructs for specifying such things as packing and
ordering (bit, word, etc.), it could deal transparently with structures
created outside of its own venue and should result in code that is
both cleaner and more portable.

As far as the format of the extension goes, it should be a pure extension
and should not give new meaning to keywords currently in use.  If you
overload the current keywords, it is virtually guaranteed to break programs
that work fine as they are now.  This means that applying a special meaning
to 'extern' is a very bad idea.  It also means that default behavior must
conform to the current default - so any 'packing', 'ordering', or
'rearranging' extensions must be used explicitly in each place that they
are desired.

I admit that these thoughts are rather general, but hopefully they will
spawn another more concrete discussion. If not, I could always fire up the
old blow torch and start a jihad:  maybe something like, oh, say "cobol is
inherently better than C ..." :->.


- Tim Iverson
  uunet!xstor!iverson

In article <195@xstor.UUCP> iverson@xstor.UUCP (Tim Iverson) writes:
<Both packing and ordering are highly desirable for the simple reason that
<as the language (C/C++) stands now, it cannot deal *transparently* with the
<real world.  This is due solely to the lack of rigor in the specification
<for the definition of a struct - the compiler is allowed too much latitude
<in the physical layout of a struct.

This is *not* true in C!  We lost something valuable on our way to C++.

<If the language had constructs for specifying such things as packing and
<ordering (bit, word, etc.), it could deal transparently with structures
<created outside of its own venue and should result in code that is
<both cleaner and more portable.

You can definitely specify what you want the exact layout of a struct to be
in C and have it be obeyed and have it be portable.  People do it all the
time.  Now if only this were possible in C++. :-(

--

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.

In article <1233@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>In article <195@xstor.UUCP> iverson@xstor.UUCP (Tim Iverson) writes:
><If the language had constructs for specifying such things as packing and
><ordering (bit, word, etc.), it could deal transparently with structures
><created outside of its own venue and should result in code that is
><both cleaner and more portable.
>
>You can definitely specify what you want the exact layout of a struct to be
>in C and have it be obeyed and have it be portable.

I don't know what kind of C you're using, but in both K&R and ANSI C, the
structs are definitely not WYSIWIG - the compiler is allowed to insert any
number bytes between fields for the sake of padding.  This makes the struct
wholely non-portable; i.e., two programs with the same struct are not
guaranteed to interpret the data in the struct in the same way.  BTW,
almost all of the compiler vendors realize this and provide some way to
"pack" a struct (e.g. #pragma pack()).

>Ron Guilmette  - Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg

- Tim Iverson
  uunet!xstor!iverson

In article <1233@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:

   You can definitely specify what you want the exact layout of a struct to be
   in C and have it be obeyed and have it be portable.  People do it all the
   time.  Now if only this were possible in C++. :-(

Since this newsgroup is about the standard for C++, I'll assume you are talking
about standard-conforming implementations of C as well.  In this context, your
assertion is patently false.  Given the definition:

struct
  {
    int elt0;
    int elt1;
  } foo;

any of the following layouts are entirely permissable within standard C:

0: elt0
4: elt1

0: elt0
8: elt1

0: elt0
1000000:elt1
--
 Roland McGrath
 Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland