# #Define error formatting needed

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

## 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 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 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 on other sites
Quote:
 Original post by LessBreadFor 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)#endifvoid 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?

1. 1
2. 2
3. 3
Rutin
22
4. 4
5. 5

• 13
• 19
• 14
• 9
• 9
• ### Forum Statistics

• Total Topics
632930
• Total Posts
3009289
• ### Who's Online (See full list)

There are no registered users currently online

×