QT Creator Can't read from stdin in debugger - c++

I just updated QT Creator to 4.13.0 and now I can't read from stdin while I'm in the debugger.
A few details...
I am running on macOS.
I am writing C++, but using C stdio library. (for historical reasons)
I am using clang 15.5.0 in c++11 mode.
I am using the 'Run from Terminal' debugger option.
Problem: Type as I might, when my code goes into fgets it never returns.
Simplified Example:
#include <stdio.h>
int main()
{
char buf[1024];
if (fgets(buf,1024, stdin)) // In debugger, this call never returns!
{
fprintf(stderr, "%s", buf);
}
return 0;
}
Note: When I run this outside of the debugger - no problems.
Has anyone run across this and fixed it? Any ideas on how to fix it?

Could be an issue with the terminal start application openTerminal.py inside QtCreator.
I had a similar issue, where the output of my console application appeared correctly in a terminal session when starting in debug mode without the debugger, but when starting using the debugger all system output and system error was written to Application Output widget making it impossible to read any values from std::in.
Solution was:
Manage Kits: Environment System Replace the long path ".../openTerminal.py"
by "/Applications/Utilities/Terminal.app"

Related

Why does nCurses (C++) block System() function?

I don't know if it is a thing just for me but I need to open a file with notepad on windows in a C++ program. I use at the same time ncurses for the pseudo-GUI but I noticed that all the "system()" calls don't work at all
void test() {
cout<<"\n\nTEST FUNCTION\n";
system("file.xml");
}
does open the file but if I use
void test() {
cout<<"\n\nTEST FUNCTION\n";
initscr();
system("file.xml");
endwin();
}
It doesn't work. With Windows' GetLastError() it gives me error 87 (invalid parameter) but for opening a file the command used is just the file name itself
Can someone please help me?
ncurses on Windows could refer to different environments:
Cygwin (where opening an xml file probably does not work, since system uses sh rather than cmd)
MinGW (which would use cmd)
WSL (undocumented like most of WSL, but probably like Cygwin)
With MinGW, ncurses switches the console mode by creating a screen buffer (analogous to xterm's alternate screen), which allows it to address cells on the visible screen. Doing that entails changing the inputs for that window. cmd would in that case change its behavior regarding file associations.

No console application on Linux

On Windows I normally create a Windows Desktop Application, this is because console applications display a brief black box on the screen.
I am using CodeBlocks on Linux Mint, how could I do the equivalent of the above but on Linux?
I do not want to hide the terminal window after it has been displayed.
Linux does not have the same "subsystem" concept as windows: there is no difference or separation between console and desktop applications. When you start an application on Linux, it will not open a console window, unless the programmer explicitly programmed it to open one.
If the application writes anything to stdout or stderr, what happens with that depends on how exactly the application got started. By default, the application inherits the stdout and stderr of its parent process. If the application is being started from a terminal, the output will be visible on the terminal. If the application was started by the desktop environment from a menu entry, the output may go to a log file or it may be lost.
If you see a terminal window open when you run your program from the IDE, that's something that the IDE is doing for you, it's not your application. If it bothers your, I would think that the IDE has a way to disable this behavior in settings.
Look into QT. It is a GUI framework that works on Linux.
You can write your code without creating a main window (or maybe you have to have a main window but it can be always hidden... it's been a while since I've used it).
Be aware though, that you may run into usability issues with this type of design... the user has no way of knowing if your app was launched or if it succeeded, when it's completed, etc.
The simple way is to use (e.g.) xterm [or gnome-terminal] to get a terminal window.
Then, invoke your program from the shell [manually]:
/path_to_my_program
You may be able to configure codeblocks to do this for you.
Or, you could add some code that holds the default window open:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
int main()
{
pid_t pid = fork();
if (pid != 0) {
waitpid(pid,NULL,0);
while (1) sleep(1);
}
long double n;
n=5;
printf("n= %Lf\n",n);
return 0;
}
UPDATE:
The invocation command can be controlled from: Settings -> Environment -> General Settings
The default is to invoke in an xterm sub-window [popup]. You may be able to change the settings to (re)use an existing [terminal] window.
Note that [a codeblocks program] cb_console_runner is used. You may be able to replace this with something more to your liking.
I do not want a GUI nor a terminal popup...
You'll need some sort of terminal to run the command in. This could be a script that diverts stdin/stdout/stderr as appropriate [and suppresses the invocation of a sub-window], so you'll have to experiment a bit.
As I mentioned above, you can just open a terminal window outside of codeblocks and then run the command manually inside it. Technically, this is not a popup. But, you lose the [automatic] debugger invocation.

Debugging C++ in Netbeans

I am very new to work c++ Programs with Netbeans IDE in Ubuntu. I wrote a simple Hello World Program and tried to debug it using step Into. When I Click Step Into Option From Debug Menu I got new window opened in the name of " Diassembly(main) " . The Debug process didn't reach my source code line at any way. I repeatedly click Step Into Function At last the process got end Without Tracing my source code line. But In the Debug output window I got the Correct Result.
#include <iostream>
using namespace std;
int main()
{
cout<<"Hello";
cout<<"World";
}
Why This process Control goes to the Diassembly (main) window ? How to rectify this problem ?
You must compile with -g option, otherwise the debugger won't be able to stop on a breakpoint. As for disassembling window - I can't reproduce that (I'm on Netbeans 7.4 in Ubuntu 13). You should just close the window if you don't need it.
First, you have to toggle a break point in your code by clicking on the line number of the line you want to stop in source window, if you did not. Then hit Debug.
Don't step into function that you not build from source, just step over it.
Pehaps that there is an answer here (i can't comment sorry)
"No source available for main()" error when debugging simple C++ in Eclipse with gdb

C++ on windows closes a program immediately after launching

I installed minGW and the eclipse CDT, and the console keeps doing something weird. The code of the program is
using namespace std;
#include <iostream>
int main() {
cout << "Hello, windows (8, c++)" << endl;
//system("PAUSE");
return 0;
}
You all know it, its the Hello World program. Now when I run this the Eclipse console displays some stuff about building, and then goes blank. And when I navigate to the HelloWorldProgram.exe in the explorer and run it, a windows flashes up and displays "hello world", but then immediately closes. When I do this on Mac OSX there's no problem, and the windows stays up until I decide to close it. Now I know there's a command
system("PAUSE") //I dont know what I need to import to use this. Could you tell me that too?
Which will give me more or less the same effect, but I'd like to know why Windows does it differently from OSX, and what I can do to fix it (bc this annoys the crap out of me).
Looking forward to your replies!
This happens on Windows because this is just the behavior of the Windows console. You'll have to open up the console manually and then running your program through the console you've opened if you don't want the window to close automatically once the program has executed.
You may want to take a look at these:
What is the Best Practice for Combating the Console Closing Issue?
https://superuser.com/questions/186562/how-can-i-keep-the-terminal-open
Don't use system("pause"), it's wrong for a multitude of reasons (read more about it here).
Put cin.get() before return and the window will stay open until you press enter.
If you want to just run your console program, you should open a console, and run it.
Apparently, the OSX version of Eclipse is configured to open a console, and run the program, and not close it. Maybe you can configure the Win version so, too.
You shouldn't meddle with your program to behave differently on another platform, instead wrap it into something that 'adapts' the behaviour.
Probably, you can tell eclipse to use "cmd /c 'yourprogram.exe && pause'", to open a command window and have it execute your program and then pause.
Just add getch(); before return, and add #include <conio.h>.

Somehow display C++ application using double-click on Ubuntu?

I'm totally new to Ubuntu and C++. Anyway, I have PHP experience.
I just created very simple application...
#include <iostream>
int main() {
std::cout << "Hello, world!";
return false;
}
Then compiled it....
g++ hello-world.cpp -o hello-world
But I can't open it with double-click on it, like I did on Windows 7. Only way to get that text printed is to do command...
./hello-world
Is it possible to open compiled file using simple double-click and then get that text somehow printed?
The program you wrote is a console application. In most Linux GUIs, by default if you open a console program from the GUI, the console output will not be displayed. You can either configure the GUI to open a terminal, or you can manually open a terminal and run it yourself.
When doing development, I highly recommend manually running the program - with using the GUI's automatic terminal window opening mode, the terminal will close as soon as the program terminates; so if the program crashes, the message will be lost. Manually opening a terminal ensures it sticks around after termination, so you can read the program's last messages before terminating.