• fluffy (unregistered)

    Someone needs to learn about inline functions. Among other things.

    Care to share any of the code which uses these macros? I'm especially interested to see the contexts in which FROMBUFFERTO_INT_VARIABLE turns up, what with it having a return in it...

  • Ashley (unregistered)

    He could have at least gone the whole way and created a macro for the variable name too...

    #define FROMBUFFERTO_VARIABLENAME pszLocal

  • Brent Railey (unregistered)

    DUDE!!! I wish I had some code from my last job. They generated ENTIRE com object methods in C++ using macros.

    Looked like a great reuse of redundant code, but it was a pain in the &$$ to debug. (I was an automated tester, but I could attach debuggers when failures occured to get an idea of the defect and communicate it to the "real" programmers)

    I often wondered if they've heard of templates in C++.

  • Aarrgghh (unregistered)

    Haven't looked at it in years, but Raima Object Manager used to define C++ classes with macros; it seems that the code was written way back when C++ templates couldn't do something they needed (or maybe didn't exist at all? Or maybe somebody just hadn't bothered learning C++ very well...). What a nightmare. They also re-defined the left-shift and right-shift operators to do strange things.

  • Randy Glenn (unregistered)

    Um... at least he labelled what would break in weird and wonderful ways if changed?

    I've got nothing.

  • Tatl (unregistered)

    WTF!

    Why not just have a macro for the ENTIRE code, and then the main body of code can just be one line!

  • Uwe Keim (unregistered)

    Funny :-)

  • Mike R. (unregistered)

    "They generated ENTIRE com object methods in C++ using macros"

    Ack.. I'm guilty of this... For certain types of methods... get/set with a dirty bit, I did just that.. But I also used a lot of templates in the same code.

    If I weren't so embarrased by my coding transgressions... it would be a shoe-in for TDWTF.

  • mschaef (unregistered)

    C/C++ Macros are underrated... Sure, they can cause lots of problems, but occasionally they offer a useful (and relatively cheap) way to create some interesting abstractions.

    I was doing some benchmarking recently, and needed a quick way to print evaluation times of particular C statements. Voila:

    #define REPEAT_COUNT (100)

    #define PRINT_EXEC_TIME(statement)

    {

    double now = timeNow();



    for(int i = 0; i < REPEAT_COUNT; i++) { statement; }



    printf("%s, t = %f\n", #statement, (timeNow() - now) / REPEAT_COUNT);

    }

    I've also found macros useful to formalize the calling convention for an error handling system in a system I was developing, among other things.

  • Brent Railey (unregistered)

    I need to clarify...

    They generated entire sets of member declaration, collection class implementations, sets of member methods with macros.

    Some of these macros has 10 to twelve "parameters" which introduced programmer error, which made it a pain to debug, because you didn't know if the coder passed a dumb parameter to the macro, or there was a bug in the macro'ed code. I often had to cut 'n paste the code, do search / replace with the parameters, and rebuild the module to find out what the defect was.

    Some macros were well over 200 lines long...

    Our contracted developers were like WTF is up with all these macros?

  • Brent Railey (unregistered)

    But, for small redunant tasks, that are, of course, well tested, macros are awesome.

  • G Dawg (unregistered)

    I wish I could get my hands on the DELETEMEMORY macro. It sure sounds useful.

  • Brian (unregistered)

    My favourite part is the typo in the macro name: ASSINGN_CHAR_DATA :-)

  • Bitter (unregistered)

    Really? My favourite part is where the so-called "INT_VARIABLE" macro casts its result to short.

  • Stern (unregistered)

    "Someone needs to learn about inline functions."

    Remember, the compiler treats "inline" as a hint, nothing guarantees the function will actually be inlined.

  • mschaef (unregistered)

    "Remember, the compiler treats "inline" as a hint, nothing guarantees the function will actually be inlined. "

    If you're dead set on inlining a function and using MSVC, you can use __forceinline. Disabling inlining disables __forceinline, but when inlining is enabled (and a function isn't recursive, etc.) __forceinline does exactly what it says it does.

    I've used it to ensure that code that does licensing checks is not stuck in one function in the actual binary.

  • Warp (unregistered)

    Actually most C++ compilers ignore the word 'inline' altogether when they are deciding if they should inline the function or not. That is, 'inline' has no effect whatsoever on the chances of a function to be inlined. In this regard 'inline' is as obsolete as eg. 'register'.

    However, 'inline' is not a completely obsolete keyword (as 'register' is) because it has a crucial role in the linking stage. In a way, 'inline' is the opposite of 'static' (while 'static' duplicates a function for each object file it appears in, 'inline' makes sure that the linker merges all the appearances to one).

Leave a comment on “The Guy Who Invented Functions”

Log In or post as a guest

Replying to comment #:

« Return to Article