I am using Visual Studio 2019 (updated to date, running on Windows) to rewrite old program code in cross-platform C++ language (Windows & Linux).
In the code, I am using the pre-compilation directives #if, #else, #endif to toggle platform-specific blocks of code.
Example:
76 #ifdef WINDOWS_OS
77 errno_t success = fopen_s(&arq, logConfigFileName.str().c_str(), "rt");
78 #else
79 arq = fopen(logConfigFileName.str().c_str(), "rt");
80 #endif
In the Visual Studio editor, everything looks correct (see screenshot).
Project selected: Windows, Debug, x86.
Lines 1 and 2 appear normally (active and without error indication) and lines 3 to 5 appear in gray indicating they are disabled, that is, it appears as it should be.
However, when compiling I get the error:
Error C4996 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
error on line 79, line that should be ignored by the compiler.
How can I fix this, so that my code can be compiled for both platforms without problems ?
You don't need to create / define macros to identify the OS.
Compiler do it already. See C++ compiling on Windows and Linux: ifdef switch for the list.
Problem solved.
The problem was in the definition of the WINDOWS_OS flag, I had defined it in the code with the #define WINDOWS_OS statement.
The IDE recognized the instruction, but the preprocessor didn't.
The solution was to include the WINDOWS_OS flag in the list of definitions in: Project Properties -> Settings Properties -> C++ > Preprocessor - Preprocessor Settings.
To me this does not make sense, my everyday IDE is Rad Studio and in it if you set a compiler directive in the code it is valid for everything.
Thank you all.
Related
TL;DR: Debuigging into MFC (CString) header code does not work on both my machines and as far as I can tell this is due to the peculiar way these headers are compiled.
Stepping through MFC header code when entered via disassembly works, but setting brealpoints does not work.
I'm looking for a workaround or at least acknowledgement of my analysis.
System:
Visual Studio 2019 Professional 16.9.6
Windows 10 / 1809 Enterprise LTSC
Setup: (I do apologize for this being rather long.)
Create a Visual Studio 2019 Example MFC Application Project (SDI App)
Make sure Enable Just My Codeis off under Options -> Debugging -> General.
Set the build configuration to Debug/x64 (does not make a difference, but let's all stay on the same page)
Navigate to MFCApplication1.cpp -> CMFCApplication1App::InitInstance()
Insert a CString init like this:
...
InitCommonControlsEx(&InitCtrls);
CWinAppEx::InitInstance(); // please put breakpoint 1 here
// Add this line and set breakpoints
CString this_is_text(L"Debugging into CString Header does not work!"); // breakpoint 2 here
Now, you can start the program under the debugger, and you should stop at the first breakpoint:
Now, make sure all symbols are loaded, easiest done via the Call Stack:
Just select all lines in the call stack window and hit Load Symbols in the context menu. Afterwards the call stack should look roughly like this:
> MFCApplication1.exe!CMFCApplication1App::InitInstance() Line 75 C++
mfc140ud.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 37 C++
MFCApplication1.exe!wWinMain(HINSTANCE__ * hInstance=0x00007ff7b5070000, ...) Line 26 C++
MFCApplication1.exe!invoke_main() Line 123 C++
MFCApplication1.exe!__scrt_common_main_seh() Line 288 C++
MFCApplication1.exe!__scrt_common_main() Line 331 C++
MFCApplication1.exe!wWinMainCRTStartup(void * __formal=0x000000c2b7084000) Line 17 C++
kernel32.dll!BaseThreadInitThunk() Unknown
ntdll.dll!RtlUserThreadStart() Unknown
Now, you can try stepping-into (possibly F11) the CWinAppEx::InitInstance() function, which should work without a problem, landing you in mfc140ud.dll!CWinApp::InitInstance() Line 394 - this is OK.
Step out again, and then then try to step-into the CString ctor:
This DOES NOT work on my machine(s)!
What I can do however, is (from the point above) switch to disassembly view, step into the calls there and get into the header code this way:
I can then successfully step through (but never into) the MFC header code. Trying to set a breakpoint will result in the error:
The breakpoint will not currently be hit. No executable code of the debugger's code type is associated with this line.
Possible causes include ...
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
And this is where I'm at.
Analysis:
What we can see from the MFC code is that we can step into "regular" cpp code, but as soon as we try to step into (or set breakpoint) code that is inside this CStringt.h it breaks.
Peculiar here: This is template header code, and still the executed code (as shown by the disassembly) is not in the user module but in the mfc###.dll! I think they do some clever tricks with the preprocessor (see defined(_MFC_DLL_BLD) and somesuch) which enables this multi use of the header file, and maybe, possibly this is also what breaks the debugger.
Question:
Is this a known problem, does this happen with all VS2019 installs, is there something peculiar to my setup?
Maybe fixed in a newer VS version?
Iff this is actually broken, what would be a useable workaround, other than constantly switching to disassembly view when into the MFC headers.
The most interesting answer here would actually be as to WHY this breaks - where does the debugger get confused? Is this a general problem with re-define-ing code when debugging library code?
The source shipped with MSVC does not match.
I think this happen, as DLLs got updated with Windows Update or a new vcredist, but Visual Studio includes are not updated. If you build with /MT or /MTd and link MFC statically, the problem does not persist.
Probably this can be reported to http://developercommunity.visualstudio.com if you care.
Workaround 1
Do steps described by #selbie:
Set a breakpoint on the line of code I want to step into.
When
the breakpoint is reached, right click in the editor window and select
"Go To Disassemly".
In disassembly mode, step over until you get to
a call statement. [...] You
can flip out of disassembly mode by right-clicking again and selecting
"go to source code".
(skipped the part not relevant to this issue)
Then pick up the location of the header manually, the debugger will tell that it does not match. The difference seem to be insignificant though, so the header is usable.
Workaround 2
Link MFC statically, compile with /MT or /MTd
Workaround 3
ATL has a similar CString that does not suffer from the issue:
#include <atlbase.h>
#include <atlstr.h>
int main() {
ATL::CString this_is_text("Debugging into CString header works");
}
Analysis went sideways at some point, but we finally found one part of the problem here:
The Require source files to exactly match the original version option:
was the problem, but in a very peculiar way:
When you do NOT require source files to match (that is, disable this default option), then the erroneous behavior of the OP occurs: The debugger can no longer match the symbols to the cstringt.h file.
Unfortunately, I had this disabled on both machines. Pulling in a third machine showed that we could set breakpoints (though F11 still does not work) and by comparing the xml export of the VS settings we found that this was different.
So, long story short: For us, to be able to set breakpoints in the (unmodified!) MFC header, requires us to enable the Require source files to exactly match .. option.
If the option is disabled, which would imply a more lenient behavior by the debugger, it no longer works.
And, yes, we double checked it's always the same source file at C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Tools\MSVC\14.28.29910\atlmfc\include\cstringt.h
The mystery with step-into/F11 persists, but I guess this would better be taken to a separate question.
Uncheck the Enable Just My Code option in Tools->Options->Debugging
I know that works for c++ std:: library code debugging. The other technique I do, when I forget to uncheck this option, is similar to what you describe above.
Set a breakpoint on the line of code I want to step into.
When the breakpoint is reached, right click in the editor window and select "Go To Disassemly".
In disassembly mode, step over until you get to a call statement. That's typically the std library. Eventually, you'll navigate into a mix of assembly and system code sources. You can flip out of disassembly mode by right-clicking again and selecting "go to source code".
I was about to use PuTTY Development source code for Windows to create my own client application (found here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) but as I tried to compile the PSCP project (SCP Client), I got the following error :
C:\work\2015\Putty\windows\version.rc2 (18): error RC2104 : undefined
keyword or key name: BINARY_VERSION
I've been going through the various posts involving this error but didn't find anything working :
error RC2104: undefined keyword or key name: DS_SETFONT :
On this post I noticed that the version of MSVC was brought up so I figured maybe something has to be done to get PuTTY to work on VC 6.0 ?
Also I tried to add #include <windows.h> in both version.rc2 (version.rc2 is used for inclusion in all .rc files) and pscp.rc, none worked.
I'll be quick to answer if you need any information (project properties, source code...)
USING Visual Studio 6.0 with SP6 on Windows 8.1
Probably, wrong version.h is seen.
Correctly, the file version.h in the project folder should be seen.
Please try to modify version.rc2:
#include "version.h"
to
#include "..\\..\\..\\version.h"
At least, resource compiler will end successfully.
If you search through the PuTTY source files, you'll notice that BINARY_VERSION is defined in version.h and used in windows/version.rc2, which #includes version.h.
Since your version.rc2 isn't seeing version.h, try to figure out why: Is version.h still present and does it still contain BINARY_VERSION? Are your include paths correct? Is there another version.h somewhere else in your include path that's getting picked up by mistake?
Which source code are you using ?
I tested latest(0.64) "Release source code for Windows".
direct link is
http://the.earth.li/~sgtatham/putty/latest/putty-src.zip
I had tried to compile using VC++ 6.0 Professional with SP6, on my PC,
running Windows XP SP3.
After extracting putty-src.zip to somewhere with keeping folder
structures, did you correctly opened 'putty.dsw' in "putty-src\windows\MSVC" folder?
You should be find in 7 projects in 'FileView' tab of the workspace
in Visual Studio 6.0.
You can switch active project to 'pscp' with context menu via
right button click on 'pscp' project.
With modified version.rc2, resource compiler finished successful.
But two (sshshare.c, winsftp.c) C source files failed compiling
with 20 errors. in 'pscp' project.
Errors while compiling 'winsftp.c' is caused 'TIME_POSIX_TO_WIN'
and 'TIME_WIN_TO_POSIX' macros.
'ull(unsigned long long)' is a 64-bit integer-suffix, newly defined in C99. Since C99 standard is not support on VC6, then caused errors.
I had temporally modified
11644473600ull ------> ((ULONGLONG)11644473600)
10000000ull ---------> ((ULONGLONG)10000000)
and confirmed errors are cleared. (Sorry, no validation the code is correctly generated)
3 errors while compiling 'sshshare.c' is also caused another macro.
I cannot understand why you got 116 errors.
I switched from Visual Studio to Code::Blocks yesterday, and just had some strange compiler error messages.
I included windows.h and i can use all the API calls just fine, such as creating window classes and creating windows / buttons and stuff. But when I tried to send some keypresses with SendInput(), I got error messages on these two declarations:
INPUT ip;
KEYBDINPUT kbi;
Compiler errors:
C:\code_blocks\test-app\main.cpp|21|error: 'INPUT' was not declared in this scope|
C:\code_blocks\test-app\main.cpp|22|error: 'KEYBDINPUT' was not declared in this scope|
I can even right click the KEYBDINPUT and INPUT structors and click on "Find declaration", it finds it inside the "winuser.h" (which is inside ), but it's still giving me these error messages that they are not declared.
This code works fine in VS with just windows.h included. I'm using the GNU GCC compiler.
I think you need the pre-processor directives (Visual Studio may already add them):
What do you have _WIN32_WINNT defined as?
Perhaps you could add:
#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0400
#endif
or you can add it to your pre-processor directives as part of your compile sequence. Any good compiler will have it.
If it still doesn't work, remove the include guards and define it directly. Maybe it is getting defined elsewhere.
Some compilers will have this in the pre-processor directive settings: WIN32,_DEBUG,_CONSOLE,_MBCS,_WIN32_WINNT=0x0400
To elaborate on Changeling's answer, if you look at the documentation for say KEYBDINPUT, you will see that near the bottom it has a table of minimal supported OS versions. VC++ sets _WIN32_WINNT to a later version than MinGW/GCC (which I am guessing is the compiler you are using with Code::Blocks), which is probably why you have encountered this problem.
The purpose of this macro is to prevent you inadvertently using API's that are not compatible with your minimum intended target OS.
There are a number of version related macros used by Windows API headers. The details can be found here
I would like to see if you could orient me.
It happens that I compiled and referenced the boost libraries in order to use them with Visual Studio 2010. When building my test project I get these two IntelliSense errors
1 IntelliSense: #error directive: "Macro BOOST_LIB_NAME not set (internal error)" c:\boost_1_43_0\boost\config\auto_link.hpp
2 IntelliSense: #error directive: "some required macros where not defined (internal logic error)." c:\boost_1_43_0\boost\config\auto_link.hpp
Checking the auto_link.hpp header file the first error is in this line
#ifndef BOOST_LIB_NAME
# error "Macro BOOST_LIB_NAME not set (internal error)"
#endif
Tracing the definition of BOOST_LIB_NAME, it seems that is defined in config.hpp by boost_regex, which code I am including below
#if !defined(BOOST_REGEX_NO_LIB) && !defined(BOOST_REGEX_SOURCE) && !defined(BOOST_ALL_NO_LIB) && defined(__cplusplus)
# define BOOST_LIB_NAME boost_regex
# if defined(BOOST_REGEX_DYN_LINK) || defined(BOOST_ALL_DYN_LINK)
# define BOOST_DYN_LINK
... more code
and strangely when I point to BOOST_LIB_NAME it defines BOOST_LIB_NAME and the IntelliSense errors disappear.
My program builds and executes fine using the Boost:Regex library -- with or without the Intellisense errors; however, I do not understand why these IntelliSense errors appear in the first place, and second why pointing the macro in the config.hpp defines BOOST_LIB_NAME.
Any guidance will be greatly appreciated.
Thanks,
Jaime
The Visual Studio IntelliSense error checking for C++ is not perfect and often reports errors that aren't really errors (those are links to three false positives that I've found and reported; they aren't related to your problem, though).
I can inhibit many warnings in Visual Studio 2005 SP1 in the C/C++ Advanced property page, which causes the IDE to use the /wd switch on the command line which invokes the compiler. However, when I try to inhibit warning 4200 (nonstandard extension used : zero-sized array in struct/union), it still appears when I compile. (Of course it's justified; I'm just not in a position to fix the code, nor would it be worth bothering, because it's generated, and the warning is entirely benign under the circumstances.) Does anybody happen to know if this is a bug in the compiler? Or might there be something I can do about it?
To completely disable the warning in the file you can add the following to the top of the file
#pragma warning(disable:2400)
If you want some more flexibility other than a blanket disable for the file, the following page lists several other more fine grained options.
http://msdn.microsoft.com/en-us/library/2c8f766e(VS.80).aspx
It's unclear based on your information as to whether or not it's a bug in the compiler or a configuration issue. I would lean towards a configuration issue, specifically conflicting compiler options that is making it difficult to suppress the warning.
EDIT
OP mentioned they can't control the generated code so they can't directly include the pragma. If that's the case then try this trick. Say the file name is Generated.cpp. No longer include Generated.cpp as one of the files to compile. Instead create a new file called Example.cpp with the following contents
#pragma warning(disable:2400)
#include "Generated.cpp"
Now you'll get the text of Generated.cpp with the disabled warning by only compiling Example.cpp.
You mean like with pragma?
#pragma warning( disable : 2400 )