Hello I'm interested in learning a way to clear the screen. I'm using C++ but it seem that some possible code to use are only known to work with Windows compilers. I'm using Ubuntu with a "g++ compiler".
code i have research in order to use and have tried...
---This don't work with g++ compiler
system("cls"); error: sh: 1: cls: not found
system("clrscr"); sh: 1: clrscr: not found
I stumble upon this code that it works, i know it prints lot's of lines ...
cout << string(50, '\n');
any cleaner methods that I could possibly use ?
The Unix command for clearing the terminal is clear.
Alternatively, send the terminal codes for doing same (this varies by terminal, but this sequence works for most):
cout << "\033[H\033[2J";
(I got the sequence by simply running clear | less on my system. Try it and see if you get the same result.)
Related
Good morning,
I have a problem with Eclipse IDE for C/C++ Developers.
I'm writting a smal tool for converting Strings. While testing on some point eclipse stopped to give console output.
e.g.:
cout<<"test";
doesn't get displayed.
But it's not every where... another example:
// File path as argument
int main(int argc, char* argv[]) {
if (argc != 2) {
cout
<< "ERROR: Wrong amount of arguments! Only one allowed...\n";
cout << "\n" << "Programm closed...\n\n";
exit(1);
}
CommandConverter a(argv[1]);
cout<<"test";
a.getCommandsFromCSV();
cout<<"test2";
return 0;
}
The error message is displayed correctly if the argument is missing.
But if the argument is there and the program continues the test outputs:
cout<<"test";
cout<<"test2";
are not displayed...
I am missing something obvious?
Thanks in advance!
You need to end output strings with newline, e.g.: `cout << "test\n"``. The reason is that the standard output is buffered and the buffer is flushed on newline. There probably exists a way to flush the cout buffer without outputting a newline, but I don't know it by heart. Probably includes access to the underlying streambuf (via the rdbuf method).
For me installing the 32 bit versions of Eclipse (Indigo 3.7) and the 32 bit Java JDK/JRE did not work. I use the much quicker solution from the Eclipse CDT/User/FAQ:
Quote from Eclipse CDT/User/FAQ - Eclipse console does not show output on Windows:
Eclipse console does not show output on Windows In Eclipse CDT on
Windows, standard output of the program being run or debugged is fully
buffered, because it is not connected to a Windwos console, but to a
pipe. See bug 173732 for more details. Either add fflush calls after
every printf or add the following lines in the start of the main
function:
setvbuf(stdout, NULL, _IONBF, 0);
setvbuf(stderr, NULL, _IONBF, 0);
I had a similar problem. In my case the program would give output if run from the command line but not from eclipse console. The solution was to use the 32 bit version of eclipse and not the 64 bit one.
I read that it was a bug. Might not be the same issue though.
I was also searching for exactly this information when I found this on the Microsoft website
http://support.microsoft.com/kb/94227
I think a simple method is to use std::flush when you want to force flushing the internal buffer that cout uses
*std::cout << ... << std::flush;*
This Happens when you debug your code and dont see the output till the last.
use
cout<<"what ever overloads"<< flush;
to see the output immediately on stdout(console)
Hi after some similar struggle I figured out, that the first element of the project's properties environment PATH variable must be "C:\MinGW\bin;" Otherwise a wrong version might be used, especially if you use different compiler.
try outputting a space at the beginning of each line
cout << " " << .....
When using CLion I have found the output sometimes cuts off.
For example when running the code:
main.cpp
#include <stdio.h>
int main() {
int i;
for (i = 0; i < 1000; i++) {
printf("%d\n", i);
}
fflush(stdout); // Shouldn't be needed as each line ends with "\n"
return 0;
}
Expected Output
The expected output is obviously the numbers 0-999 on each on a new line
Actual Output
After executing the code multiple times within CLion, the output often changes:
Sometimes it executes perfectly and shows all the numbers 0-999
Sometimes it cuts off at different points (e.g. 0-840)
Sometimes it doesn't output anything
The return code is always 0!
Screenshot
Running the code in a terminal (i.e. not in CLion itself)
However, the code outputs the numbers 0-999 perfectly when compiling and running the code using the terminal.
I have spent so much time on this thinking it was a problem with my code and a memory issue until I finally realised that this was just an issue with CLion.
OS: Ubuntu 14.04 LTS
Version: 2016.1
Build: #CL-145.258
Update
A suitable workaround is to run the code in debug mode (thanks to #olaf).
The consensus is that this is an IDE issue. Therefore, I have reported the bug.
A suitable workaround is to execute the code in debug mode (no breakpoint required).
I will update this question, as soon as this bug is fixed.
Update 1
WARNING: You should not change information in registry unless you have been asked specifically by JetBrains. Registry is not in the main menu for a reason! Use the following solution at your own risk!!!
JetBrains have contacted me and provided a suitable solution:
Go to the Find Action Dialog box (CTRL+SHIFT+A)
Search for "Registry..."
Untick run.processes.with.pty
Should then work fine!
Update 2
The bug has been added here:
https://youtrack.jetbrains.com/issue/CPP-6254
Feel free to upvote it!
Hi great C++ programmers,
I've been in this situation many times, but I still don't know how to solve it.
I am programming in C++ in Rstudio, and my program runs into a fatal error which needs me to restart. I want to locate where the mistake is in my code. What I often do is adding some detection lines like:
int main()
{
...code block;
std::cout<<"1.1\n";
...code block;
std::cout<<"1.2\n";
...code block;
std::cout<<"1.3\n";
...code block;
std::cout<<"1.4\n";
return 1;
}
Then I run the code.
The weird thing is, before it runs into "fatal error", sometimes I got "1.1" printed on the console, sometimes I got "1.1" and "1.2", sometimes I got "1.1", "1.2" and "1.3, and sometimes I got nothing.
I guess it has something to do with the operating system because it is the operating system that got the order to print something which would take some time, but meanwhile the CPU was executing forward the code and met the fatal error.
Or, maybe it's the way the codes were compiled that results in such thing?
Is there anyway to solve it? I just want the program to print out everything I asked before it runs into "fatal error".
Thanks!
The compiler optimization could reorder the code, making the printouts unreliable. You are coding C++ in the R environment, and the default g++ compiler optimization is set to -O2. Go to your R directory, search for a file named "Makeconf". Open it with a text editor, locate command "CXX11FLAGS = -O2 ...", erase "-O2", save the file and rebuild your program. Other commands like "CXXFLAGS = -O2 ..." may also need to be modified. Code will run in strictly sequential order by then.
You are using std::cout which is not what R uses, and you get caught up in two different buffering schemes.
Easy solution: use Rcpp::Rcout instead which redirects into R's output stream.
I am using MinGW (GCC) as a C++ compiler within my application. I have set it to redirect the output of its command line process to my app. Now, suppose I have the following simple C++ code:
int n = 5;
if (n == 6) cout << "YES";
else cout << "NO";
Is there a way to tell what line(s) of code were actually hit during execution of the application? Is there a command I can send to MinGW (GCC) process which, for the given example, would output 1 and 3, as those were the lines hit. And also, in case of a line inside a "for" loop, to tell how many times that statement was actually hit?
And, if not possible, what would be the best approach to having this information? Developing my own compiler or...? Thanks in advance
EDIT: Can someone provide a snippet of commands (in Windows) to be used in order to create a coverage-enabled GCC exe file?
"Is there a way to tell what line(s) of code were actually hit during execution of the application?"
Yes. It's an intrinsic GCC feature. You'll need to compile and link your code with the --coverage, -lgcov or -fprofile-arcs options set.
The gcov tool can be used to consolidate and interpret the actual informations gathered during program runs, that were instrumented with --coverage.
A very good tool to produce browsable consolidated and fairly visualized covearage information from gcov outputs is lcov.
Since you're using mingw you should be able to use gcov: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html
I have a "black box" question about an error I get when I run a discrete event simulation for about a minute. Everything works fine, and it completes successfully, but the system prints the following message once at some point during the simulation:
Error (202): Command token too long
I've never seen anything like it. I wonder what "command" it's referring to. Perhaps it's system("...") call that I make several times in the program in order to plot and visualize the data it generates.
I'm sorry I can't provide any code as I'm not sure where the error is coming from. Is there an efficient way to discover at which point the system generates this message? Or in any case, have you encountered such an error in your own C++ programming experience, and thus suggest where it could possibly be coming from?
I'm using Ubuntu 11.04 and compiling with GCC. The error appears at run-time during the simulation for simulations that are especially long (30+ seconds), and doesn't appear in shorter cases. I should emphasize that the "error" doesn't stop the execution of the code and doesn't actually cause any visible errors in the visual output of the simulation data.
write a program similar to the following:
int trials 10000;
string str("ls ");
while( trials--)
{
system( str.c_str() );
str += "a";
cout << "chars in cmd = " << trials << endl;
}
It will successively run commands like
ls, ls a, ls aa, ls aaa, while simultaneously printing to the console what trial # it's on.
and if you're right about where the error is coming from, eventually it will get the same error message about "token too long", and if so, tell you how many characters the cmd may be. Then code this limit into your real C++ program so that it doesn't emit the error.
If it doesn't reproduce the error, try making # trials bigger, say up to 100k. If it still doesn't happen, the error is probably coming from somewhere else.
It's coming from a lexer, telling you that one of the tokens (identifiers/preproc tokens/etc.) in your program is rather lengthy. Look through your code to see if there are any ridiculously long strings or preprocessor tokens.