Strange behaviour with #define

General FreeBASIC programming questions.
SARG
Posts: 1046
Joined: May 27, 2005 7:15
Location: FRANCE

Strange behaviour with #define

Postby SARG » Apr 03, 2020 19:42

I 'm facing a problem and I can't figure out if it's normal or a bug.
Compile the code below with option -pp to see the problem.

In one of my program I must to use the third define to get what I want (a call to a function located in a namespace).

Code: Select all

#define test1 test_1
#define test2 test_2
#define concat(a,b) a.b

test1.test2  '--> test_1. test_2     there a space after the dot.

concat(test1,test2) '-->test_1.test_2
thebigh
Posts: 34
Joined: Dec 14, 2018 11:11

Re: Strange behaviour with #define

Postby thebigh » Apr 03, 2020 20:49

I don't understand all the arcane rules regarding #defines, but by trial and error I found that giving test2 an empty argument list suppresses the initial space:

Code: Select all

#define test1 test_1
#define test2() test_2

test1.test2  '--> test_1.test_2     'no more space. why? I have no idea
Last edited by thebigh on Apr 03, 2020 21:00, edited 1 time in total.
marcov
Posts: 2945
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: Strange behaviour with #define

Postby marcov » Apr 03, 2020 20:57

In C preprocessor you have to use # or ## to concatenate and form aggregates of two parts. Maybe in FB too?
MrSwiss
Posts: 3455
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Strange behaviour with #define

Postby MrSwiss » Apr 03, 2020 21:01

Something like that, perhaps?

Code: Select all

#Define concat(a, b)    ( (a) + "." + (b) )

Print concat("NSpace_name", "Func_name")

Sleep
RESULT wrote:NSpace_name.Func_name
thebigh
Posts: 34
Joined: Dec 14, 2018 11:11

Re: Strange behaviour with #define

Postby thebigh » Apr 03, 2020 21:02

marcov wrote:In C preprocessor you have to use # or ## to concatenate and form aggregates of two parts. Maybe in FB too?


There is a concatenate operator ## that concatenates at the preprocessor stage, but AFAICT it has the same issue with spurious spaces.
paul doe
Posts: 1175
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: Strange behaviour with #define

Postby paul doe » Apr 03, 2020 21:20

SARG wrote:I 'm facing a problem and I can't figure out if it's normal or a bug.
Compile the code below with option -pp to see the problem.
...

Yes, I had the same issues when coding the templating framework. Here's how I solved it:

Code: Select all

#define __conc__( a, b... ) a##b
#define __nfcall__( a, b ) __conc__( a., b )

namespace foo
  sub _
    bar()
   
    ? "Bar"
  end sub
end namespace

__nfcall__( foo, bar )

sleep()

You need another macro so that it expands correctly.
dodicat
Posts: 6390
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Strange behaviour with #define

Postby dodicat » Apr 03, 2020 21:33

One #define for concat seems to work here.

Code: Select all


#include "fbgfx.bi"
#define test1 fb
#define test2 sc_escape

#define concat(a,b)  a.b

namespace foo
  sub _
    bar()
   
    ? "Press <esc>"
  end sub
end namespace



do
    locate 4,,0
concat(foo,bar)
if multikey(concat(test1,test2)) then exit do
loop
print "Press any key . . ."

sleep()

Or am I missing something?
SARG
Posts: 1046
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Strange behaviour with #define

Postby SARG » Apr 03, 2020 21:58

dodicat wrote:One #define for concat seems to work here.
Sure concat(a,b) a.b does the job. It's what I use.

It's seems that the preprocessor adds a space in front of each define.

Code: Select all

#define test1 test_1
#define test2 test_2
#define concat(a,b) a.b

test1.test2  '--> test_1. test_2

concat(test1,test2) '-->test_1.test_2

print   test1

test1=test2

After preprocessing there is also a space before test_1.

Code: Select all

 test_1. test_2

 test_1.test_2

print test_1

 test_1= test_2
thebigh
Posts: 34
Joined: Dec 14, 2018 11:11

Re: Strange behaviour with #define

Postby thebigh » Apr 03, 2020 22:08

I suppose that's a good thing, actually. Imagine if you *needed* a leading space for some reason and couldn't otherwise get one-- because the preprocessor would interpret a leading space as a separator between tokens instead of being part of a token itself, or compress consecutive spaces into one. Now we know we can suppress a leading space if we need to, or include it if we need to.

Return to “General”

Who is online

Users browsing this forum: No registered users and 4 guests