"No output" instead of compiler communication | Sololearn: Learn to code for FREE!

0

"No output" instead of compiler communication

Are you also experiencing this on Sololearn? Somewhere in the code is a bug, but for some reason there is no compiler reaction whatsoever; instead you get 'no output', even if that logically can't be, as if it was a semantic error. Then you erase a few unrelated lines and suddenly the errors are coming in, as if the compiler wanted to say: 'See? Give me less code and I might even look at it.' At other times: 'Compilation error.' Nothing else, no explanation whatsoever. Do you know this? What does it mean? How do you deal with it?

11/10/2018 10:18:28 PM

HonFu

2 Answers

New Answer

+4

[NO OUTPUT] run-time : (c/c++ example) Results from stack smashing / corrupt memory (or segfaults). Look for runtime memory violations. *((int*)0) = 0; // Segmentation fault (core dumped) --> No Output [COMPILATION ERROR] compile-time Warning/error text exceeds a threshold BEFORE the program starts. ~ Reported to Feedback / I have reliable test cases BUT may not be a bug. ~ Possible lesson: reduce the problems in your code causing massive warning/error output. * Diags: Block comment 50% of code, check for "Compilation Error", comment 50% more. When the program runs force an error like this and start un-commenting things: int main() { /* block commented code, no reason except to reduce possible compilation errors ...... */ probably_working_code(); false_call_forcing_crash(); } The "false call" just calls something that doesn't exist. It causes a single error that ALSO reveals (normally-suppressed) warnings bloating the output into a Compilation Error.

+1

Kirk Schafer, I was doing stuff with several vectors, so maybe I 'missed the target' somewhere... But aren't vectors supposed to call the mistake and terminate instead of letting weird stuff happen? Funny, I didn't know that you could have too many errors so that you don't get shown even one ... Very often it is just a single mistake that leads to follow-up trouble, right? Wouldn't it be more sensible for a compiler to give out the first few mistakes and stop when it gets too much instead of showing nothing at all? (I started with Python where you never have these issues, so it still confuses me (I had to google most of what you said).)