Re: Constants from a 3rd Party DLL

About my bad C #define definition, to have

    #define UVA_SOMECONT $1001

> \ Notice the following definition don't work. Why ?
>
> : #define ( "const" "value" -- )
> token
> token pad place
> s" CONSTANT " pad append
> ( a n) pad append
> pad count ( evaluate) type ; \ $1001 CONSTANT $1001OMECONT
>
> #define SOMECONST $1001
>

I see now it's because TOKEN use WORD, and WORD moves the
parsed word at the HERE location (conflict).

So the next PARSE based definition is better:

    : #define ( "const" "value" -- )
        bl parse bl parse pad place
        s" CONSTANT " pad append
        ( a n) pad append
        pad count ( evaluate) type ; \ $1001 CONSTANT SOMECONST

I think there is a proposal to have PARSE-NAME :

    : PARSE-NAME ( "name" -- c-addr u ) \ CORE-EXT
         /SOURCE OVER >R BL SKIP DROP R> - >IN +!
         /SOURCE DROP 'TIB @ - IN> ! BL PARSE DUP IN> CELL+ ! ;

So the next definition is better:

    : #define ( "const" "value" -- )
        parse-name parse-name pad place
        s" constant " pad append
        ( a n) pad append
        pad count ( evaluate) type ; \ $1001 CONSTANT SOMECONST

Just before a click on the <send> button, I see
again a simplest (but less optimal) definition:

    : #define ( -- )
        create bl word count evaluate , does> @ ;

Charles

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Wed Apr 19 2006 - 11:58:29 PDT