Workarounds for preprocessor oddities?

General FreeBASIC programming questions.
Post Reply
shadow008
Posts: 117
Joined: Nov 26, 2013 2:43

Workarounds for preprocessor oddities?

Post by shadow008 »

I'm rather confused as to how to get the preprocessor to properly resolve tokens without resorting to trial and error.

Specifically I'm noticing that
1) #print and #error do not allow for token resolution unless that token is at the very beginning of the line.
2) The wiki description of typeof() is clearly omitting something about its actual behavior. The wiki states the following:
Typeof is a compiler intrinsic that replaces itself with the type of the variable passed to it.
But this "compiler intrinsic" does not behave like other compiler intrinsics (See other intrinsics: https://www.freebasic.net/wiki/CatPgDddefines) as it does not actually replace itself with the type of the variable passed to it in some circumstances.

I've noted the issues in the following code snippet:

Code: Select all

#define _TEST asdf

dim _TEST as integer

'Let's see if we can output details on both the
'variable being used, and its type...

'_TEST is not resolved in either instances.
'typeof is not resolved either
#print Variable: _TEST is of type typeof(_TEST)

'Nope
#print Variable: ##_TEST is of type typeof(##_TEST)

'Closer, but typeof is still not resolved
'This is rather excessive for an only partially working solution
__FB_UNQUOTE__(__FB_EVAL__("#print Variable: " & __FB_QUOTE__(_TEST) & " is of type " & __FB_QUOTE__(typeof(_TEST))))

'This is the most straightforward, minimal solution, but
'why does it have to be spread across 3 lines?
'This could be partially joined with the above solution
'for a 2 line solution but damn is it ugly.
#print Variable:
#print _TEST is of type
#print typeof(_TEST) 'Demands its own line because...?  It's special I guess

'Syntax error.  I'm not sure why, seems like it should be valid to me.
'#print __FB_EVAL__(typeof(_TEST))

'End-of-line what now?  This is both unexpected and bizarre.
'#print typeof(_TEST) should be an integer

'Cannot capture the actual type name in quotes because...?
'I would expect this to output "INTEGER", not "typeof(asdf)"
'AND JUST WHY is _TEST being resolved here but it wasn't being
'resolved above in the first couple examples??
#print __FB_QUOTE__(typeof(_TEST))
Is there a more elegant workaround to the fact that tokens are not being resolved mid-statement with #print and #error (unless those tokens are at the start of the line)?
Also are any of the noted issues with typeof() a bug or am I just using it wrong?
cbruce
Posts: 180
Joined: Sep 12, 2007 19:13
Location: Dallas, Texas

Re: Workarounds for preprocessor oddities?

Post by cbruce »

The manual for #print states:

Code: Select all

Syntax:
   #print text

Description:
    Causes compiler to output text to screen during compilation.
It does *not* state that #print evaluates expressions... it just says it outputs 'text'.

So typeof() is not an issue there, because #print won't evaluate it or anything else in an expression.

cbruce
shadow008
Posts: 117
Joined: Nov 26, 2013 2:43

Re: Workarounds for preprocessor oddities?

Post by shadow008 »

cbruce wrote: Oct 12, 2024 3:56 It does *not* state that #print evaluates expressions... it just says it outputs 'text'.

So typeof() is not an issue there, because #print won't evaluate it or anything else in an expression.
Three things to note:
1) typeof() is not an expression nor is it part of an expression, it's a compiler intrinsic. And compiler intrinsics are not "evaluated", they are replaced at runtime with an expected constant value.
2) typeof() *IS* replaced ("evaluated", if you will) if it's the very first thing in the #print statement (see my original post code snippet for examples)
3) Even if it were an expression, then the following would work:

Code: Select all

'Syntax error.  I'm not sure why, seems like it should be valid to me.
'#print __FB_EVAL__(typeof(_TEST))
But it doesn't. And it's a syntax error(?!) no less.

The wiki page is either extremely imprecise, or wrong, which is why I wanted to know if any of the issues I showcased in my OP were bugs or expected behavior.
Jattenalle
Posts: 61
Joined: Nov 17, 2023 14:41
Contact:

Re: Workarounds for preprocessor oddities?

Post by Jattenalle »

Welcome to the club of "People who would like to use typeof() for cool pre-parsing shenanigans but can't"!

The short of it is that typeof() is in-between both a runtime and pre-processing operator, while also being neither.
As you've noticed typeof() is not (Except sometimes) evaluated before any pre-parsing, making it impossible to use for defines etc.
But on the other hand, typeof() is not a runtime command (It gets string-replaced with the type name), making it impossible to use during runtime: if, iif, __fb_eval__, etc

Oversimplified, but what happens during FBC compile is:
  • Pre-processor runs
  • typeof() is replaced with the type-name
  • Code is compiled
Due to the placement of typeof() in that chain neither the pre-processor nor the runtime can take full advantage of it.

This also means that debug, such as #print is not accurate and can differ from the generated source. e.g. #print and what is generated with -pp can differ

If you're not already on the FreeBASIC Discord I'd recommend you join: https://www.freebasic.net/forum/viewtopic.php?t=26784
I'd love to have someone else to bounce pre-parsing shenanigans back and forth with.
shadow008
Posts: 117
Joined: Nov 26, 2013 2:43

Re: Workarounds for preprocessor oddities?

Post by shadow008 »

Jattenalle wrote: Oct 13, 2024 6:49 Welcome to the club of "People who would like to use typeof() for cool pre-parsing shenanigans but can't"!

The short of it is that typeof() is in-between both a runtime and pre-processing operator, while also being neither.
It's heartbreaking, isn't it?
Based on other observations, procptr might be in the same boat. So much potential between pre-processor resolved typeof() and procptr(), but they're rather hamstrung in their current incarnation. Maybe one day.
If you're not already on the FreeBASIC Discord I'd recommend you join: https://www.freebasic.net/forum/viewtopic.php?t=26784
I'd love to have someone else to bounce pre-parsing shenanigans back and forth with.
Man, if I had time to BS on discord these days, I'd have time to code :D I might drop in here and there though, we'll see.
Post Reply