wishlist for NXC

[HaWe]

Is it possible to make a variable a bit? Like it is 1 or 0? If so, could you add that?

bit is not a C data type, not even bool, so having "bit" would make NXC even more unlike C.
Instead of NXC it would be then more like QUC (quite unlike C). I don't like this idea very much.

[spillerrec]

bit is not a C data type, not even bool, so having "bit" would make NXC even more unlike C.
Instead of NXC it would be then more like QUC (quite unlike C). I don't like this idea very much.

I don't see the issue, one of the fundamental ideas behind C++ is that you can create your own data types to extend the language.
Anyway, this would not be a change of the C language, it would be an extension and pretty much every C compiler (like gcc) extends C in a variety of ways.

But a bit variable type do correspond to a bool, as it must only as it must only contain the values true and false. I'm not sure if the spec enforces it, but it you compile this code with g++ you get 1:

Code: Select all

int i = (bool)457;
printf( "%d", i );

I also believe that there is no strict definition on how it must be implemented, so I don't think there would be anything wrong with saving it as one bit. (vector<bool> actually does this.)
Instead of using a byte for each bool, you could combine up to 8 separate bools into one byte. This is not thread safe however, so you would need to make the compiler smart enough to detect which variables are only used in the same thread. Quite a bit of work, but not impossible. Worth the effort? I wouldn't say so...


Again, I think bit fields would be more useful.

[nxtboyiii]

Actually, the bool in NXC can hold other numbers than 0 and 1. It must be the same as a byte.

[mattallen37]

Yes, bool in NXC seems to be identical to byte; UINT_8. I think the reason for calling it bool, is so the programmer knows at a glance that it will only ever be used to store a true/false value.

I don't know, but it doesn't seem like it would be too hard to store boolean values in a large array, with each bit accessible through a custom function (with mutexs to make it thread safe).

[nxtboyiii]

Yeah, so a 1-bit variable type would be nice. It would save space and memory.

[mattallen37]

It would also be a lot slower, because you would need to use a routine to access it. However, for an application where you need to store hundreds/thousands of boolean values and don't care about speed, I suppose it might be worth it.

I'm pretty sure that the architecture of all modern uCs is such that you can't natively use bit variables. I don't know if any uC ever natively supported bit variables, but they used to support nibbles (4 bits).

In order to add bit variable support, it would be most efficient if it was added at the FW level. But in reality, why would you ever need them? And if you do need them, why not use masks and bit-math with an array of bytes?

[HaWe]

IMO, a 1-bit variable type will be NOT C-LIKE.
false = a value of zero
true = a value of anything but zero.

and C++ is also not C.

anyway - sorry to interrupt this vivid discussion, but I have a wish:
;)

NumOut and TextOut both use an optional "clear" parameter which makes the display clear or not before writing (clear screen).
It would be nice (and much more useful) to have it also for clearing the current line before drawing or to clear the end of the line after writing (clear end of line).

For down-compatibility we could make it
0 = no clear
1 = clrscr
-1 = clrln (before writing)
-2 = clreol (after writing)

[mattallen37]

Can't you use something like this:

Code: Select all

TextOut(x, y, "                 ");

to clear the line before writing to it?

Or what about something like this:

Code: Select all

void TextOutEx(byte x, byte y, string txt, bool CL = false, unsigned int options = DRAW_OPT_NORMAL){
  if(CL)TextOut(0, y, "                 ");
  TextOut(x, y, txt, options);
}

There are a zillion other options I can think of, without some new and special official functions.

[HaWe]

pls, no discussion about workarounds, I know that there might my trillions of 'em...
(this is not meant to be a discussion thread...)

[mattallen37]

Okay then, TextOut already does clear the area first! It just doesn't clear any extra character spaces.

What I suggested was hardly a work-around! It's more like an un-official function that does what you asked for (and you can add other "modes" of clearing the area if you want).

Why does it always seem that with you, everything needs to be officially implemented for it to be any good? The official NXC functions provide a base to build custom functions and tasks.