Hi,
because of many crushes with the last betas
I'd like to know if someone may test, if direct display and conversion (assignment) frombyte to int (and back) are now possible, just like


In ANSI C this should work, (int, byte, char, short, and long all are integer variables!) but with RobotC (1.10) I consistently get compiler or runtime errors, so I'd like to know if the bug has been removed meanwhile.
And because of several other beta 1.17 and 1.22 bugs I can't test this by my own

Thanks in advance!

(PS: new test file above)

I don't believe that would work in ansi c, at least it shouldn't.

When doing type conversions you should always specify the type.

[/code]

in ANSI C you don't have to do type conversion!
You could write

and it works!
and it should work just because char (byte) is nothing else but a small integer!

which would create truncation errors.
You should always be aware of mixing data types which is why you should always have type conversions.

There are a lot of versions of c out there that allow you to mix bytes and ints without having the type conversion, but they shouldn't. That just creates bugs.

It kind of looks like your going through robotc looking for things to complain about. I'm not sure if your just a young guy trying to prove your smarts or a forum troll. Either way, it's making me not want to help you.

Personally, I really like robotc, it's a great way to get people into robotics and a great way to program the NXT

You have to keep in mind that this is not running on a terminal, but on a unique system. Most other (maybe all other) versions of C for micro-controllers require that you program IO directly. That is that one has to program the micro-controllers io pins directly to access such things as LCD displays and sensors. I personally wouldn't care to write my own i2c asm code. RobotC makes all that stuff a breeze.

I didn't want to discuss with you about how you personally like RobotC or what errors may occur if variables exceed their allowed ranges.

all of the types
char (byte)
short
int
long
are integer, so they ought to be assigned and calculated to each other - actually this even seems to work with RobotC, but some calculations seem to cause runtime errors (e.g. modulo function: char_value%int_value or int_value%char_value).
And the editor function printf (RobotC equivalent: nxtDisplayTextLine) got a format string ("%d"), which enables the display of any integer variable of any size - why not of byte (char)?

I just asked if somebody may test the latter with one of the newer versions.

If you don't want to help me, let it be!

But this gives you not the right to offend me as a forum troll!!!

Well Im sorry if I offended you.

However, you are in everybodies threads complaining about how robotc doesn't work the way that you would like it to work. Either it doesn't follow ansi standards to the letter or it's too complicated. I wonder why you're even using it. Most people would just not be using it if it was that much trouble to them. I'm not sure why you're here in the forums if it's not to troll.

Anyway. I apolgize to everyone else, I don't want to start a flame war here. There's enough noise already.

ok, I take your apology, although I'm not sure if you're honest.

The reason why I "complain" that RobotC (as a commercial product featured by the Lego Company) in some (or many) cases doesn't work as it should is simply that it doesn't work as it should. The demands on a commercial software are higher than on freeware (such as NXC).

In Germany we got another (bigger) forum to discuss general programming problems and projects (in NXT-G, Robolab, MatLab, RobotC, NXC, NBC, Lejos, Java, NXJ, pbLua, NQC, for NXT, RCX, Scout,...), but here is the forum of the RobotC developers, here is the right place to point out to bugs of RobotC. Where else, if not here?

But I'm willing to stop this discussion too, let's return to the point of the opening question...