🚀 go-pugleaf

In article <BLUME.95Sep18161301@dynastar.cs.princeton.edu>, blume@dynastar.cs.princeton.edu (Matthias Blume) writes:
|> 
|> I wrote:
|> 
|>    If you had read the C standard or any of the more popular
|>    documents describing it then you would know that neither C nor
|>    C++ give you such a guarantee either.
|> 
|> In article <43jsfd$1ea@nntp.nta.no> ohk@hal.nta.no (Ole-Hjalmar
|> Kristensen TF.E/DELAB) writes:
|> 
|>    What makes you think I haven't read it? I was just complaining that
|>    Modual-3 does not provide it.
|> 
|> What made me think so?  Let's see: A complaint about Modula-3 in
|> (among others) C- and C++-related newsgroups -- in a thread with a
|> title, which suggests a direct comparison between Module-[23] and
|> C(++)...  But of course, you are right, there was nothing more than
|> circumstantial evidence, the facts do not allow to draw a logical
|> conclusion of the kind I drew.

The thread was crossposted to several groups, yes.

|> 
|> Aside from that I still disagree with you:  a programming language
|> should not specify low-level things like memory layout in its
|> definition.  Most of the time you don't need that kind of knowledge,

If it is a systems programming language, I think it should.

|> it becomes a pain in the neck when switching to modern architectures,
|> it prohibits certain kinds of optimizations, and it is generally not
|> very useful EXCEPT for the dubious abuse of data types as templates
|> for persistent structures in the file system.
|> 

Do you have any better suggestions than this "dubious abuse", as you call it?
Byte I/O isn't an option when efficiency is an issue, and if you want to do block
I/O you have to impose structure on the blocks in some way. At some level, you
have to specify the structure of the block. Doing it in a subroutine is fine, but
it is more error prone than explicitly declaring the logical structure of the
block, and how it should be mapped physically.

|> As many others have pointed out already, if you really need to do I/O
|> with specific memory layouts, then it is usually very easy to write
|> I/O subroutines explicitly and encapsulate that code in a few
|> functions.  So you never worry about it no matter what the compiler
|> decides to do.
|> 
|> --
|> -Matthias

Well, let's put it this way then: If someone really needs to do I/O with specific
memory layouts, what's the best solution, having constructs in the language which
allows you to do so in a portable way (or at least more portable than C/C++), or
not having those constructs? I would rather have them.

Of course I would encapsulate the code in a few functions anyway, but what's
wrong with having language support, or at least library support for it? Don't tell
me Sun created its XDR standard and library just for fun. Relying on unspecified
mechanisms for I/O is OK as long as all access to the data is from programs
compiled with the same compiler, but many standard formats for exchanging
data has a standardized physical layout as well.

I can agree that it's perhaps no big deal, it was just a minor complaint that the
designers of a *system* programming language hadn't put it in.


Ole-Hj. Kristensen