I agree, that in the right hands, pointers are extremely powerful,
but I feel Crestron have chosen wisely here.
As foo's already said, the potential for misuse of pointers would
open us up to a world of pain. I'm not knocking anyone here; we all
have to start somewhere, but there do appear to be a lot of guys
programming systems with some pretty shaky foundations in procedural
languages, and even simple syntactic issues (like the root of this
thread) could wreak havoc scrambling your processor's brains. So I
suppose you could argue "Pointers don't kill processors, programmers
do" ;-) Anyway - anyone who's had to debug bad pointer arithmetic
knows what a time-consuming process it can be, and that's on your own
code - it's 100x harder when it's someone else's.
The efficiency argument can be mitigated too - you can always use
ByRef in your function declarations (in fact, you can't avoid it with
STRING). I've written an XML parser that doesn't move the XML
document at all (though it does mean creating a lot of markers...
which I guess are just my version of (safe?) pointers).
This is where foo pipes up to say that Crestron's implementation of
ByRef does actually make a copy the data 8)
Now... if they'd just implement multiple-inheritance in S+ (*JOKING!*)
Ol
--- In Crestron@..., "Joseph K. Vossen" <jkv@...> wrote:
agreed...in my non-Crestron circle of travels in the past, I have
found that a *good* understanding of pointers separates the good
programmers from the great ones. And then when you jump into
function pointers, that opens up a whole new world of fun.....
having pointers in SIMPL+ would benefit, for example, those tasks
that perform a *lot* of parsing, such as busting up XML pages. Sure
one can do it now with what is available, I just think the code would
be a bit more compact, IMHO
-----Original Message-----
From: fooguy89 <fooguy89@...>
Sent: Jan 23, 2009 10:53 AM
To: Crestron@...
Subject: [Crestron] Re: Question on finding the number of defined
array elements.
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
