OK, I am starting to tear my hair out here. I have pretty simple logic=20=20
but the behavior of my program doesn't seem to be following my logic.=20=20
And, yes, I am assuming I am doing something wrong but I don't have=20=20
enough background with the OOPic to know for sure.

It appears that I can create a data object, i.e. an oByte, set it to=20=20
various values in my program, and look at how it changes at run-time=20=20
to give me an idea of how my logic flow is working. (While this=20=20
*seems* to be working, please correct me if I am wrong in this=20=20
assumption.)

Is there any reason that, insofar as program flow is concerned, data=20=20
objects and variables, e.g. oByte and Byte, might behave differently=20=20
in program structure, e.g. a switch statement? I have looked through=20=20
the documentation but can't see any differentiation but some of my=20=20
results suggest that this might be the case.

--

Brian Lloyd Granite Bay Montessori
brian AT gbmontessori DOT com 9330 Sierra College Blvd.
+1.916.367.2131 (voice) Roseville, CA 95661, USA
http://www.gbmontessori.com

I fly because it releases my mind from the tyranny of petty things . . .
=97 Antoine de Saint-Exup=E9ry

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C

=20

=20


(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Variables (byte and word) are unsigned; data objects can be
signed. That can certainly lead to operational differences under the
right circumstances.

At 12:24 PM 3/9/2008, Brian Lloyd wrote:
>Is there any reason that, insofar as program flow is concerned, data
>objects and variables, e.g. oByte and Byte, might behave differently
>in program structure, e.g. a switch statement? I have looked through
>the documentation but can't see any differentiation but some of my
>results suggest that this might be the case.



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

On Mar 9, 2008, at 9:36 AM, Andrew Porrett wrote:

> Variables (byte and word) are unsigned; data objects can be
> signed. That can certainly lead to operational differences under the
> right circumstances.

I am aware of the differences between signed and unsigned types. (I=20=20
must admit to being surprised to see that type char is signed. That=20=20
makes no sense to me.) I was wondering if they behaved differently,=20=20
i.e. can I substitute an oByte for a Byte in my program code without=20=20
any ramifications? I am using it in a switch (case) statement which=20=20
defines the states in my state machine. I am trying to follow the=20=20
state transitions by watching the data object in real time.

--

Brian Lloyd Granite Bay Montessori
brian AT gbmontessori DOT com 9330 Sierra College Blvd.
+1.916.367.2131 (voice) Roseville, CA 95661, USA
http://www.gbmontessori.com

I fly because it releases my mind from the tyranny of petty things . . .
=97 Antoine de Saint-Exup=E9ry

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C

=20

=20


(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

Brian Lloyd wrote:
> OK, I am starting to tear my hair out here. I have pretty simple logic
> but the behavior of my program doesn't seem to be following my logic.
> And, yes, I am assuming I am doing something wrong but I don't have
> enough background with the OOPic to know for sure.
>
> It appears that I can create a data object, i.e. an oByte, set it to
> various values in my program, and look at how it changes at run-time
> to give me an idea of how my logic flow is working. (While this
> *seems* to be working, please correct me if I am wrong in this
> assumption.)
>
> Is there any reason that, insofar as program flow is concerned, data
> objects and variables, e.g. oByte and Byte, might behave differently
> in program structure, e.g. a switch statement? I have looked through
> the documentation but can't see any differentiation but some of my
> results suggest that this might be the case.
>
>
Yes, they can operate differently. If you have an oByte tied to a VC
then that value can change unpredictably while in the running VC. A
Byte variable will be what you set it to. An oByte will reflect
whatever the VC is doing at that moment, and a VC is running _many_
times faster than the script code. So, in effect you will get a
snapshot of the window of the VC operation that happens to be doing
something when the script code interprets it.

DLC
> --
>
> Brian Lloyd Granite Bay Montessori
> brian AT gbmontessori DOT com 9330 Sierra College Blvd.
> +1.916.367.2131 (voice) Roseville, CA 95661, USA
> http://www.gbmontessori.com
>
> I fly because it releases my mind from the tyranny of petty things . . .
> — Antoine de Saint-Exupéry
>
> PGP key ID: 12095C52A32A1B6C
> PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C
>
>
>



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

At 01:26 PM 3/9/2008, Brian Lloyd wrote:
>I am aware of the differences between signed and unsigned types. (I
>must admit to being surprised to see that type char is signed. That
>makes no sense to me.)

char defaulting to signed is classic / standard behaviour for real C
compilers. It dates from the early days when memory space was tight
and using 8 bit variables was common. You can't calculate a negative
difference with unsigned values, which is why programmers normally
use signed variables (hello Year 2038 problem!)

When working with real compilers, I always define my own unsigned 8
bit datatype:

typedef unsigned char BYTE; // portable unsigned 8 bit data type
It seems correct to me for "byte", "word", "dword", etc. datatypes to
be unsigned. I tend to equate them with memory addresses, block
sizes, and so on - things that can never be negative.

char, int, long - these are the signed counterparts. It works for me.
...Andy



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

On Mar 10, 2008, at 1:16 AM, Andrew Porrett wrote:

> At 01:26 PM 3/9/2008, Brian Lloyd wrote:
>> I am aware of the differences between signed and unsigned types. (I
>> must admit to being surprised to see that type char is signed. That
>> makes no sense to me.)
>
> char defaulting to signed is classic / standard behaviour for real C
> compilers. It dates from the early days when memory space was tight
> and using 8 bit variables was common.

Yes. I spent more time writing in Pascal where char is a character and
must be assigned character data. Byte, word, dword, long, etc., were
unsigned types. Int was signed.

> You can't calculate a negative
> difference with unsigned values, which is why programmers normally
> use signed variables (hello Year 2038 problem!)

I agree.

> When working with real compilers, I always define my own unsigned 8
> bit datatype:
>
> typedef unsigned char BYTE; // portable unsigned 8 bit data type

Yes.

> It seems correct to me for "byte", "word", "dword", etc. datatypes to
> be unsigned. I tend to equate them with memory addresses, block
> sizes, and so on - things that can never be negative.

I agree 100%.
> char, int, long - these are the signed counterparts. It works for me.

My only disagreement would be to use char as signed. It should be
reserved for character data, e.g. "char foo[10]" would be a string of
length 10. But then, I have always been a proponent of strongly-typed
languages. It catches a lot of silly errors.

So clearly, I am right and everyone else is wrong. ;-)

Thanks for the response Andy.

Brian Lloyd
Granite Bay Montessori School 9330 Sierra College Bl
brian AT gbmontessori DOT com Roseville, CA 95661
+1.916.367.2131 (voice) +1.791.912.8170 (fax)

PGP key ID: 12095C52A32A1B6C
PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A 1B6C



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )

At 12:58 PM 3/10/2008, Brian Lloyd wrote:
>My only disagreement would be to use char as signed. It should be
>reserved for character data, e.g. "char foo[10]" would be a string of
>length 10. But then, I have always been a proponent of strongly-typed
>languages. It catches a lot of silly errors.

Most C compilers have command line switches to force char to
unsigned, but that can lead to portability issues if you're forced to
use a compiler that doesn't support it, or if someone forgets to use
the switch.

There may be #pragma's that will do it; that at least moves the
information in to the actual code where it belongs, but I doubt that
they're standardized.
Myself, I use BYTE foo[10]; to declare character data arrays and

typedef BYTE * STRING; // used with null-terminated strings

to define string pointers:

STRING sp; // pointer to colon in string

sp = strindex(foo, ':'); // sp points to (first) colon (or NULL if not found)

etc...
>So clearly, I am right and everyone else is wrong. ;-)

Clearly. Same goes for me. :)
...Andy



(You need to be a member of oopic -- send a blank email to oopic-subscribe@yahoogroups.com )