__FB_EVAL__ does not do what I think it should do according to the documentation

General FreeBASIC programming questions.
Post Reply
wallyg
Posts: 267
Joined: May 08, 2009 7:08
Location: Tucson Arizona

__FB_EVAL__ does not do what I think it should do according to the documentation

Post by wallyg »

This is a greatly reduced version of a complex set of macros

Code: Select all

#DEFINE     gtkList     999

#MACRO      gtkWindow?(windowName,args...)
#DEFINE     gtkTemp     __FB_JOIN__(gtkList,__FB_UNQUOTE__(__FB_EVAL_("AAAA")))
#Print      gtkTemp
#UNDEF      gtkList
#DEFINE     gtkList     gtkTemp
#Print      gtkList

#EndMacro

gtkWindow(alpha,H,1,V,2)
When I compile this with FB 1.09 which comes with WinFBE standard toolchain on an up-to-date Windows 10 system. I get

999__FB_EVAL__("AAAA")
Error 89: recursive Define not allowed, found "__FB_JOIN__ in gtkWindow(alpha,H,1,v,2)

Why does the first #Print not replace the __FB_UNQUOTE__(__FB_EVAL("AAAA)) with just AAAA
And where is the recursive define coming from? I put an #UNDEF prior to the new Define?

Wally
fxm
Moderator
Posts: 12082
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: __FB_EVAL__ does not do what I think it should do according to the documentation

Post by fxm »

The right macro name is '__FB_EVAL__' instead of '__FB_EVAL_' or other typos.
wallyg
Posts: 267
Joined: May 08, 2009 7:08
Location: Tucson Arizona

Re: __FB_EVAL__ does not do what I think it should do according to the documentation

Post by wallyg »

Thank you for the insight into the misspelling of __FB_EVAL__. I looked at line many times and did not see that.

I corrected the misspelling and tried the code again. I still get Error 89: Recursive define.

Code: Select all

#Print      gtkTemp					' works fine now

#UNDEF      gtkList
#DEFINE     gtkList    gtkTemp
#Print      gtkList
So after the print, we know that gtkTemp is 999AAAA no __FB_JOIN__ to be found.

After UNDEFing gtkList, I then define gtkList to gtkTemp ("999AAAA") and then try to print the value of gtkList.

Where can the recursive define be coming from?

Code: Select all

#Print      gtkTemp
#UNDEF      gtkList
#DEFINE     gtkList     __FB_EVAL__(gtkTemp)
#Print      gtkList
I tried changing the value to which I set gtkList as above, with the same error. It's like it thinks gtkTemp contains a reference to gtkList.

Is it possible that the __FB_xxx__ functions do not work on a #define statement? And only work when the defined variable is used and the __FB_xxx__ functions get evaluated at that time? It is certainly not specified as such in the documentation. Almost makes the __FB_xxx__ functions useless.

If so then how do I build up a defined variable one piece at a time from subsequent macros and then after all the macros cause the built-up contents to be placed on a line and get compiled after all the macros do their thing?

Wally
fxm
Moderator
Posts: 12082
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: __FB_EVAL__ does not do what I think it should do according to the documentation

Post by fxm »

Maybe it is just the recursive DEFINE absence check that does not take the UNDEF keyword into account in its logic?
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: __FB_EVAL__ does not do what I think it should do according to the documentation

Post by coderJeff »

wallyg wrote: Aug 29, 2022 20:34 I tried changing the value to which I set gtkList as above, with the same error. It's like it thinks gtkTemp contains a reference to gtkList.
It does contain a self reference.
Is it possible that the __FB_xxx__ functions do not work on a #define statement? And only work when the defined variable is used and the __FB_xxx__ functions get evaluated at that time? It is certainly not specified as such in the documentation.
None of the built-in __FB_xxx__ macros or user #defines or user #macros "work" on #define statements. The body of the macro is stored as literal text.
If so then how do I build up a defined variable one piece at a time from subsequent macros and then after all the macros cause the built-up contents to be placed on a line and get compiled after all the macros do their thing?
#macros and #defines work like functions and only after all the nested macros are expanded does it get compiled. You will likely need to rethink what you are trying to accomplish.


----
Two problems, simplified examples:
1) misleading error message, a refers to b and b refers to a - it is recursive

Code: Select all

#define a __FB_JOIN__(b,2)
#define b a
#print  b
2) hangs the compiler since at least fbc 1.04 (I didn't test older):

Code: Select all

#define a b
#define b a
#print  b
wallyg
Posts: 267
Joined: May 08, 2009 7:08
Location: Tucson Arizona

Re: __FB_EVAL__ does not do what I think it should do according to the documentation

Post by wallyg »

Thank you for the information. It was not what I wanted to hear but it is what it is. I thought I came up with a sneaky way to accomplish a problem.

Wally
Post Reply