iverson@xstor.UUCP (Tim Iverson) (08/18/90)
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
rfg@NCD.COM (Ron Guilmette) (08/18/90)
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.iverson@xstor.UUCP (Tim Iverson) (08/21/90)
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
roland@ai.mit.edu (Roland McGrath) (08/21/90)
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
rfg@NCD.COM (Ron Guilmette) (08/31/90)
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.
hopper@ux.acs.umn.edu (hopper) (09/11/90)
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..." :-) :-) :-)
jimad@microsoft.UUCP (Jim ADCOCK) (09/18/90)
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.
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (09/21/90)
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>
bobatk@microsoft.UUCP (Bob ATKINSON) (09/24/90)
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
jimad@microsoft.UUCP (Jim ADCOCK) (09/25/90)
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.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (09/25/90)
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.
dhoyt@vw.acs.umn.edu (09/25/90)
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
iverson@xstor.UUCP (Tim Iverson) (09/26/90)
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
dhoyt@vw.acs.umn.edu (09/26/90)
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
iverson@xstor.UUCP (Tim Iverson) (09/29/90)
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
dhoyt@vx.acs.umn.edu (09/30/90)
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
hopper@ux.acs.umn.edu (hopper) (10/01/90)
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..." :-) :-) :-)
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (10/01/90)
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.
jimad@microsoft.UUCP (Jim ADCOCK) (10/02/90)
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" ?
hopper@ux.acs.umn.edu (hopper) (10/02/90)
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..." :-) :-) :-)
bobatk@microsoft.UUCP (Bob ATKINSON) (10/02/90)
(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
jimad@microsoft.UUCP (Jim ADCOCK) (10/03/90)
I have to admit I'm becoming very discouraged by the amount of commentary this subject is generating, without any corresponding understanding of the issues as applied to object oriented programming. I don't believe any compiler vendor is going to want to reduce the amount of capability their C compilers have traditionally provided for 'bit-twiddling' The real issue is what methods shall compilers writers be allowed to use to implement inheritence. This cannot have been an issue in the past, because C did not have inheritence. Use a C structure, don't use inheritence, and chances are about 99% that your C++ compiler will give you the same layout as your C compiler. But, given that a C++ compiler needs to implement inheritence, how shall vendors be allowed to do so? Should C++ compiler vendors all be forced to follow the cfront model? Or should vendors choose object models that maximize efficiency for their target machines? I, for one, believe there is a need to allow multiple object models. Differing object models can allow significant trade offs between speed and space. Differing object models may be necessary to interface to other OOPLs, or systems. Newer object models can provide overall speed enhancements. Therefore, I believe the issues are different in the face of inheritence as opposed to a language without inheritence. Please don't just keep dragging out historical C examples of how you like to place bits. That's not the issue. You'll still be able to do that. The question is, what should language users be allowed to do, and not do, via inheritence, and what should compiler implementors be allowed to do, and not do, regards inheritence?
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (10/03/90)
jimad@microsoft.UUCP (Jim ADCOCK) writes: >I have to admit I'm becoming very discouraged by the amount of commentary >this subject is generating, without any corresponding understanding of >the issues as applied to object oriented programming. No more than I am to see you return to a position passed by two weeks ago as inadequate to the needs of the user community, with no progress made whatever from opinions stated at that time. Let's establish a few ground rules: 1) Compilers are not written for the convenience of compiler writers, but of compiler users and users of compiled code. Therefore, promoting user inconvenience in favor of compiler writer convenience is a Bad Thing. 2) Tremendous as the productivity gains can be from using object oriented programming languages, they are at bottom just notational conveniences for ordinary imperative languages. In particular, no new computations become feasible by using OOPLs, though the chance of implementing the old ones correctly or cost effectively may improve. In particular, there is a direct translation of C++ into C, which is merely a change of notation. The price paid for using a new notation should not be the loss of ability to do some common programming tasks, compared to the older notation. 3) The purpose of any standard, and in particular a language standard, is to standardize existing practice, for purposes of making things adhering to the standard more widely and conveniently useable, in particular for programming languages, the code and the programmers trained in its use. Now let's see if some progress is possible. > I don't believe any compiler vendor is going to want to reduce the > amount of capability their C compilers have traditionally provided > for 'bit-twiddling'. And, whether standardized or not, past practice has been that complete, bit by bit control of structure layouts was always made available to the programmer, albeit not portably so. > The real issue is what methods shall compilers writers be allowed > to use to implement inheritence. This viewpoint is part of the problem in coming to some resolution in this discussion. 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 cannot have been an issue in the past, because C did not have > inheritence. Beside the point. The same capabilities provided to extend structures by inheritence existed and were widely used and known, when structures were embedded in other structures. The experience of that widely used programming paradigm is completely applicable to the current question. > Use a C structure, don't use inheritence, and chances are about > 99% that your C++ compiler will give you the same layout as your C > compiler. Given that C compiler implementors all tended to lay out structure elements so that they didn't cross boundaries of elements their size laid out in an array beginning at address zero, and left padding between them to assure this, and didn't arbitrarily rearrange structure fields to achieve more efficient packing, and that this habit is reenforced in the C++ implementors, probably true, but note _all_ the conditions. > But, given that a C++ compiler needs to implement inheritence, how > shall vendors be allowed to do so? The first choice would be that they follow the model of existing practice in C, which is to embed the "parent" structure as the first element of the "child" structure. See for example the very pretty general link list structure used for the Commodore Amiga windowing operating system. _Any_ choice should be evaluated to see whether it has a high cost that would preclude the general use of inheritance, one of the great design benefits of an OOPL. Not to keep the reader in suspense, loss of control of structure layout by the programmer/user of the compiler is such a high cost. > Should C++ compiler vendors all be forced to follow the cfront > model? Never having looked at it, I haven't a clue; since I only care about the part that affects me on the outside as a programmer designing code, I care much less about the method or model, than about the final result. > Or should vendors choose object models that maximize efficiency > for their target machines? This choice is not even expressed along the relevant axes. The question which needs consideration is, should compiler writers/vendors choose to wrest control of structure layout, in the case of structures built piecemeal by inheritance, from the programmer? Again, it needs emphasis, the same structure _functionality_ can be built in a non-OOPL, without inheritance. That it is built by the mechanisms of inheritance is a convenience of notation, but not an essential characteristic of the structure, so the question of the structure's utility to the programmer should be considered _independent_ of the notational mechanism used to build the structure. (Given that the programmer retains complete control of the structure layout, the same _structure_ can also be built in a non-OOPL.) If the programmer, by deliberate coding choice, expresses no need to control the layout of a particular structure exactly, which may be the majority case, then the compiler writer will, simply to meet competition from other vendors, do the most efficient implementable optimizing layout possible, but this cannot be allowed to become the only case, to the exclusion of the programmer's _preeminent_ right to demand complete control in order to accomplish the programming task at hand _when_ _needed_. > I, for one, believe there is a need to allow multiple object > models. This only makes sense if it is not allowed to diminish the utility of the notational convenience which is inheritance. If it does, then we have put the wrong group's interests foremost. > Differing object models can allow significant trade offs between > speed and space. Wonderful, but if you give me fast, compact code that prevents me from doing _my_ job, where is the gain? Your code may look wonderful in the benchmarks, and sell well in the market place, but when word gets out that it is unusable, what have you profited by denying the programmer control of the code's results? > Differing object models may be necessary to interface to other > OOPLs, or systems. Interfacing at the data level, what more than exact layout control could you offer, and how could you possibly expect to succeed at this task if you don't offer at least that much? > Newer object models can provide overall speed enhancements. If your insistance on control of structure layout, to the preclusion of my controlling it when I need that control, prevents me from doing my job, or from using inheritance, and gaining its productivity benefits, how has your faster compiled code helped me? Code still costs more to write than it does to run in all but the most extreme cases, and if you force me back to more primitive methods and increase the cost of my code implementation, of what use to me is it when it runs fast but is delivered too late for its intended task or market window of opportunity? > Therefore, I believe the issues are different in the face of > inheritence as opposed to a language without inheritence. As I hope I have successfully demonstrated, this belief is false. The premier criterion _must_ be, can the programmer get done the job s/he needs to do with the tool you have provided. If you have impeded that task, all the speed and code size brags in the world won't repair the damage. > Please don't just keep dragging out historical C examples of how > you like to place bits. I must, until you finally understand the point. The fact that you find history's lessons inconvenient for your arguments on certain questions doesn't make that history any less valid in deciding those questions. I've been programming a _long_ time; many of those examples predate the existance of C. Until you understand the point that this kind of programming is a large part of what the C++ language's audience of programmers will be doing for the lifetime of the language, these historical examples will keep being brought up to avoid the old "those who refuse to learn from history..." problems. Programming's past is also part of its future. New programming tasks will arise as time proceeds, but all those old ones keep coming back in new suits of clothes, and the retreads outnumber the new tasks in day to day programming work. > That's not the issue. You'll still be able to do that. But if I cannot do that with the productivity gains of the new programming model provided by OOPL, but have to revert to the methods of C, then I lose productivity, portability, reuse, and the other benefits of OOP. Also, now with your proposed paradigm, I have to keep two programming models in mind, keep track of when one or the other is appropriate, and in general will be led to make a whole new class of programming mistakes by the added complexity this dual model of programming structures would cause. > The question is, what should language users be allowed to do, and > not do, via inheritence, and what should compiler implementors be > allowed to do, and not do, regards inheritence? Completely true. My answers: Language users should be allowed to do, via inheritance, at least those things which were possible with the pre-OOPL methods of embedding structures that were the predecessors of, and model for, inheritance. This explicitly includes exact structure layout control when needed. Compiler implementors should be allowed to do whatever cute tricks they can think up to gain speed and compactness so long as those don't degrade the utility of inheritance compared to the methods it replaces. End of direct responses. Note that there are really several more questions here: 1) Do I know how the compiler will lay out my structures? 2) Can I control that structure layout at all? 3) Can I do it in portable code? 4) Does that portable code produce portable structures? (I admit this question is a strange one, but see below.) 5) Can I do it for the full range of notational conveniences that an OOPL provides, and enjoy the productivity gains that implies? 6) Can I make use of optimizations provided by the compiler writer when I don't need the structure layout control those optimizations would prevent? In terms of a standard, this leads to these further questions. 1) Does the standard mandate that the compiler's structure layout methods will be documented exactly for each implementation, so that I can know what layout the code produces by inspecting the code and reading the implementation documentation? 2) Does the standard mandate that there will be a way in a C++ compiler to control the layout of structures, so that I can read the implementation documentation expecting to find it? 3) Does the standard mandate that there will be an implementation independent method of controlling structure layout, where the same code leads to the same layout, bit for bit? 4) Does the standard mandate what "bit for bit" means into the teeth of byte order and other machine inconsistencies? 5) Does the standard extend that layout control consistently across all the ways the language has to define a structure, or does it treat such layout control as an unusual case, and isolate it to only the more primitive structure definition methods? 6) Does the standard mandate a #pragma, "exact" keyword, compiler flag, or similar mechanism to yield control of structure layout to the programmer (or yield it to the compiler's layout optimization, depending on which is the default), or does it at least mandate that some such, implementation dependent, method must exist? It is not a given that we can agree to answer all, or any, of these questions "yes", or even agree to answer them at all, but I think it should be a given that the results of the answers or lack thereof will have a large impact on the success and lifetime of the language whose standardization is being discussed here. I hope it can also become a given that the utility of the language to the programmer, not to the compiler writer, should be the paramount criterion for deciding these questions, and that functionality and programmer productivity should preceed speed or compactness of compiled code in measuring that utility. Note that, with history for a guide, we can say with some degree of confidence that each successful C++ compiler implementation _will_ provide _some_ way to control structure layout exactly, since successful past compilers have consistently, though non-portably, done so. The question then reduces to one of whether we (you) choose to capture and mandate that existing practice in this standard, with the gains implied by _making_ this practice standard rather than implementation dependent. If this choice is made in the affirmative, then the next question is how much control of implementations the standard will take on behalf of the programmer/user, with respect to the question of exact structure layout control. [No sense trying to execute the "then" portion until the "if" portion is satisfied, so I'll stop here.] Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -- Whew! ;-)
jimad@microsoft.UUCP (Jim ADCOCK) (10/05/90)
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.
henry@zoo.toronto.edu (Henry Spencer) (10/06/90)
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
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (10/06/90)
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>
henry@zoo.toronto.edu (Henry Spencer) (10/07/90)
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
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (10/07/90)
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>
jimad@microsoft.UUCP (Jim ADCOCK) (10/09/90)
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]
brians@hpcljms.HP.COM (Brian Sullivan) (10/13/90)
>>>... 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 --
gordon@meaddata.com (Gordon Edwards) (10/17/90)
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)