Using a integer for OutputDebugString in VS2017 - c++

I've been searching around on the web for a while on how to output a integer or optionally a float using OutputDebugString().
It would be easier if i could write my debug data straight to the console from my external executable using this command. However i only got it to work with a const char.
The solutions i found were outdated i tried copy and pasting the code straight from the web but didn't work. Even after modifying the code i couldn't get it to typecast correctly.
Is there anyone that could help me typecast something into the OutputDebugString as clean as possible, it's for debugging purposes only so i rather keep the code short and easily readable than having a more complex and clunky typecast IF that is possible. Many thanks!

Provided alternatively solution. The function below encapsulates OutputDebugString that can accept formatted arguments.
#include <vector>
#include <string>
void DbgMsg(const char * zcFormat, ...)
{
// initialize use of the variable argument array
va_list vaArgs;
va_start(vaArgs, zcFormat);
// reliably acquire the size
// from a copy of the variable argument array
// and a functionally reliable call to mock the formatting
va_list vaArgsCopy;
va_copy(vaArgsCopy, vaArgs);
const int iLen = std::vsnprintf(NULL, 0, zcFormat, vaArgsCopy);
va_end(vaArgsCopy);
// return a formatted string without risking memory mismanagement
// and without assuming any compiler or platform specific behavior
std::vector<char> zc(iLen + 1);
std::vsnprintf(zc.data(), zc.size(), zcFormat, vaArgs);
va_end(vaArgs);
std::string strText(zc.data(), iLen);
OutputDebugStringA(strText.c_str());
}
For example, the code below shows how to print an integer variable by OutputDebugString through DbgMsg().
int foo=12;
DbgMsg(" foo=%d", foo);

OutputDebugString can only take strings, if you want formatted output you will have to do that yourself before feeding it to OutputDebugString. If you are using MSVC I suggest that you use _CrtDbgReport or _CrtDbgReportW. With recent versions of MSVC that support variadic macros I use the following:
#if !defined(_RPTW)
#if defined(_DEBUG)
#define _RPTW(pszFmt, ...) _CrtDbgReportW(_CRT_WARN, NULL, __LINE__, NULL, (pszFmt), __VA_ARGS__)
#define _RPTW_(dest, fmt, ...) _CrtDbgReportW((dest), NULL, __LINE__, NULL, (pszFmt), __VA_ARGS__)
#else
#define _RPTW(pszFmt, ...)
#define _RPTW(dest, pszFmt)
#endif
#endif // #if !defined(_RPTW)
#if !defined(_RPTA)
#if defined(_DEBUG)
#define _RPTA(pszFmt, ...) _CrtDbgReport(_CRT_WARN, NULL, __LINE__, NULL, (pszFmt), __VA_ARGS__)
#define _RPTA_(dest, fmt, ...) _CrtDbgReport((dest), NULL, __LINE__, NULL, (pszFmt), __VA_ARGS__)
#else
#define _RPTA(pszFmt, ...)
#define _RPTA_(dest, pszFmt)
#endif
#endif // #if !defined(_RPTA)
#if !defined(_RPTT)
#if defined(_UNICODE)
#define _RPTT _RPTW
#define _RPTT_ _RPTW_
#else
#define _RPTT _RPTA
#define _RPTT_ _RPTA_
#endif
#endif // #if !defined(_RPTT)
The second forms allow providing a different level of report (_CRT_ASSERT or c_CRT_ERROR instead of _CRT_WARN)

I would recommend to use sprintf like that:
// issues with the int x, let's output and look at it in DebugView
char msg[255] = {0};
sprintf(msg, ">> Watch out x=%d\n", x);
OutputDebugString(msg);
Maybe I did not understand the question, but that's how I quickly dump integers. And to be honest I do not know these MACROS which SoronelHaetir listed but indeed you've got to format yourself. So I Hope this helps and is rather straight forward.

Related

What's the best way #define macro Function used in linux and windows?

WindowsAPI functions currently used in the following examples for Linux
I want to use it as one definition depending on the platform.
example.
#ifdef _WIN32
::CopyMemory(dest, readBuffer_ + fileOffset - readBufferOffset_, size);
#elif __linux__
memcpy(dest, readBuffer_ + fileOffset - readBufferOffset_, size);
#endif
If there are a lot of processing like the above in the code, the readability is reduced.
So I want to use something like this, but I'm not sure what is a good way to do it.
#ifdef _WIN32
#define MEM_COPY CopyMemory
#define SET_FILE_POINTER SetFilePointer
#define READ_FILE ReadFile
#elif __linux
#define MEM_COPY memcpy
#define SET_FILE_POINTER lseek // parameter sequence not equal to SetFilePointer
#define READ_FILE read
#endif
int main()
{
// i wanna use one function (READ_FILE) both in linux and Windows
READ_FILE(dest, readBuffer_ + fileOffset - readBufferOffset_, size);
}
I have an additional question.
Windows has many safety functions.
ex) fopen_s
memcpy_s
in linux
I've seen memcpy used frequently. How do you usually judge a standard that guarantees safety?
(Is it ok to just use it normally? I have the linux manual manpage,
I saw the note contents.)
I would use an abstraction layer for that in a namespace:
namespace OperatingSystemFunctions
{
static void CopyMemory(arguments)
{
#ifdef _WIN32
::CopyMemory(dest, readBuffer_ + fileOffset - readBufferOffset_, size);
#elif __linux__
memcpy(dest, readBuffer_ + fileOffset - readBufferOffset_, size);
#endif
}
}
int main()
{
MyMemoryCopy::CopyMemory(...);
}
Of course the arguments needs to match for that approach.

When running an MFC application is there a way to output to a "console"?

I'm used to developing with C++ in Qt Creator, much more so than Visual Studio. In the former, you can do something like this
qDebug()<< my_trace_string;
to output my_trace_string to a "console" which can be handy so that you can see what is going on.
I wondered if there is a Visual Studio window to which an application can easily write, independently of the dialogs and controls. This is complementary to the use of the debugger. It leaves a visual trace for example.
OutputDebugString() from debuapi.h (just #include <windows.h>) is your friend. I usually wrap it up into a function like this (use A suffix for ASCII or W suffix for for UNICODE):
void dbgMsg(PCWSTR _format, ...)
{
va_list args;
va_start(args, _format);
WCHAR msg[MAX_PATH];
if(SUCCEEDED(StringCbVPrintfW(msg, sizeof(msg), _format, args))){
OutputDebugStringW(msg);
}
}
That will output into Output window in IDE (next to Call stack, Error List and others)
In Visual Studio when working on GUI programs the usual method for such is to use the _RPTX (where X is the number of varadic parameters) macros which when report type is _CRT_WARN print to the Output window within VS itself rather than use an external console window.
For example:
_RPT1(_CRT_WARN, __FUNCTION__ ": hWnd: %#x\r\n", m_hWnd);
Personally I prefer using the following (custom) macros which do not take the report type (I simple use _CRT_WARN) and also do away with the need to know the number of vararg parameters and also the ability to take more than 4 vararg parameters (the limit with the default macros). The _RPT macros have simply never been updated to take advantage of the variadic macro capable preprocessor:
#if !defined(_RPTW)
#if defined(_DEBUG)
#define _RPTW(pszFmt, ...) _CrtDbgReportW(_CRT_WARN, NULL, __LINE__, NULL, (pszFmt), __VA_ARGS__)
#define _RPTWF(dest, fmt, ...) _CrtDbgReportW((dest), _T(__FILE__), __LINE__, NULL, (pszFmt), __VA_ARGS__)
#else
#define _RPTW(pszFmt, ...)
#define _RPTWF(dest, pszFmt)
#endif
#endif // #if !defined(_RPTW)
#if !defined(_RPTA)
#if defined(_DEBUG)
#define _RPTA(pszFmt, ...) _CrtDbgReport(_CRT_WARN, NULL, __LINE__, NULL, (pszFmt), __VA_ARGS__)
#define _RPTAF(dest, fmt, ...) _CrtDbgReport((dest), __FILE__, __LINE__, NULL, (pszFmt), __VA_ARGS__)
#else
#define _RPTA(pszFmt, ...)
#define _RPTAF(dest, pszFmt)
#endif
#endif // #if !defined(_RPTA)
#if !defined(_RPTT)
#if defined(_UNICODE)
#define _RPTT _RPTW
#define _RPTTF _RPTWF
#else
#define _RPTT _RPTA
#define _RPTTF _RPTAF
#endif
#endif // #if !defined(_RPTT)
Using the custom macros the original example becomes:
_RPTA(__FUNCTION__ ": hWnd: %#x\r\n", m_hWnd);
The original way does have the benefit of taking the report type as a parameter, using that output can be redirected to a window (as _ASSERT does), the output window (the default with _CRT_WARN) or to a trace file (requires calling _CrtSetReportMode and _CrtSetReportFile).
First of all you could try to call the AllocConsole function to create a Console for your process.
Send your output to the console via _cprintf()And don't forget to #include wherever you use _cprintf()
If you need to close the console output, call FreeConsole();
For more details you could refer to this link

Macro auto-injecting argument without VARIADIC support

I have a macro with varargs that auto injects some arguments, like the first below injecting the argument "__FNAME__":
#ifdef VERBOSE
#define logdbg(format, ...) debugff(__FNAME__, format, ##__VA_ARGS__)
#elif defined(NORMAL)
#define logdbg(format, ...) debugf(format, ##__VA_ARGS__)
#else
#define logdbg(format, ...) /* debud off */
#endif
But I need to keep this macro working with compilers without MACRO VARIADIC support (in SCO Unix and AIX 4.3 Copmiler v3).
In these environments I have now:
#ifdef VERBOSE
#define logdbg debugff(__FNAME__, format, ##__VA_ARGS__)
#elif defined(NORMAL)
#define logdbg debugf
#else
#define logdbg if(1);else debugf
#endif
These compilers didn't accepted the comment in the last macro definition, and I get the if(1);else blablabla that works fine from https://stackoverflow.com/a/687412/926064
But I need yet a solution to the first case, where an argument is "injected" by macro.
Some workaround to do that ?
EDIT:
As it isn't a software with multithread support, I'm thinking to change the debug 'framework' to inject the arguments using side functions to set values in 'context' variables (global, static, etc):
#define logdbg pass_args(__FNAME__); debugf
More possibles workarounds ?
Assuming it is impossible to use a different compiler (which seems a dubious requirement, but let's put that aside), for certain, you will need a different function for logdbg to expand into. Probably, that function would take the __FNAME__ argument from another source, like a global variable.
#define logdbg ((logdbg_fname__ = __FNAME__), debugff_broken)
void debugff_broken(const char *fmt, ...) {
extern const char *logdbg_fname__;
va_list ap;
va_start(ap, fmt);
vdebugff(logdbg_fname__, fmt, ap);
va_end(ap);
}
Where vdebugff is like debugff except it takes a va_list.
If thread safety is required, use thread specific storage instead of a common global.

What use cases necessitate #define without a token-string?

I have encountered the #define pre-processor directive before while learning C, and then also encountered it in some code I read. But apart from using it to definite substitutions for constants and to define macros, I've not really understook the special case where it is used without a "body" or token-string.
Take for example this line:
#define OCSTR(X)
Just like that! What could be the use of this or better, when is this use of #define necessary?
This is used in two cases. The first and most frequent involves
conditional compilation:
#ifndef XYZ
#define XYZ
// ...
#endif
You've surely used this yourself for include guards, but it can also be
used for things like system dependencies:
#ifdef WIN32
// Windows specific code here...
#endif
(In this case, WIN32 is more likely defined on the command line, but it
could also be defined in a "config.hpp" file.) This would normally
only involve object-like macros (without an argument list or
parentheses).
The second would be a result of conditional compilation. Something
like:
#ifdef DEBUG
#define TEST(X) text(X)
#else
#define TEST(X)
#endif
That allows writing things like:
TEST(X);
which will call the function if DEBUG is defined, and do nothing if it
isn't.
Such macro usually appears in pair and inside conditional #ifdef as:
#ifdef _DEBUG
#define OCSTR(X)
#else
#define OCSTR(X) SOME_TOKENS_HERE
#endif
Another example,
#ifdef __cplusplus
#define NAMESPACE_BEGIN(X) namespace X {
#define NAMESPACE_END }
#else
#define NAMESPACE_BEGIN(X)
#define NAMESPACE_END
#endif
One odd case that I recently dug up to answer a question turned out to be simply commentary in nature. The code in question looked like:
void CLASS functionName(){
//
//
//
}
I discovered it was just an empty #define, which the author had chosen to document that the function accessed global variables in the project:
C++ syntax: void CLASS functionName()?
So not really that different from if it said /* CLASS */, except not allowing typos like /* CLAAS */...some other small benefits perhaps (?)
I agree with every answer, but I'd like to point out a small trivial thing.
Being a C purist I've grown up with the assertion that EACH AND EVERY #define should be an expression, so, even if it's common practice using:
#define WHATEVER
and test it with
#ifdef WHATEVER
I think it's always better writing:
#define WHATEVER (1)
also #debug macros shall be expressions:
#define DEBUG (xxx) (whatever you want for debugging, value)
In this way, you are completely safe from misuse of #macros and prevents nasty problems (especially in a 10 million line C project)
This can be used when you may want to silent some function. For example in debug mode you want to print some debug statements and in production code you want to omit them:
#ifdef DEBUG
#define PRINT(X) printf("%s", X)
#else
#define PRINT(X) // <----- silently removed
#endif
Usage:
void foo ()
{
PRINT("foo() starts\n");
...
}
#define macros are simply replaced, literally, by their replacement text during preprocessing. If there is no replacement text, then ... they're replaced by nothing! So this source code:
#define FOO(x)
print(FOO(hello world));
will be preprocessed into just this:
print();
This can be useful to get rid of things you don't want, like, say, assert(). It's mainly useful in conditional situations, where under some conditions there's a non-empty body, though.
As you can see in the above responses, it can be useful when debugging your code.
#ifdef DEBUG
#define debug(msg) fputs(__FILE__ ":" (__LINE__) " - " msg, stderr)
#else
#define debug(msg)
#endif
So, when you are debugging, the function will print the line number and file name so you know if there is an error. And if you are not debugging, it will just produce no output
There are many uses for such a thing.
For example, one is for the macro to have different behavior in different builds. For example, if you want debug messages, you could have something like this:
#ifdef _DEBUG
#define DEBUG_LOG(X, ...) however_you_want_to_print_it
#else
#define DEBUG_LOG(X, ...) // nothing
#endif
Another use could be to customize your header file based on your system. This is from my mesa-implemented OpenGL header in linux:
#if !defined(OPENSTEP) && (defined(__WIN32__) && !defined(__CYGWIN__))
# if defined(__MINGW32__) && defined(GL_NO_STDCALL) || defined(UNDER_CE) /* The generated DLLs by MingW with STDCALL are not compatible with the ones done by Microsoft's compilers */
# define GLAPIENTRY
# else
# define GLAPIENTRY __stdcall
# endif
#elif defined(__CYGWIN__) && defined(USE_OPENGL32) /* use native windows opengl32 */
# define GLAPIENTRY __stdcall
#elif defined(__GNUC__) && (__GNUC__ * 100 + __GNUC_MINOR__) >= 303
# define GLAPIENTRY
#endif /* WIN32 && !CYGWIN */
#ifndef GLAPIENTRY
#define GLAPIENTRY
#endif
And used in header declarations like:
GLAPI void GLAPIENTRY glClearIndex( GLfloat c );
GLAPI void GLAPIENTRY glClearColor( GLclampf red, GLclampf green, GLclampf blue, GLclampf alpha );
GLAPI void GLAPIENTRY glClear( GLbitfield mask );
...
(I removed the part for GLAPI)
So you get the picture, a macro that is used in some cases and not used in other cases could be defined to something on those cases and nothing to those other cases.
Other cases could be as follows:
If the macro doesn't take parameters, it could be just to declare some case. A famous example is to guard header files. Another example would be something like this
#define USING_SOME_LIB
and later could be used like this:
#ifdef USING_SOME_LIB
...
#else
...
#endif
Could be that the macro was used at some stage to do something (for example log), but then on release the owner decided the log is not useful anymore and simply removed the contents of the macro so it becomes empty. This is not recommended though, use the method I mentioned in the very beginning of the answer.
Finally, it could be there just for more explanation, for example you can say
#define DONT_CALL_IF_LIB_NOT_INITIALIZED
and you write functions like:
void init(void);
void do_something(int x) DONT_CALL_IF_LIB_NOT_INITIALIZED;
Although this last case is a bit absurd, but it would make sense in such a case:
#define IN
#define OUT
void function(IN char *a, OUT char *b);

Use #ifdefs and #define to optionally turn a function call into a comment

Is it possible to do something like this
#ifdef SOMETHING
#define foo //
#else
#define foo MyFunction
#endif
The idea is that if SOMETHING is defined, then calls to foo(...) become comments (or something that doesn't get evaluated or compiled), otherwise it becomes a call to MyFunction.
I've seen __noop used, but I don't believe I can use that.
EDIT(s):
I don't think I can really use a macro here, because MyFunction takes a variable number of arguments.
Also, I'd like to make it so the arguments are NOT evaluated! (So doing something like commenting out the body of MyFunction doesn't really give me what I need, as the arguments will still be evaluated)
Try this:
#ifdef SOMETHING
#define foo(x)
#else
#define foo(x) MyFunction(x)
#endif
If your function has several arguments, then:
#ifdef SOMETHING
#define foo(x,y,z)
#else
#define foo(x,y,z) MyFunction(x,y,z)
#endif
If your function has a variable number of arguments, then your compiler may support so-called "variadic macros", like this:
#ifdef SOMETHING
#define foo(...)
#else
#define foo(...) MyFunction(__VA_ARGS__)
#endif
The reason which I've seen this kind of thing used in practice is to get rid of logging functions from a release build. However, see also Separate 'debug' and 'release' builds? in which people question whether you should even have different builds.
Alternatively, instead of redefining the function call as nothing, Jonathan's comment to this answer suggested doing something like the following:
#ifdef SOMETHING
#define foo(...) do { if (false) MyFunction(__VA_ARGS__) } while (0)
#else
#define foo(...) do { if (true) MyFunction(__VA_ARGS__) } while (0)
#endif
The reasoning for doing this is so that the function call is always compiled (so it won't be left with gratuitous errors like references to deleted variables), but only called when needed: see Kernighan & Pike The Practice of Programming and also the Goddard Space Flight Center programming standards.
From a debug.h file (originating from 1990, and therefore not using __VA_ARGS__):
/*
** Usage: TRACE((level, fmt, ...))
** "level" is the debugging level which must be operational for the output
** to appear. "fmt" is a printf format string. "..." is whatever extra
** arguments fmt requires (possibly nothing).
** The non-debug macro means that the code is validated but never called.
** -- See chapter 8 of 'The Practice of Programming', by Kernighan and Pike.
*/
#ifdef DEBUG
#define TRACE(x) db_print x
#else
#define TRACE(x) do { if (0) db_print x; } while (0)
#endif /* DEBUG */
With C99, there's no longer a need for the double parentheses trick. New code should not use it unless C89 compatibility is an issue.
Maybe an easier way to do this would be to conditionally omit the body of the function?
void MyFunction() {
#ifndef SOMETHING
<body of function>
#endif
}
Unless you specifically don't want a function call to be made at all, this seems like a clean way to achieve your goal.
Unfortunately the current C++ version doesn't support variadic macros.
However, you can do this:
#ifdef SOMETHING
#define foo
#else
#define foo(args) MyFunction args
#endif
// you call it with double parens:
foo((a, b, c));
If, in the case you don't want foo called, you define it as:
void foo() {}
any calls to foo() should be optimized way.
What about something along these lines:
#ifdef NDEBUG
#define DEBUG(STATEMENT) ((void)0)
#else
#define DEBUG(STATEMENT) (STATEMENT)
#endif
You would use it like this to log debugging messages:
DEBUG(puts("compile with -DNDEBUG and I'm gone"));
A non-generic version for formatted output with additional debugging information using C99 variadic macros and the __func__ identifier could look like this:
#ifdef NDEBUG
#define Dprintf(FORMAT, ...) ((void)0)
#define Dputs(MSG) ((void)0)
#else
#define Dprintf(FORMAT, ...) \
fprintf(stderr, "%s() in %s, line %i: " FORMAT "\n", \
__func__, __FILE__, __LINE__, __VA_ARGS__)
#define Dputs(MSG) Dprintf("%s", MSG)
#endif
Here's how you'd use these macros:
Dprintf("count = %i", count);
Dputs("checkpoint passed");
Likely, you don't want to do the simple "code removal" as suggested,
because your callers will be expecting the side effects of the
arguments to happen. Here are some troublesome caller snippets that
should get you thinking:
// pre/post increment inside method call:
MyFunction(i++);
// Function call (with side effects) used as method argument:
MyFunction( StoreNewUsernameIntoDatabase(username) );
If you were to disable MyFunction by simply saying:
#define MyFunction(x)
then the side effects that the callers were expecting would go away,
and their code would break, and be quite difficult to debug. I like
the "sizeof" suggestion above, and I also like the suggestion to just
disable the body of MyFunction() via #ifdef's, although that means
that all callers get the same version of MyFunction(). From your
problem statement, I presume that's not actually what you want.
If you really need to disable MyFunction() via preprocessor defines on
a per-source-file basis, then I'd do it like this:
#ifdef SOMETHING
#define MyFunction(x) NoOp_MyFunction(x)
int NoOp_MyFunction(x) { }
#endif
You could even include the implementation of NoOp_MyFunction() inside
the source & headers for MyFunction(). You also have the flexibility
to add extra logging or debugging information in NoOp_MyFunction() as
well.
No, the C and C++ Standards say you cannot #define something to be a comment, so
#define foo //
won't work.
#ifdef SOMETHING
#define foo sizeof
#else
#define foo MyFunction
#endif
I'm assuming that foo is a printf style function? Anyways, this won't work with a zero parameter function, but if that were the case, you would already know what to do. If you really want to be anal you can use (void)sizeof but that's probably unnecessary.
I'm a little reluctant to post this answer because it's use of macro hackery can become the source of problems. However - if the calls to the function you want to have disappear are always used alone in a statement (ie., they are never part of a larger expression), then something like the following could work (and it handles varargs):
#ifdef SOMETHING
#define foo (1) ? ((void) 0) : (void)
#else
#define foo MyFunction
#endif
So if you have the line of code:
foo( "this is a %s - a++ is %d\n", "test", a++);
it will end up after the preprocessing step as either:
MyFunction( "this is a %s - a++ is %d\n", "test", a++);
or
(1) ? ((void) 0) : (void)( "this is a %s - a++ is %d\n", "test", a++);
which turns the pseudo-function's parameter list into a bunch of expressions separated by the comma operator that will never be evaluated, since the conditional always returns the ((void) 0) result.
A variant of this is something close to what ChriSW and Jonathan Leffler suggested:
#ifdef SOMETHING
#define foo if (0) MyFunction
#else
#define foo if (1) MyFunction
#endif
This is slightly different in that it does not require the compiler to support variadic macros (__VA_ARGS__).
I think this can be useful for eliminating debug trace function calls which are generally never combined into a larger expression, but beyond that I think it's a dangerous technique.
Note the potential for problems - especially if the parameters in the call produce side-effects (this is a general problem with macros - not just this hack). In the example, the a++ will be evaluated only if SOMETHING is defined in the build, otherwise it's not. So if code after the call depends on the value of a to be incremented, one of the builds has a bug.
If I remember correctly, you should be able to #define your macro to "nothing" and that will cause the compiler to ignore that call
#define foo()
foo(); // this will be ignored
What about surrounding each call to myFunction with
#ifdef SOMETHING
myFunction(...);
#endif
?