In VS Code I have a define identifier that is not found. The variable is eventually passed to the compiler as a flag -DENABLE_LOGS_PREVIEW and found in ./cmake-build-debug/build.ninja. I build with CMake and Ninja directly from the command line.
#ifdef ENABLE_LOGS_PREVIEW
std::cout << "Hello world" << std::endl;
#endif
std::cout << "Goodbye world" << std::endl;
Correctly prints, though VS Code greys out std::cout << "Hello world" << std::endl;
Hello world
Goodbye world
I'm struggling to get the correct c_cpp_properties.json to work with my workflow. How do I get the above define to be recognized?
The answer here was to have CMake to generate a compile_commands.json and add it to the VS Code c_cpp_properties.json like so:
"compileCommands": "${workspaceFolder}/cmake-build-debug/compile_commands.json"
Related
I have the following extract of a program
int main(){
cout << "1) ✊\n";
cout << "2) ✋\n";
cout << "3) ✌️\n";
}
But at the time I run it I get strange texts like the following
====================
rock paper scissors!
====================
1) 
2) 
3) ԣÅ
This seems not to be related to my terminal but instead to a compilation result because if I run echo ✊ it shows as expected.
See example below
I'm currently using the following compilation commands and compiler version
g++ *.cpp -o rock_paper_scissors.exe
g++.exe (Rev9, Built by MSYS2 project) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
Finally, note that it was working before as expected, but at some point, it stopped working, I noticed after I used system("pause") which I'm guessing may have changed something on the compilation configurations as this is a Windows-only command, I delete such piece of code and still having the issue.
You can see the rest of the code here: https://github.com/guillene/RockPaperScissors
If your terminal font supports emojis and you don't want to write much code (like switching from cout to wcout), you can use the windows api function below.
#include <windows.h>
#include <iostream>
int main(){
SetConsoleOutputCP(CP_UTF8);
std::cout << "1) ✊\n";
std::cout << "2) ✋\n";
std::cout << "3) ✌️\n";
return 0;
}
see: https://learn.microsoft.com/en-us/windows/console/setconsoleoutputcp
When i run the .exe release file it shows some kind of awkward error in my IDE.
And when I try to run from outside the IDE as an appilcation it terminates as soon as it opens without showing any output.
I am using Eclipse and MinGw
This is the error message my ide shows.
And i guess there is nothing wrong with my code.
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World" << endl;
cout << "hello Again" << endl;
return 0;
}
This is not an error, you are viewing the contents of the exe file which is not human-readable, but binary data. The output from your application is in the 'Console' window at the bottom of the screen.
I wonder if there is way to define your own debug flags in VS for C++.
For example the code below is only executed in debug mode. I want to have another piece of code that maybe prints "Hello World"that only prints at debug level 2. How do you define a level 2 debug flag in VS? is it via properties?
#ifdef _DEBUG
std::cout << "Hello" << std::endl;
#endif
You use your own macros.
#ifdef DEBUG_LEVEL_2
std::cout << "Hello" << std::endl;
#endif
or
#if defined (DEBUG_LEVEL) && DEBUG_LEVEL >= 2
std::cout << "Hello" << std::endl;
#endif
and then you either
#define DEBUG_LEVEL_2
or
#define DEBUG_LEVEL 2
manually, or define it in the "Preprocessor" tab in the project settings, or pass it to the compiler using the /Dflag if you're compiling on the command line.
This question already has answers here:
Debugging with command-line parameters in Visual Studio
(13 answers)
Closed 8 years ago.
EDIT: The following code is run through Microsoft Visual Studio 2013
I have the following script:
#include "stdafx.h"
#include <iostream>
#include <boost/filesystem.hpp>
using namespace boost::filesystem;
int main(int argc, char* argv[])
{
if (argc < 2)
{
std::cout << "Usage: tut1 path\n";
return 1;
}
std::cout << argv[1] << std::endl;
std::cout << "File Size is: " << file_size(argv[1]) << std::endl;
return 0;
}
But when I run it with ctrl+f5, I get this message (which is predicted by an if-condition in the code itself:
Usage: tut1 path
It seems the number of arguments is lower than 2.
Why this happens? How should I avoid this problem?
EDIT:
When I remove the following line:
std::cout << "File Size is: " << file_size(argv[1]) << std::endl;
I get the "Filing.cpp" printed on my console which means
argv[0] value is Filing.cpp that further shows argv is getting the commands from command arguments of Debuger of project correctly.
But when I add the line again, I see the message "Filing.exe not found or not built by the last incremental link;"
The easiest solution would be to open a prompt in the directory of your compiled output and call your program and pass in the string of the filename.
e.g. FileSize.exe foo.jpg
This saves messing about with project config options.
The if triggers because the application filename is considered the first argument, so argc == 1 which is less than 2, triggering the instructions.
If you are running it like this the number of arguments is only one (the executables name). If you are using Visual Studio (which you propably are) and you want to add arguments, go to properties->Debugging and add the arguments you want on "Command Arguments"
If you want to run a program with arguments please run the exe file by cmd.
Exe file would be in debug directory.
In cmd go to path of exe file then run command like ABC.exe then arguments.
Some systems I use don't have a logging library I'm using, which is OK for well-tested code on production runs --- the logging library is mostly for debugging and testing. On my main development machine, and on a couple of servers I frequently run experiments on, the logging library exists. But occasionally I need to farm out experiments to another server with many more nodes and cores but that does not have the logging library.
The library (Google glog) provides, for example, the following macro functions:
LOG(INFO) << "Insert my message here.";
LOG(FATAL) << "Insert another message here.";
So, what I've done is defined the following:
#ifdef NOLOGGING
#define MYLOG(i,m) std::cerr << #i << ": " << m << "\n";
#else
#define MYLOG(i,m) LOG(i) << m ;
#endif
Using those definitions, I can now write statements like this:
MYLOG(INFO, "My info message");
MYLOG(FATAL,"My fatal message");
If compiled with flag -DNOLOGGING, the last two statements will be expanded to:
std::cerr << "INFO" << ": " << "My info message" << "\n";
std::cerr << "FATAL" << ": " << "My fatal message" << "\n";
Wherease, if the -DNOLOGGING flag is not used in compilation, they will be expanded to:
LOG(INFO) << "My info message";
LOG(FATAL) << "My fatal message";
The solution I've described above is satisfactory, but not ideal.
Ideally, when I don't have acces to the logging library, statements like MYLOG(FATAL,"foo") would expand to statements that print to std::cerr; however, statments like MYLOG(INFO,"bar") would expand to nothing. In other words, when I can't use the logging library, I want statements like MYLOG(INFO,"bar") to be ignored. The idea is that I don't care too much about log messages of the INFO severity when I'm using the servers without the logging library, but I do still want to see messages of the FATAL severity.
How, if possible, can I do this using only preprocessor directives?
I don't think you can do it solely with preprocessing directives, since the preprocessor doesn't really give you the necessary mechanisms to guide macro expansion based on the arguments to the macro.
That said, you can perpetrate some mildly ugly hacks that will work. Consider the following code:
#include <iostream>
#define MYLOG_ERR 1
#define MYLOG_INFO 0
#define P(a,b) a##b
#define MYLOG(x,y) do { if (P(MYLOG_,x)) { std::cerr << y << std::endl; } } while (0)
int main(void)
{
MYLOG(ERR, "err");
MYLOG(INFO, "info");
}
This approach relies on the compiler's optimizer to recognize some common idioms, such as do { ... } while (0) and if (0) / if (1) to optimize away compile-time known conditions. But, I think it'll give you what you want.