Sudden Build Error

[nxt-ai]

Tried to recompile a program and got the following errors

# Status: NBC compilation f# Error: Preprocessor macro function does not match instance (acquire __FOMutex
mov __FOArgs.Filename, _fname
mov __FOArgs.Length, _fsize
syscall FileOpenWrite, __FOArgs mov _handle, __FOArgs.FileHandle
mov _result, __FOArgs.Result
releasailed.
e __FOMutex)
File "<path to my file>.nxc" ; line 2799
# Exception
#----------------------------------------------------------
1 errors during compilation
make: *** [myfile.rxe] Error 1

Any Ideas?

The code is:

Code: Select all

#define FILESIZE=1024
task main() {
	byte i=0,handle=0;
	DeleteFile("log.txt");
	CreateFile("log.txt", FILESIZE, handle);
	//SetSensorType(IN_1, SENSOR_TYPE_LIGHT_ACTIVE);
	NumOut(10,LCD_LINE1,handle);
	Write(handle, "Sensor Data:");
	while (i<=10) {
		WriteLn(handle,"Sec:");
		WriteLn(handle,"NumToStr(i)");
		StrCat("hello"," hi");
		i++;
		Wait(1000);
	} 
}

<standard help request ending>Thanks in Advance</standard help request ending>

[h-g-t]

By no means an expert but do you not have to close a file after opening it?

[afanofosc]

The problem is the way you defined FILESIZE. It should be like this:

#define FILESIZE 1024

No equal sign in preprocessor #define macros.

The way it is expanding is confusing the preprocessor trying to expand the CreateFile macro.

John Hansen

[muntoo]

Code: Select all

const int fsize = 0x400;

Is what I prefer, but whatever.

[nxt-ai]

Ahh Mighty John Hanson thank you for gracing my thread with your presence
So now I'm curious what does nbc think of the "=" you said it had something to do with expanding?

Also now (ugh!) I'm getting another error:

Error: NXT Error #92
make: *** [download] Error 255
Command /usr/bin/make failed with exit code 2

What is error #92? (it also fails without make)

Code: Select all

Code: Select all

const int fsize = 0x400;

Is what I prefer, but whatever.

first: I don't understand 0x400 yet.
second: if I'm not mistaken constants are only for the pre-compiler so I like to differentiate.
Please correct me if I'm wrong.

By no means an expert but do you not have to close a file after opening it?

Yes I most definitely should close the file <pauses> I was planning to do that!

[muntoo]

first: I don't understand 0x400 yet.

0x400 is hexadecimal for 1024. Replace it with 1024, if you like.

second: if I'm not mistaken constants are only for the pre-compiler so I like to differentiate.

You've got it wrong. This is the preprocessor:

Code: Select all

#define FILESIZE 1024

And this:

Code: Select all

const int fsize = 1024;

Is basically like:

Code: Select all

int fsize = 1024;

Except that it will generate a compiler error if you directly try to change it. This could be helpful if you do it by accident, but otherwise it's used to help anyone reading your code that it won't change. If you're especially evil, you could do this to change the const int, just to confuse the reader:

Code: Select all

const int fsize = 1024;
int * ptr = &fsize;
*ptr = -1;
std::cout << "This should say -1: " << fsize << std::endl;

NOTE: This is C++, not NXC. NXC currently has no support for pointers, and according to John Hansen, probably never will.

So now I'm curious what does nbc think of the "=" you said it had something to do with expanding?

That's because #define replaces whatever the constant is with the number. So, for example:

Code: Select all

#define FILESIZE =1024

NumOut(0, 0, FILESIZE, 0);
// is the same as:
NumOut(0, 0, =1024, 0);

const int fsize FILESIZE;
// is the same as:
const int fsize =1024;

OR:

Code: Select all

#define CONSTANT 42

NumOut(0, 0, CONSTANT, 0);
// Same thing as:
NumOut(0, 0, 42, 0);

[nxt-ai]

So isn't #define faster if its hard coded versus an unchangeable variable?

[muntoo]

So isn't #define faster if its hard coded versus an unchangeable variable?

Not necessarily. Might be, might not, I'm not sure about the details. If the compiler is good, it'll automatically determine this for you.

Also, focus on code readability. This small thing will never really make a difference. You might as well switch over to NBC (or even bytecode) if you're worried about the speed of little things like these. A "simple" call to PointOut() takes hundreds (if not thousands) of more power than a simple variable read/write.

Many [stubborn people ] will recommend const over #define for various reasons (not necessarily good reasons ), but #define can be useful sometimes, no matter what they say. Still, you need to be careful when using #define, in case you make a mistake and don't understand the compiler errors, or even worse, runtime errors. It may be helpful in some cases because NXC lacks some C++ stuff (operator overloading) and C stuff (void*).

[nxt-ai]

Thanks Muntoo.

Still, does anyone know what

Error: NXT Error #92
make: *** [download] Error 255
Command /usr/bin/make failed with exit code 2

Means?

[spillerrec]

Code: Select all

const int fsize = 1024;
int * ptr = &fsize;
*ptr = -1;
std::cout << "This should say -1: " << fsize << std::endl;

NOTE: This is C++, not NXC. NXC currently has no support for pointers, and according to John Hansen, probably never will.

This raises an error in my C++ compiler, ptr needs to be const int *ptr since you are assigning it to address containing a const int. But doing this will invalidate the next line...
I have seen this example before, so I guess this was fixed in a newer version of the spec?

And since NXC compiles into NXT standard firmware bytecode which doesn't support pointers or anything similar, support will not come without a firmware change.

So isn't #define faster if its hard coded versus an unchangeable variable?

Not necessarily. Might be, might not, I'm not sure about the details. If the compiler is good, it'll automatically determine this for you.

There should be no speed difference if the compiler is optimizing properly as it needs to convert the #define into a variable in the end anyway (when using the .rxe format). However the NXC compiler just doesn't optimize the code very well, in fact it struggles with just creating clean code...
I mentioned it a long time ago (perhaps on nxtasy.org, don't remember), but using constant variables instead can cause speed, executable size and memory usage to worsen a bit. (depends a lot on the actual case though.) However I wouldn't be surprised if there are also cases where #define is less efficient...
But if you really care about efficiency, program in NBC, NXC compilation just is too inefficient... So using const is probably a better idea.


@nxt-ai,
I don't really know, but I think the error might be with connecting and transferring the program to the NXT and not the NXC code.