Re: Variable length/precision formats?
- From: "James Giles" <jamesgiles@xxxxxxxxxxxxxxxx>
- Date: Wed, 22 Mar 2006 20:10:03 GMT
robin wrote:
James Giles wrote in message .......
The feature requires something like "thunks" that change
the format as the I/O list is processed.
Well, then you implemented it wrongly, because the format
can be updated PRIOR to the passing control to format
processing.
The usual definition of the feature *requires* that the user
be allowed to change the format *while* the I/O list is being
processed. Yes, the user *should* avoid that like the plague.
It would be easier to avoid if it weren't possible in the
first place. The usual definition of the feature should be
changed so that it's impossible to have the format change
during the processing of the I/O list. It's the worst aspect
of the feature.
The value of the
format changes every time one of the variables used
in any of the VFEs in the format string gets changed. This
includes changes made to those variables on-the-fly: *WHILE*
the I/O list is being processed. Variables such as implied
loop indices and I/O list items themselves can be in the
VFEs!
They don't have to be, as I pointed out in an earlier post.
The *implementation* must permit them to be (by the usual
definition). The *user* should probably avoid doing so.
The usual definition of the feature should change so that the
*implementation* no longer even needs to support the capability.
The instances in this newsgroup are primarily with basic uses,*
not those doing anything remotely like what you described.
Just f<w>.<d>
But, for *those* instances, the ability to change W or
D *during* the processing of the I/O list is particularly
useless. It needn't be permitted by the feature. It shouldn't
be permitted by the feature's definition. Until that aspect
of the features definition is removed, other methods
described in this thread remain superior.
These errors could be
entirely eliminated by removing the wierd, indirect, on-
the-fly behavior of VFEs.
Or by not using them this way; it's not something that
people actually want.
It's certainly not something *I* want. That's why I support
removing the capability altogether. As I've *repeatedly*
said: if this and a few other failings were altered, I would
even support the feature for standardization. But, the
feature as *usually* defined will, I hope, never be standardized.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
.
- References:
- Re: Variable length/precision formats?
- From: robert . corbett
- Re: Variable length/precision formats?
- From: Joe Krahn
- Re: Variable length/precision formats?
- From: Richard Maine
- Re: Variable length/precision formats?
- From: Joe Krahn
- Re: Variable length/precision formats?
- From: Richard E Maine
- Re: Variable length/precision formats?
- From: Joe Krahn
- Re: Variable length/precision formats?
- From: glen herrmannsfeldt
- Re: Variable length/precision formats?
- From: robin
- Re: Variable length/precision formats?
- From: glen herrmannsfeldt
- Re: Variable length/precision formats?
- From: James Giles
- Re: Variable length/precision formats?
- From: robin
- Re: Variable length/precision formats?
- From: James Giles
- Re: Variable length/precision formats?
- From: robin
- Re: Variable length/precision formats?
- From: James Giles
- Re: Variable length/precision formats?
- From: robin
- Re: Variable length/precision formats?
- Prev by Date: Re: Help: declare an array without knowing the rank and size
- Next by Date: Re: Help: declare an array without knowing the rank and size
- Previous by thread: Re: Variable length/precision formats?
- Next by thread: Re: Variable length/precision formats?
- Index(es):
Relevant Pages
|