From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public From: scs@eskimo.com (Steve Summit) Subject: Re: Porting Experiences (was Ada and Pascal etc ) Date: 1997/11/13 Message-ID: <64f5nr$6de$1@eskinews.eskimo.com> X-Deja-AN: 289886920 References: <34557f2b.1934172@news.mindspring.com> <345E3ACD.A15@gsg.eds.com> <63mcmm$r3s$1@helios.crest.nt.com> <3460A7BB.3CCD27DC@hso.link.com> Organization: better late than never Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1997-11-13T00:00:00+00:00 List-Id: In article <3460A7BB.3CCD27DC@hso.link.com>, Samuel T. Harris evidently wrote: > Reading the arguments between Kaz and others, I'm struck with the > realization that Kaz is missing a significant point. As long as > application code is not concerned with the representation of > variables, Kaz is correct in his statements that a few simple > guidelines insure good type choices for portable C code. What Kaz has > failed to consider, but has been state by others, is that sometimes > the representation of the type IS important to the application... > context in which the application is running... While application > usually are only concerned witht he RANGE supported by the type... > the context in which the app is running may force the use of > [some type], especially when interfacing to hardware, COTS libraries, > or in a distributed environment where heterogenous architectures must > interface with each other. These are common examples of the context > forcing a representation. C does not support forcing the > representation in a portable way. Ada does. The need for such > cannot be simply dismissed because the need is real. The need is as real as you make it. (But note also that to suggest that a problem be solved by avoiding it is not dismissing or ignoring the problem.) It's no surprise that performing portable, "binary" I/O to an externally-imposed storage layout is less convenient in C. *Everything* is less convenient in C! It's a relatively low-level language, as high-level languages go, and it embodies a cornerstone of the Unix philosophy, which is that it should not go too far in helping you to do something, because to help you to do it invariably involves constraining the way you'll do it. C lets you do I/O however you want; the cost is that you have to specify more of the details to get what you want. Of course, you can try to come up with a higher-level scheme which contains so much flexibility that it lets you do whatever you want, but of course, there are potential costs here, too. One is the specification and implementation cost, and another is the learning curve cost on the part of the would-be programmer. >From what you say, it sounds like Ada does attempt to tackle this problem, but we know that at least one of those costs has already been exacted. For the first several years of its existence as a language, Ada managed to revive an old adage from the earliest days of high-level languages: Ada compilers were (just as FORTRAN compilers were once thought to be) nearly impossible programs to write. I think that every aspect of this discussion over the problems of performing portable, "binary" I/O is wholly consistent with the established fact that C is a low-level language which may make you do more work up-front than do more ambitious languages. C's enduring popularity in spite of this tradeoff suggests strongly that it must have some compensating merits. But I've lapsed into silly, defensive, language-war posturing, which is just that: silly! Use the right tool for the job! If you have an absolute requirement to perform I/O in a byte-for-byte way to conform with externally-imposed storage layouts, fread() and fwrite() are not your tools. Either write your own low-level I/O routines (as Kaz has been suggesting all along), or use preexisting libraries such as those for XDR, CDF, or HDF, or use another language which either has I/O built in or makes it easier to encapsulate your own. Don't blame C or call it a poor tool for not making it easier to perform this task; blame yourself or your superiors for choosing a poor tool or a poor strategy. And don't get me wrong: I do agree that, as bad an idea as it often is, the need to perform layout-constrained I/O can be very real. If I were designing a language, I'd include features to make it more convenient. But that's another story. > So, I can't say to Kaz that he is wrong, because he is not, as far as > he goes. What I do say to Kaz is "You have only pricked the tip of the > portability iceberg." Portability involves much more than guaranteeing... Well, it all depends on how you define "portability." I've been a student of portability for a long time, and maybe I'm crazy or tilting at windmills off in left field, but I'd say that if you really care about portability, you need to define your data file formats portably, too. If your data format is defined, either explicitly or implicitly, as containing fields such as "a 32-bit integer in the machine's byte order", then it's an inherently unportable format, and to describe a "portable" program for reading or writing this format is an oxymoron. Once you've defined a portable data file format, *then* you can start arguing about which language makes it more or less convenient, or more or less efficient, to read and write that format. But defining "portability" as the ability to write code which reads and writes binary formats and which recompiles anywhere, and then criticizing a language which does not make this task maximally convenient, strikes me as erecting a bit of a strawman. Steve Summit scs@eskimo.com