OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Dariusz Piatkowski on October 21, 2021, 09:44:07 pm

Title: Function MACRO or #DEFINE?
Post by: Dariusz Piatkowski on October 21, 2021, 09:44:07 pm
Alright...so I'm going through the IBM CPP (3.6.5) header files and pulling the various constructs as I enhance my 'VSE Modern Theme' solution.

Now, here is where i'm running into a bit of a...umm...mental block??? LOL  ::)

Looking at tchar.h I have the following section:

Code: [Select]
#ifndef __tint
         typedef wint_t _TINT;
         #define __tint

      #define _TEOF  WEOF

      #define __T(x) L ## x

      #define _tprintf     wprintf
      #define _ftprintf    fwprintf
      #define _stprintf    swprintf
      #define _vtprintf    vwprintf
      #define _vftprintf   vfwprintf
      #define _vstprintf   vswprintf
      #define _tscanf      wscanf
      #define _stscanf     swscanf

Alright...so one of my rules is to colour code all static DEFINEs in a certain way. However, the xxprintf & friends really do not fall in line with that approach. After all, these are genuine functions, and in this header file we are simply creating a pointer (MACRO really I think) that references the xxprintf library calls.

So for example:

"#define _tprintf     wprintf"

simply allows _tprintf to be used elsewhere and really being a MARCO it will get mapped to wprintf.

OK, so that's simple right? (and I'm assuming my thinking on this correct...smack me if it's not though!!! )

But if the above is right, I really should NOT colour code those #define statements that point to a function, they should really be colour coded as a MACRO instead.

Makes sense?
Title: Re: Function MACRO or #DEFINE?
Post by: Lars on October 22, 2021, 08:55:54 am
I know this can be discussed until the end of the world, but for me, this is a DEFINE.
That's because a DEFINE is a simple text replacement which is also true for these function calls.
A MACRO on the other hand typically contains multiple instructions (lines broken up with \), typically adding code to your source file (your source file grows, so to say) and/or arguments passed to it. But it is NOT a  (callable) function, it's just additional instructions, as if handwritten.
That's at least my interpretation.

If that helps, you can create a small source file using the construct in question and run that through the precompiler only. Then, have a look at the generated output file (I think it has the .i file extension). Then judge from the replaced output what you would consider it to be.
Title: Re: Function MACRO or #DEFINE?
Post by: Andreas Schnellbacher on October 22, 2021, 10:20:50 am
Aren't macros defined with #define? I won't handle simple text replacements different from replacements that include a function call or have multiple lines.
Title: Re: Function MACRO or #DEFINE?
Post by: Dariusz Piatkowski on October 22, 2021, 03:13:09 pm
Hey Guys!

Yeah, you bring up an excellent point. I was driven by this definition as I covered the OS2_DevToolkit, and it seemed to work OK. The criteria that separated a static #DEFINE from a MACRO for me was whether the definition was specifying the use of a parameter. In hindsight I think this may have been a bit of an arbitrary call, after all, a macro does not necessairly have to use a parameter, it could be just as you pointed out, a multi-line statement.

However, that being the OS2_DevToolkit, I think it was pretty clean. Although I'm having to re-visit some of this in light of asking these types of questions, and learning a bit more about the structures as I look at the IBMCPP_DevToolkit.

Yes, MACROS are declared using a #DEFINE, and my challenge is in determing how to correctly (given the VSE limitations) differentiate a true static #define (so let's say "#define IMPORTANT_NUMBER 100") from a #DEFINE which actually creates a MACRO, or is a reference to an existing C library function (that may require a re-name given things like a single or multi-threaded library use, debug or not, unicode use, etc.).

I am nearly done with the IBMCPP_DevToolkit, and given the significant number of these library function dependencies I am going to consider all #DEFINEs of a function name to be a MACRO.

This will require me to go back through the OS2_DevToolkit though and make sure I catch all the multi-line MACRO definitions, as Lars brought up an excellent point I think.

Thanks you guys, appreciate the feedback.

The next big step is to embark on the GCC_DevToolkit pass.
Title: Re: Function MACRO or #DEFINE?
Post by: Dave Yeo on October 22, 2021, 05:00:28 pm
While Lars's description of a macro actually doing something sounds right, I've consistently seen things like "#define __OS2__ 1" referred to as a macro.
Title: Re: Function MACRO or #DEFINE?
Post by: Dariusz Piatkowski on October 23, 2021, 04:08:18 pm
You know, to complicate things further, even the IBMCPP 3.6.5 docs sometimes intermittently change the descriptions of what's a MACRO and what's a STATIC define, for example:

in reference to the following source contained in STDIO.H:

Code: [Select]
#define _IOFBF              1   /* Buffer modes */
   #define _IOLBF              2
   #define _IONBF              3
   #define BUFSIZ           4096   /* Default buffer size */
   #define EOF              (-1)
   #define L_tmpnam          260   /* Maximum length of temporary names */
   #define FOPEN_MAX          20   /* Minimum number of open files guaranteed */
   #define FILENAME_MAX      260   /* Maximum file name length */
   #define SEEK_SET            0   /* fseek constants */
   #define SEEK_CUR            1
   #define SEEK_END            2
   #define TMP_MAX        100000   /* Maximum guaranteed unique file names */

   #define _IOEOF         0x0001   /* EOF flag mask */
   #define _IOERR         0x0002   /* ERR flag mask */

the HTML docs actually state the following:

...The macros SEEK_CUR, SEEK_END, and SEEK_SET expand to integral constant expressions and can be used as the third argument to fseek.

The macros _IOFBF, _IOLBF, and _IONBF expand to integral constant expressions with distinct values suitable for use as the third argument to the setvbuf function...

Clearly, these #define statements all point to a real value, none of these have even a simple +/- type of a calculation in them...sigh!