I have CLion installed with presumably default configuration. I think something is wrong with it, because I can't see exceptions. For example, this code:
int main(){ throw 5; }
Prints only Process finished with exit code 0
Why doesn't it print the exception?
Why does it print 0 instead of 1?
Here is an example showing how other console output is printed and CLion is running code:
For comparison:
int main(){try { throw 5; } catch(int x) { std::cout << x << '\n'; }}
This prints 5.
Note: this is not a duplicate of "not seeing any console output". I can see console output just fine. The only thing that is not showing is error messages.
Related
I am having trouble understanding the output of my very little program which should read characters from a text file until it finds a new line.
It correctly outputs the characters and stops, but I don't understand why it still outputs the newline ('\n) character in the terminal and doesn't end before getting to it.
I know that I could use getline() or find another way but I would really understand the reason behind this behaviour.
Thank you in advance!
Edo
Code:
int main() {
std::ifstream in_file;
in_file.open("../responses.txt");
char c;
while(c != '\n'){
in_file.get(c);
std::cout << c << std::endl;
}
return 0;
}
Output:
A
B
C
D
E
Time elapsed: 000:00:000
The
Used Versions: OMNeT++ 5.0 with iNET 3.4.0
I created some code, which gives me reliable results in ‘step-by-step’- or ‘animated’ simulation mode. The moment I change to ‘fast’ or ‘express’ mode, it gets buggy. The following simplified example will explain my problems:
void MyMacSlave::handleSelfMessage(cMessage *msg)
{
if (msg == CheckAck) {
std::cout << “CheckAck: “ << msg << std::endl;
}
if (msg == transmissionAnnouncement) {
std::cout << “transmissionAnncouncement: “ << msg << std::endl;
}
if (msg == transmissionEvent) {
std::cout << “transmissionEvent: “ << msg << std::endl;
}
delete msg;
}
There is a function, which is called for handling self-messages. Depending on what self-message I got, I need to run different if queries.
I get this correct output in step-by-step or animated mode:
CheckAck: (omnetpp::cMessage)CheckAck
transmissionAnncouncement: (omnetpp::cMessage)transmissionAnncouncement
transmissionEvent: (omnetpp::cMessage)transmissionEvent
And this is the strange output I get using fast or express mode:
CheckAck: (omnetpp::cMessage)CheckAck
transmissionAnncouncement: (omnetpp::cMessage)transmissionAnncouncement
transmissionAnncouncement: (omnetpp::cMessage)transmissionEvent
transmissionEvent: (omnetpp::cMessage)transmissionEvent
The third output line shows that the self-message is ‘transmissionEvent’, but the ‘if (msg == transmissionAnnouncement)’ is mistakenly considered as true as well.
As shown above I get different simulation results, depending on the simulation mode I am using. What is the reason for the different output? Why is there even a difference?
As Christoph and Rudi mentioned there was something wrong with the memory allocation. When a pointer is de-allocated and a new one is allocated on the same memory, there will be something wrong. The difference regarding the usage of different running modes is just a sign that there are errors to that effect.
In my case it was useful to check for message-kinds like:
if (msg->getKind() == checkAckAckType) {
instead of the method used in the originally question. I defined the message-kinds using simple enums.
Should I call SDL_DestroyWindow if Window Creation fails? I have the following code below:
if(this->Window == NULL)
{
std::cout << "Error: Can't create the SDL Window \n" << SDL_GetError() << "\n";
SDL_DestroyWindow(this->Window);
std::exit(EXIT_FAILURE);
}
Is it wrong?
From the SDL wiki :
If window is NULL, this function will return immediately after setting the SDL error message to "Invalid window"
You don't have to call SDL_DestroyWindow if you don't have a window in the first place : it will not do anything (other than setting an error message).
You can think of it like free in C or delete in C++. If you give them NULL or nullptr (respectively), they do nothing.
So, here is a countdown.
My aim is the next: if you don't do anything for the given time (ent_sec) the countdown will reach 0 after a time and return with 0, BUT if you press down the letter c (code: 99) the countdown stops and you can enter your PIN code and return with it.
I have already solved the problem with Windows.h in the next way:
if (GetAsyncKeyState(VK_SPACE))
This solves the problem is through WIN32 API (in this case you have to press SPACE, not letter 'c'), but it revealed that I can't use any WinAPI function (school project). So I rewrite this line to the following:
if (getchar() == 99)
But unfortunately it doesn't work in the proper way, cause my countdown stops in almost every second until I dont't press some "wrong" key (for example I press 'x', then the countdown goes forward, but in the next sec it stops again)... In the first solution (win func) this problem doesn't exist... So how can I fix that? Thanks. Here is the whole code of my function:
unsigned Timer::DownCount
{
int ent_sec = this.time;
cout << "The counter has started (" << this.time << "sec), press 'C' to enter your PIN code: " << endl;
while (ent_sec >= 0)
{
if (getchar() == 99) // c letter's code is 99 in ANSI (or ASCII dunno)
{
unsigned code;
cout << "PIN code: ";
cin >> code;
return code;
}
else
{
SecCounter(1); // this function counts 1 secundum
cout << ent_sec << endl;
ent_sec--;
}
}
return 0;
}
I don't believe there's a standard way to do this that will work across all platforms, but here's one way of doing it that will work on Windows without actually using Windows API functions.
int getch_nowait()
{
if (!kbhit()) return -1;
return getch();
}
Then your check just becomes if (getch_nowait() == 99) ...
This code may be compiler specific. If it doesn't work for you, it'll help if you tell us what compiler and operating system you are using.
I've been using the following bit of code for years to consume characters from cin up and including the next newline.
void skip_rest_of_line()
{
while (cin.get() != '\n') {}
}
I would call this after a catching an exception and clearing the cin state, as in:
catch (Error& error) {
cout << error.msg << endl;
cin.clear();
skip_rest_of_line();
}
The next read from cin skips the remaining newline as whitespace.
I've just changed to Xcode 4.4.1 under Lion. Using LLVM GCC 4.2 GNU++98, libstdc++(GNU C++ standard library), it works like it always did.
But using Apple LLVM Compiler 4.0, c++11, libc++ (LLVM C++ standard library with C++11 support) it looks like there are multiple problems with recognizing the newline. The same code as above requires a second return keystroke to satisfy the loop! The same problem appears with the alternative:
cin.ignore(numeric_limits<streamsize>::max(), '\n');
Finally, using getchar instead of cin.get() in the while loop works like it always did!
Is this a bug in libc++? Or have I missed something either in Xcode or C++11?
In response to Howard Hinnant, here is a little test case that shows what happens without any exceptions, etc. in the picture:
#include <iostream>
#include <vector>
using namespace std;
int main()
{
for(int count = 0; count < 2; count++) {
cout << "ready for input: " << endl;
int i;
vector<int> v;
while(cin >> i) {
v.push_back(i);
if(i == 3) {
while(cin.get() != '\n') {}
break;
}
}
for(auto it = v.begin(); it != v.end(); ++it)
cout << *it << ' ';
cout << endl;
}
cout << "done" << endl;
return 0;
}
It reads and saves ints until it's saved a 3, whereupon it reads and discards through the next newline, and then repeats the whole thing, so you can see that the stuff after the 3 gets discarded from the input stream. With Xcode 4.4.1 Lion with GNU++98 || GNU++11, libstd++, I get what I expect when I put in these two lines each terminated by a space followed by a RETURN keystroke:
1 2 3 4 5
6 7 8 3
and I get in the output window of Xcode:
ready for input:
1 2 3 4 5
1 2 3
ready for input:
6 7 8 3
6 7 8 3
done
But with C++11, libc++, nothing happens with the first line until I enter a SECOND RETURN keystroke, after both lines of input, but the proper discarding has still happened. So the extra space below after each input line is what the second keystroke looks like.
ready for input:
1 2 3 4 5
1 2 3
ready for input:
6 7 8 3
6 7 8 3
done
The very same behavior happens with using the above cin.ignore call instead of the while loop around cin.get(). So the problem is "Why is the second RETURN keystroke needed?"
I think this is a bug in libc++ on Lion, and fixed on Mountain Lion. But it is difficult to be certain without a complete test case.
Update
Thanks for the test case. Confirmed bug on Lion and fixed on Mountain Lion.