Apparently you can overload keywords like ''return'' with #defines. Example:

  
#define return(R,G,B)   {return D3DCOLOR_COLORVALUE(R,G,B);}

int NormalReturn ( )
{
    return 0; // Uses the return keyword.

}

int D3DReturn ( )
{
    return( 1, 0, 0.5 ); // Uses the return macro.

}
  

I don''t use that exact code, that''s just a simple example. But I''m curious as to how people feel about this code. Is it bad code design? The Visual C++ 6.0 compiler allows it with no warnings, I don''t know about other compilers though. Is it technically ANSI-uncompatible? ~CGameProgrammer( );

It is perfectly valid code, though it is clearly confusing, perhaps even to the original programmer.

The #define statements aren''t handled by the compiler, they are handled by the preprocessor, and the preprocessor doesn''t care (and shouldn''t, IMO) if you redefine reserved words.

There are, after all, rare but possible instances where such redefinition is helpful (perhaps you want to create a macro from a debug build that checks the return types of many different functions on some existing code and don''t want to have to edit each function..If they all return the same data type, you could just shoehorn it in with a #define macro). That''s just one simple example, there''s many others.

In short, its up to the programmer to use #defines wisely.

It think that particular example would be a bad design. You should some how distingish the a D3DColor return from other 3 parameter returns.

#define Color_return(R,G,B) (return D3DCOLOR_COLORVALUE(R,G,B))

#define Vector_return(x,y,z) (return D3DVECTOR(x,y,z))


I personally avoid #define''s for actual code. I use them to determine compile routes if I want somthing special for _DEBUG builds and for header inclusions etc... Once you make a #define name - you can never use name in your code without the preprocessor whacking it.

For instance, you cannot create a class with a method called CreateWindow, because that''s a Win32 macro that decides whether to call the ansi or unicode version. If you''re programming in C, its not such a big deal.



Magmai Kai Holmlor
- The disgruntled & disillusioned

I agree that example would be a bad one, I only wrote it as just that: an example. My actual code (which works) calls any base class'' version of a virtual function. So if you have:

class A { virtual int Function (); }
class B:public A { virtual int Function (); }
class C:public B { virtual int Function (); }
class D:public C { virtual int Function (); }

And you want D::Function() to do some stuff, and then call B::Function(), the macro I wrote can do that. I find it really handy. Overloading ''return'' has nothing to do with the algorithm, except I was thinking of calling one version of the macro ''return'', so you can say return(int, B, Function()).

~CGameProgrammer( );


return B::Function();



Why bother making a macro for stuff that the language already supports?

Hehe, I never even knew you could do that. I assumed the compiler would think you're trying to call a static function and generate an error. So my macro changed the v-table to the class whose function you want to call, calls the function, then restores the original v-table. (The v-table is the first four bytes in any object with a virtual function or derived from a class with a virtual function.)

Edited by - CGameProgrammer on February 19, 2001 12:53:55 PM

quote: Original post by CGameProgrammer

... So my macro changed the v-table to the class whose function you want to call, calls the function, then restores the original v-table. (The v-table is the first four bytes in any object with a virtual function or derived from a class with a virtual function.)

Thats completely hilariously cool. Yes its useless, pointless and not recommended, but it''s a great hack.

Reminds me of when I wrote my own round() function (horribly inefficient btw) and then a person from my class just showed me the normal one.

--------------------------
I guess this is where most people put a famous quote...
"Everything is funnier with monkey''''s" - Unknown

quote:
I assumed the compiler would think you''re trying to call a static function and generate an error.

It will, unless you write that line of code inside a method of a derived class who''s parent has a method called Function();

PS That''s how you can call a method with the same name from two different parents, if you ever run into that case.


Magmai Kai Holmlor
- The disgruntled & disillusioned