I want to define some member variable and some code just in Debug Mode,
When change to Release mode, they will not appear.
I know I can use #ifdef xxx to do this task.
My question is : is there any handy macro provided by MFC to do this.
#ifdef _DEBUG
Visual Studio defines the _DEBUG macro when building Debug flavor of your application.
Related
I have an SDK for some Hardware I need to implement
I use The MFC Class they provide and created a windows console application.
They heavily rely on the Trace Macro so i cant simply comment them out.
I already manually installed the ATL + MFC Component for visual C++
I installed the 2015 Compiler (as i read they changed something ...)
I disabled precompiled headers
I tried "switching" some options in Project properties, but that did not yield anything different :(
TRACE(_T("PS10DLL not found\n"));
I would expect to compile smoothly but the Error (they used it alot) is:
error C3861: "TRACE": Identifier was not found.
According to your issue, you are creating a windows console application? TRACE is used in the MFC support program and cannot be used in the WIN32 Application program.
TRACE is a definition in MFC. In Win32 code, you can directly use OutputDebugString to achieve the same effect.
I suggest you could refer to the link: How can I use the TRACE macro in non-MFC projects?
I am using Visual Studio Community 2015 and I wrote some simple Win32 demo application which should download file from internet and execute two HTTP GET requests.
I am using functions like InternetOpenA, InternetConnectA, HttpOpenRequestA, URLDownloadToFile, etc.
Only thing that I have changed in settings is Platform Toolset to Visual Studio 2013 (v120) and my targetver.h file looks like this:
#pragma once
// Including SDKDDKVer.h defines the highest available Windows platform.
// If you wish to build your application for a previous Windows platform, include WinSDKVer.h and
// set the _WIN32_WINNT macro to the platform you wish to support before including SDKDDKVer.h.
#include <WinSDKVer.h>
#define WINVER 0x0600
#define _WIN32_WINNT 0x0600
#include <SDKDDKVer.h>
However, it runs on my Windows 10 computer, but it does not run on windows 7. It says: Missing MSVCR120.dll file. I can install appropriate C++ Redistributables but that is not solution that I need.
Is there any other options I need to include when I compile so I can avoid this error?
To avoid your application needing a separate runtime DLL, in the project settings, look under:
C/C++ > Code Generation > Runtime Library
and choose multi-threaded, rather than multi-threaded DLL.
You do not need to change the platform toolset.
In my project, that I compile with VS 2017 and want to run all the way down to Vista, I do the same as you, but without the first #include <WinSDKVer.h>. I just set the _WIN32_WINNT macro to 0x0600 and so far it's working fine.
I target the Windows 8.1 SDK, and use MFC, if that helps.
I've used dependency walker in the past to diagnose dll dependencies. Hopefully it's something silly like the 32-bit or 64-bit runtimes being missing.
As keith recommended in his answer, you can also try static linking the vc runtime (/MT[d] under C++/Code generation/Runtime Library) so that it doesn't need to load the runtime as a dll. Note that this is not the recommended option, since the VC runtime cannot be patched by Windows Update if it's burned into your executible.
I am working on a large inherited C++ project and am trying to build it for the first time in VS 2015.I have all the build files, but my build is failing in visual studios because the conditional
#ifdef WIN32
.....
#else error
I am trying to run on windows, but the program always is falling back to the else statements logic.
I have everything possible installed for C++ in visual studios. Any help is greatly appreciated.
VS 2015 defines _WIN32, not WIN32. See this list of predefined macros.
Most of the time _WIN64 macro was working well with Microsoft Visual Studio 2008 but TARGET_X64 not working well.Please explain these two macros with specific example.
The Visual C++ compiler predefines _WIN64 when compiling for a 64-bit target. To test for x64/amd64 specifically, test for _M_X64 instead. Consult the documentation for other macros that are predefined by the compiler.
TARGET_X64 is defined by neither the Windows SDK nor the Visual C++ libraries or toolchain. It must be defined somewhere else in your project or one of its dependencies.
I have a DLL written in C++. It wraps a static library. I am calling it from python with ctypes. So far, so good. I need to debug some calls in the DLL. I can hit breakpoints in the static library, but, not the DLL. I am doing this by using Attach to Process from the Debug menu. The code looks something like this:
extern "C"
{
__declspec(dllexport)
void foo()
{
int i = 0; // Can't hit breakpoint here
}
}
I am generating debug info. The pdb is sitting right next to the DLL. I am loading the DLLI think I am loading. What am I missing?
Edit
I recreated the project. Problem went away. Perhaps the difference is I went from a managed C project to an MFC DLL?
When you attach to a running process using MS Visual Studio, make sure you have the options set for both "Managed Code" and "Native Code". This will ensure your breakpoints in any type of code, native or managed, will be honored by the MS Visual Studio debugger. Otherwise, MS Visual Studio will use its "automatic" settings, which results in it only honoring break points that it sees in its "type" of project (for instance: a MFC project is native code (unmanged) and therefore won't normally debug managed code sections, while a .Net project is managed code and won't bother to stop for break points in "unmanaged" native code.)
You can set this option at attach time by selecting the "Select..." button, and swapping the radio button from "Automatic" to "Debug these code types". Under "Debug these code types", check the box beside "Managed" and "Native". You can select more options if you work with other types that MS Visual Studio recognizes (like T-SQL for SQL Server code, etc).