Sign in to follow this  

#Define error formatting needed

This topic is 4308 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've noticed that I do the same thing often (Typo's aside, guessing the copde) std::string Error; Error += __File__ Error += __Line__ Error += __Function_ Error += "Message about error" throw std::runtime_error(Error); ... or something like that. I do this so I can get some context as to the location and scope of the error. Some might be caught and logged if they can be recovered from, others might abort the app. In both cases, I, as the programmer want some information about whats up rather than having to type our a good deal of text for every message to work it out. So far I had been building my scope like this: Error = "WMI : CoInitializeEx : A previous call to CoInitializeEx specified a different concurrency model for the calling thread, or the thread that called CoInitializeEx currently belongs to the neutral threaded apartment. "; Which is a lot more work. What kind of macro can I use to speed this up a bit? I'm pretty sure the macro is needed so that __FILE__ stuff ends up referencing the correct file. Do you guys use somethng similar?

Share this post


Link to post
Share on other sites
Generally speaking... [grin]

First off, __FILE__, __LINE__, __FUNCTION__ are only valid at compile time - and __FUNCTION__ isn't part of the standard - so different compilers might use different tokens, __function__ for example. It's also possible that those tokens are only defined for debug builds, so it's not good to write code that depends on them in release mode.

These tokens are replaced at compile time by the actual strings they represent. This means that using them can introduce a lot of extra and uncessary "fat" to the program (even if it's just debug mode). For example, __FILE__ might include the full path of the source file and multiplied by a dozen uses that can add up. If that is the case, consider declaring the filename once as a global and then referencing that variable. For example:


#define DECLARE_FILENAME() static const LPTSTR filename = _T(__FILE__)


(This is Windows based).

Declaring these variables as static const directs the linker to store them in the .data section of the pe file rather than as a local variable. This can be more important with __FUNCTION__, as it only exists inside the function definition and only at compile time.

static const LPSTR funcname = __func__;

Share this post


Link to post
Share on other sites
Try *something* like this

#define ERROR_MSG( MSG) {std::string Error;Error += __FILE__;Error += __LINE__;Error += __FUNTION_;Error += MSG;throw std::runtime_error(Error);}
Then just use the ERROR_MSG marco whereever you want,

HTHS

Paul

EDIT: Dammit the forum screws up the forwar dslashes I am using to make the macro multi line bah, hope you get the idea

Share this post


Link to post
Share on other sites
Quote:
Original post by LessBread
For example, __FILE__ might include the full path of the source file and multiplied by a dozen uses that can add up.


Actually, if the strings are marked as const, most compilers nowadays will "pool strings" and merge identical strings into one.

I use a #define sort-of like this:
#ifdef DEBUG
#define MYASSERT(flag, msg) ((flag) ? DoMyAssert(#flag, __FILE__, __LINE__, __FUNCTION__, msg) : 1)
#else
#define MYASSERT(flag, msg)
#endif

void DoMyAssert(const char *flag, const char *fname, unsigned long line, const char *func, char *msg);



With this method, the strings are only built in to your EXE in debug mode, so your release builds don't contain any unnecessary debug code.

Also, the "#flag" portion converts the assertion test into a text form, so you can print out what assertion failed. It might help to read up on preprocessor defines a bit?

Share this post


Link to post
Share on other sites

This topic is 4308 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this