Harold Aptroot wrote:
>
"CBFalconer " <cb********@yah oo.comwrote in message
news:48******** *******@yahoo.c om...
>Harold Aptroot wrote:
>>"MisterE" <Mi*****@nimga. comwrote in message
Is it possible to access this value..??
No.
Of course it is. The OP did not request a standard compliant
way to do it after all
On this newsgroup, there are no non-standard compliant ways to do
anything. Anything of that nature is off=topic, and may be found
on specialized news-groups dealing with the authors system.
You mean to say that any solution that requires non-standard compliant
code temporarily ceases to exist when talking on this NG and everyone
trying to predend they Do exist will be flamed for OT-talk?
That seems to be happening anyhow
For my part, I draw the line a little more leniently than
CBF does. Nonetheless, I maintain that the line is a useful one:
There is an important distinction between things that can be done
with unaided C and things that require additional machinery or
additional assumptions.
The reason the distinction is important is that engineering
is an art of trade-offs, and the trade-offs should be made with
proper consideration and not out of ignorance. If you know that
doing a task in some particular way involves things C doesn't
provide or guarantee, then you can make a conscious assessment
about whether the increased capability justifies the diminished
portability. But if you *don't* know where the line is, you'll
wander across it all unaware, perhaps to be unpleasantly surprised
when your code doesn't work on the next machine. You need to be
aware of the boundary, so that you cross it only by decision and
not by accident.
Another reason to study the distinction is that the category
of things unaided C can do is larger than some people imagine.
For example, people are always asking how to discover a machine's
endianness so they can write code that swings both ways. Usually
they're shown a couple of tricks for testing and byte-swapping and
so on -- but often they're also shown "endian-blind" code that
just plain works, no matter how the underlying machine arranges
its integers. That is, they're shown an unaided-C way to solve a
problem that they originally thought needed machine-specific hacks.
That sort of improvement is a worthwhile gain, and should motivate
any serious practitioner to become more familiar with his tools.
Finally, when somebody wants to do something that unaided C
cannot do or cannot do well, the helpful response is to let them
know it's beyond the capabilities of unaided C and to refer them,
if possible, to sources where they can get more information about
the beyond-C capabilities they need. The alternative of dragging
all the beyond-C things into this group is not viable, simply
because the experts in those beyond-C things don't hang out here.
Among the people who frequent this group there are probably folks
who know quite a bit about networking, cryptography, numerical
analysis, random number generation, parsing of artificial and
natural languages, hardware-assisted 3D rendering, and on and on
and on. That's fine, and I for one am glad of their presence.
But the experts in any one such field are thin on the ground here,
not surrounded by their fellow experts who might clarify or correct
their responses. If somebody's working on a C program to reckon
dates according to ancient Babylonian calendars, this is a fine
forum for dealing with the C problems but not a good one for the
calendrical questions. There's probably someone here who knows
about Babylonian calendars and he might answer the question, but
there's nobody here to say "No, that's how the Sumerians did it;
the Babylonian system was quite different."
This group attracts (as it is intended to) a congregation of
people interested in and to varying degrees expert in C, and is
a splendid forum for C questions. Questions about shells, shared
memory, threads, eigenvalue computation, texture mapping, and the
approved protocols for financial computation belong elsewhere.
Because despite our high opinions of ourselves ("Hey, I can write
C -- I must be Really Smart!"), we don't quite Know It All.
--
Er*********@sun .com 
