ACE_DEBUG declare #include< ace/Task.h > in source header file.I trace debug define by
ACE_DEBUG((LM_ERROR, "Reader pathSetOpen : %s
",pathSetOpen);
The string variable name "pathSetOpen" for show value still execute programs.But I cannot compile code.
About ACE_DEBUG,It's macro for printing debug message.
Compile error code.
EnvTest.cpp:353:1: error: unterminated
argument list invoking macro
"ACE_DEBUG"
You've forgot a closing parenthesis:
ACE_DEBUG((LM_ERROR, "Reader pathSetOpen : %s ",pathSetOpen));
Related
I have a basic #pragma message warning
#pragma message(__FILE__ "(" _CRT_STRINGIZE(__LINE__) ") : warning : T does not have an << operator.")
This is inside a Sfinae controlled overload testing for the presence of a << operator. This warning works and gets printed to the output window and added to the Error List in VS2019.
However it is missing the extra info that "native" warnings and errors give:
[ with T = int ]
And the extra stack/instantiation trace, allowing you to work out exactly which function call is causing the issue.
Is there a way to have my warning also display this extra useful info, as it stands my warning is unable to even tell the user what type triggered the warning, let alone which section of code/method call is causing the warning.
__PRETTY_FUNCTION__ for example does not work in #pragma message as it is a const char[] and #pragma message requires a constant string i.e. "bla bla".
A bit unorthodox, but you could use a [[deprecated("...")]] in front of your SFINAE-controlled overload to have info about both the actual type and the call stack.
I suggest that you could refer to this link.
// Statements like:
// #pragma message(Reminder "Fix this problem!")
// Which will cause messages like:
// C:\Source\Project\main.cpp(47): Reminder: Fix this problem!
// to show up during compiles. Note that you can NOT use the
// words "error" or "warning" in your reminders, since it will
// make the IDE think it should abort execution. You can double
// click on these messages and jump to the line in question.
#define Stringize( L ) #L
#define MakeString( M, L ) M(L)
#define $Line MakeString( Stringize, __LINE__ )
#define Reminder __FILE__ "(" $Line ") : Reminder: "
Once defined, use like so:
#pragma message(Reminder "Fix this problem!")
This will create output like:
C:\Source\Project\main.cpp(47): Reminder: Fix this problem!
Besides, while in general, you cannot have a #pragma directive within macros, MS C/C++ compilers 2008 and above do support a special vendor-specific extension called the __pragma which can be used with macros.
I'm porting a windows based c++ project into windows, and I ran into the following error.
UeiDaqAnsiC.cpp:105:24
error: expected ')' before string constant
UEI_ERROR(__FUNCTION__ " error: %s\n", e.getErrorMessage());
It looks as though linux is unable to concatenate the __FUNCTION__ macro with the following string. This is confusing, as the project compiles and builds just fine in Windows.
As a quick fix, it appears simply adding a , between the __FUNCTION__ and "error: %s\n", e.getErrorMessage() completely fixes it.
The new fixed line looks like this UEI_ERROR(__FUNCTION__, " error: %s\n", e.getErrorMessage());
I came here because im not well versed on the linux g++ compiler, and I want to know if this is a valid workaround for this error, before I fix all 130 lines where this error occurs.
EDIT: I also want to ask if the comma keeps the functionality of simply concatenating the macro and string
EDIT2: UEI_ERROR is defined as
#define UEI_ERROR(...) UeiPalTraceOutputWithLevel(UeiPalTraceError, __VA_ARGS__)
__FUNCTION__ is not a string literal and cannot be concatenated by preprocessor with other string literal.
Your "fix" by adding , changes the meaning, mostly as
printf(__FUNCTION__ " format %i", 42); // MyFunction format 42
printf("MyFunction", "unused format %i", 42); // MyFunction
Real fix would be to change the format and reorder parameter:
UEI_ERROR("%s error: %s\n", __FUNCTION__, e.getErrorMessage());// MyFunction error: error message.
I want to print a simple message in mrhof function.
in core>net>rpl I write mrhof.c in makefile. then in rpl-conf.h I change RPL_DAG_MC_NONE to RPL_DAG_MC_ENERGY.
in mrhof.c in calculate_path_metric there is a message to print. for example I want to print Energy.
when I run one of examples like udp-rpl in cooja why I can't see the message in mote output?
It seems that your message use PRINTF macro. All PRINTFs (capped) are macros for printf (small).
For enabling this macro you should change the DEBUG constant value.
Add this to your code:
#define DEBUG DEBUG_PRINT
This snippet would enable your PRINTF macros.
For disabling debug mode and not printing any message written by PRINTF macro change to this:
#define DEBUG DEBUG_NONE
As part of a bigger project ( the ff activex plugin for Mozilla Firefox) there is this code snippet:
if (CombineRgn(hrgnClip, hrgnClip, hRGN, RGN_AND) != ERROR)
{
::InvalidateRgn(m_hWndParent, hrgnClip, fErase);
}
When I build in VS2012 I get "Error C2065: 'ERROR' : undeclared identifier"
ERROR is defined in wingdi.h like this:
...
/* Region Flags */
#define ERROR 0 // it wont build when this macro is used
#define NULLREGION 1 // it builds when this macro is used
#define SIMPLEREGION 2
#define COMPLEXREGION 3
#define RGN_ERROR ERROR
...
The strange thing is that if I replace ERROR (just to see if it builds OK) with NULLREGION or SIMPLEREGION (which are macros in the same file, just two lines below the offending one) in the if statement above, the code builds OK. When I use ERROR, the code wont build.
Is it possible that the ERROR macro defined above gets masked by some keyword or another macro or some such by Visual Studio?
The problem here is that ERROR actually appears in the compile error message. That should not happen, the preprocessor should have substituted it with 0.
So somewhere in a .h file you #included after windows.h, some programmer took the 10 second shortcut to a macro name collision problem and wrote this:
#undef ERROR
You'd need to find that line and remove it. That's likely to be difficult and liable to give you a maintenance headache since that's a file you don't own and might well be updated in the future, forcing you to make that change over and over again. The alternative is to redefine it yourself:
#define MYGDIERROR 0
...
if (CombineRgn(hrgnClip, hrgnClip, hRGN, RGN_AND) != MYGDIERROR)
//etc...
Which still gives you a maintenance problem and requires you taking a bet that the return value definition of CombineRgn() is never going to change. That's a very safe bet, GDI is cast in stone.
Keep getting warnings on lines like these
qDebug("An error occured while trying to create folder " + workdir.toAscii());
workdir being QString()
warning: format not a string literal and no format arguments
That should probably be:
qDebug("An error occured while trying to create folder %s", workdir.constData());
since qDebug takes const char* as first argument.
When debbuging with qDebug, I find the following syntax much easier :
qDebug() << "An error occured while trying to create folder" << workdir;
To do this, you'll need to include the <QtDebug> header.
More info : Qt docs regarding qDebug().
I managed to get it to work fine without warning like this :
qDebug("An error occurred while trying to create folder %s", qUtf8Printable(workdir));