I'm pretty sure the reason Crestron doesn't do Pointers is because of
support. They tend to perform a lot of support that doesn't seem to
be "their problem" - issues that are clearly programming mistakes, but
they do try to help resolve them (I know people knock TB for a lot,
but I mean they do try to be helpful if you get the right folks).
Can you just imagine the chaos of newbies trying to use pointers,
overwriting memory, blah blah blah, and Crestron trying to suck it up
and fix it/teach them?
As a professional programmer, sure, it would be great to have, but I
can definitely see why many things are limited.
Sometimes I don't understand the need to try to fix and assist with
blatant programming problems (If you were to call microsoft and whine
about how your system crashed because you did a NULL pointer access or
overwrite the bounds of your array, they'd probably just be like
"Uh....GO FIND AND FIX IT YOURSELF!!")
--- In Crestron@..., Joseph K. Vossen <jkv@...> wrote:
the semi-colon after the if() is a valid statement from the parser's
point of
view; it just doesn't do what you want/expect
here is a simple example of how that is useful; the following 'C'
code copies
a NULL-terminated string, where 'p' points to the destination and
'q' points
to the source:. The while() terminates when the NULL terminating
byte is hit.
while (*p++ = *q++)
; // <- note lone
semi-colon
ya' just gotta love pointers...sure wish SIMPL+ had 'em.......
On Friday 23 January 2009 12:33 am, you wrote:
I would have expected to see a compiler error on the fatal ; at the
end of an IF statement.
True, but I always put them in so that if I do add another line I
don't mess up the execution order/nesting. (Didn't see the ; -
fatal, but a trace should have shown 10 outputs rather than just 1.)
Lindsay
[snip]
