OS/2, eCS & ArcaOS - Technical > Programming

Function MACRO or #DEFINE?

(1/2) > >>

Dariusz Piatkowski:
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: ---...
#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

--- End code ---

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?

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.

Andreas Schnellbacher:
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.

Dariusz Piatkowski:
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.

Dave Yeo:
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.


[0] Message Index

[#] Next page

Go to full version