[Please do not mail me a copy of your followup] I want to make custom assertion methods that report the failure location as the place where the custom assertion is invoked, not the location where the BOOST_REQUIRE_xxx macros are used in the implementation of the custom assertion. In my own code, when I wanted to do report the point of invocation instead of the point of implementation, I implemented my code along the lines of void report(char const* file, int line) { // ... // output a message using line and file // ... } #define REPORT() report(__FILE__, __LINE__) void code() { REPORT(); // report something interesting here } When I look at how the assertion macros are implemented in Boost.Test, it seems that __FILE__ and __LINE__ are substituted down pretty far in the macro invocation chain. This means that if I want to write my own custom assertion that reports messages at the point of invocation and not at the point of implementation, I have to call these very low-level macro facilities and duplicate a bunch of stuff that's in Boost.Test. One thing I don't want to do is make a gigantic multi-line macro for my custom assertion. I really don't like using macros for things that could be done with functions and a custom assertion, IMO, falls into that category. Is there a clean way of implementing a custom assertion in the manner I've described without replicating a bunch of the intermediate layers of Boost.Test's macros? Gennady, if you're reading this and there isn't a clean way of doing what I'd like, are you willing to accept a refactoring changeset that promotes __FILE__ and __LINE__ arguments higher in the macro call chain? -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com