Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!usc!zaphod.mps.ohio-state.edu!uwm.edu!lll-winken!bert.llnl.gov!howell From: howell@bert.llnl.gov (Louis Howell) Newsgroups: comp.std.c++ Subject: Re: Controlling structure layout (Re: Randomly ordered fields !?!?) Message-ID: <1990Sep6.175744@bert.llnl.gov> Date: 7 Sep 90 00:57:44 GMT References: <1990Aug28.173553@bert.llnl.gov> <1990Sep1.131041.15411@zorch.SF-Bay.ORG> <1990Sep4.163132@bert.llnl.gov> <1990Sep6.194543.7685@zorch.SF-Bay.ORG> Sender: usenet@lll-winken.LLNL.GOV Reply-To: howell@bert.llnl.gov (Louis Howell) Organization: Lawrence Livermore National Laboratory Lines: 83 In article <1990Sep6.194543.7685@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: |> But what has made FORTRAN so valuable to the (hard) engineering |> profession is exactly that the "dusty decks" still run. I doubt |> that the originators of FORTRAN envisioned _at_that_time_ a set |> of applications software that would outlast the century being |> written with the first compilers, but so it has proved. With the |> perspective of history to assist us, we know that stability makes |> for a useful language, and should try to make all the important |> decisions for long term utility of the objects written today as |> early as feasible, not put them off in the interests of granting |> "flexibility" to the compiler writer. Unlike the middle '50's, |> today we have a plethora of highly experienced compiler writers |> to guide our projects; we can depend that a lot of the "best" |> ways, or ways good enough to compete well with the eventual best |> are already in hand. This doesn't deny the possibility of |> progress, or even breakthroughs, nor suggest that either be |> prevented. Instead, let's install the mechanisms now that will |> let today's objects be the "dusty decks" of the 2010's, while |> leaving options to bypass those mechanisms where some other |> goal (speed, size, orthogonality) is more important to a piece |> of code than stability. IMHO, another reason for Fortran's long dominion is that it is (now) a user language, not a CS language. It's used by people who know no other language, and who have no interest in programming beyond its use as a tool for their specialty. (How many C programmers know only C?) It can be easy to forget that users who know only one language often strongly resist switching to a second one, but learning your seventh language is easy. Computing professionals tend to learn many languages, and thus these languages go out of fashion more quickly. C++ may influence future languages, but I very much doubt if it will be directly compatible with them. I think the proper role for C++ will be more like that of Algol. To get dusty decks, you need a user base outside the CS community that creates hard-to-translate information. Scientific computing is the only present non-CS user base that does much of its own programming (unless you count BASIC or Cobol :-), so I doubt that another language will rise to monolithic dominion in another field in the forseeable future. It doesn't have to be just programs, though. You want to know what the "dusty decks" of the 2010's will be? They'll be data and possibly macro packages written for PC applications like 1-2-3. Other possibilities include formatting languages like TeX, and hard-to-translate graphics languages like Postscript, but these can't be considered reusable code. |> a ball. Just give me a switch, like the optimization switches now |> common, to turn it all off and preserve my own explicit control |> over structure layout if that is a real need for my application The extreme case would give you functionality something like the Fortran EQUIVALENCE statement. Create an array of chars, then make the first member start at char 3, the second member start at char 1, the third member start at char 4 (overlaps first member), and so on. I am a bit reluctant to make class layout rigidly defined unless the user has direct control over it. What if we agree to justify on single-word boundaries, then some future architecture makes it efficient to pack classes with no leftover space at all? We'd be stuck with a wasteful construct and no way to work around it in the language. I think there should be either no control, or more control than a single switch. I have no good idea as to what syntax would be best for this, however. |> Again, this is just the standard for what I mean when _I_ take |> control of laying out a structure. If I give that control to the |> compiler writer, I'd better make no assumptions at all in my code |> about the result, because it is explicitly allowed to be "unstandard", |> and I have chosen to write at a high level and delegate those details |> to the compiler writer's ingenuity. Good. Two levels of functionality, for two kinds of code. |> Peace? Agreed. Unfortunately, the standards committee doesn't give a damn whether we agree or not, or what we agree on, and even within the newsgroup we are now most likely in everyone else's kill files. -- Louis Howell "A few sums!" retorted Martens, with a trace of his old spirit. "A major navigational change, like the one needed to break us away from the comet and put us on an orbit to Earth, involves about a hundred thousand separate calculations. Even the computer needs several minutes for the job."