Re: Enhancement needed (was strange record size ?)

[Michael Pickett <Ada@norvu.demon.co.uk>]

In article <39beb5c7.17576629@news.demon.co.uk>, John McCabe <john@assen
.demon.co.uk.nospam> writes
>Michael Pickett <MPickett@norvu.demon.co.uk> wrote:
>
><..snip..>
>
>>...Robert may have misunderstood my intentions...
>
>Given my experience of Robert's interpretations, I think that your
>hypothesis is likely to be entirely correct!

One has to take the rough with the smooth. :-)

>
>>* Implementation Advice is a useful mechanism for persuading an
>>implementor to adopt (or avoid) a particular approach where it would be
>>inappropriate to introduce a normative clause. (Unfortunately, the
>>Standard does not provide any background on what qualifies a clause to
>>be a recommendation rather than a requirement.)
>
>I may be missing the point here, but I believe IA are guidelines as to
>the way a compiler would be expected to do things, but none of these
>are requirements. The RM however does identify Implementation
>Requirements sections.

I am inclined to share your beliefs. The point is, I think, that code
that relies on Implementation Requirements is portable, at least to the
extent that that is practical, but code that relies on Implementation
Advice is only portable to the extent that all compilers under
consideration follow that advice. Relying on Implementation Advice being
followed is a calculated risk. Relying on Implementation Advice NOT
being followed, as appeared to be the case at the start of this
exchange, is an even greater risk, even though there may be compilers in
this category. My concern in following up this posting was that there
may be examples of where only by assuming that Implementation Advice has
been taken (and so by taking a calculated risk) is some particular
useful effect achievable. I don't know that there are any such examples,
- I hope there aren't any - but if there are, I hope someone will bring
them forward rather than simply live with the risk.


-- 
--Michael--