Advertisement

To macro or not to macro, that is the question

Started by September 25, 2000 06:03 PM
11 comments, last by DW-za 24 years, 3 months ago
Yes I know what you are talking about:

DECLARE_INTERFACE(interface)
DECLARE_INTERFACE_(interface, baseinterface)

STDMETHOD
STDMETHODIMP
STDMETHODIMP_(retval)

// etc.


Still, you do understand why they do this, don't you? The reason is for aiding in the portability of code to other platforms and compilers. Its a small price to pay for portability (then again how many systems has COM been ported to).

I still agree that some macros can be really annoying - especially large ones that hide important implementation details.

- Dire Wolf
direwolf@digitalfiends.com

Edited by - Dire.Wolf on September 27, 2000 3:55:09 PM
[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com
i''m currently using one macro in my source:
#define HINST GetModuleHandle(NULL) //Little ShortCut for smaller source
its just boring to write everytime the functioncall (and, in the CreateWindowEx() its even really stupid, because i wanna see it at one line..

but what i wanted to say:
my only macro, that you couldnt create with inline is the TRY(a)

#define TRY(a) {if(!(a)){MessageBox("Error (just an example");return FALSE}
and why?!
because, when I have a function for initializeing DX, i just do something like this:

#define TRY(a) {if((a)!=DD_OK)..restof code...)
BOOL initDXStuff()
{
code with alot of TRY()es
return TRUE;
}
#undef TRY

after that I redef my TRY for another function..
its just to speed up writeing (and reading, because TRY means allways the same thing in the source, just for some API''s, with other "real source" in the #define

i like macros for shorting up code, not speeding up it
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia

My Page davepermen.net | My Music on Bandcamp and on Soundcloud

Advertisement
In my opinion, macros are simply for saving time when doing repetive things to clean up your code, e.g. in error loggers where you are only presented with an error code and you want a description of the error.

            LogError(char *Where, int Line, HRESULT hResult, char *FileName){	char*	Description;		switch (hResult)	{	ErrorHandler(DDERR_ALREADYINITIALIZED, "The object has already been initialized.");	ErrorHandler(DDERR_BLTFASTCANTCLIP, "A DirectDrawClipper object is ...");	ErrorHandler(DDERR_CANNOTATTACHSURFACE, "A surface cannot be attached...");	ErrorHandler(DDERR_CANNOTDETACHSURFACE, "...");	...and so on[/source]The above code uses the ErrorHandler macro, which is defined as:[source]//Damn useful macro for error handlers, takes an error code and description#define ErrorHandler(Code, Msg) case Code:	Description = Msg;	break;[/source]This makes the code much more a) maintainable if it needs to beupdated/fixed, and b)cleaner/easier to read compared to theoriginal (no macro) version below.[source]LogError(char *Where, int Line, HRESULT hResult, char *FileName){	char*	Description;		switch (hResult)	{	case DDERR_ALREADYINITIALIZED:		Description = "...");		break;	case DDERR_BLTFASTCANTCLIP:		Description = "...");		break;	case DDERR_CANNOTATTACHSURFACE:		Description = ...");		break;	case DDERR_CANNOTDETACHSURFACE:		Description = "...");		break;	...            


There's a lot of unnecessary typing here that just makes the
code messy, I'm hoping I'll still be able to type when I'm 40,
but if I have to type those error handlers every time I'll have
RSI by next month.

Sorry for the long post, but hey, other opinions are great, aren't they?.



Edited by - mr_jrt on September 29, 2000 8:49:32 PM
Waassaap!!

This topic is closed to new replies.

Advertisement