3

I am writing an experimental networking program, basically a test program for learning networking. I am using SDL and SDL_net in Code::Blocks with mingw, so the console output was being directed to stdout.txt. I searched around and found that you can fix this by including after SDL_Init():

freopen("CON", "w", stdout); //stops redirect of output
freopen("CON", "w", stderr); //and errors...

This worked perfectly, but only when building and running the program in the IDE: when run outside of the IDE ( e.g. double clicking on the program) the program runs properly, with the exception of the console output, which is still blank. As the program is supposed to be a console program this is a severe problem... I don't want to have to always run the program in the IDE to use it.

Any solution is apreciated but I would prefer that it was an alteration to the code, although in a pinch a batch file will do (I've read a couple of posts where this is the only thing that works, but they didn't go into much detail, so I can't replicate it). Thanks.

QubicGames
  • 63
  • 1
  • 7

4 Answers4

2

For (MinGW) SDL 2.0 users

SDL 2.0 disables the console by default, or rather, it does not enable it. Since compiling with -mwindows disables the console, stdout does not point to anything. SDL_Log is a little fancier and can find the console using the windows API, but it can't capture stdin, because cmd.exe stole it :(.

SDL does not claim the console for various reasons, most likely because the program was compiled with -mwindows. Specifying WinMain as the entry point might also make cmd.exe reclaim the console. From what I've read SDL_main might redirect stdout and stderr.

You could probably get away with #undef'ing main, and/or

  • call AllocConsole(); after SDL_init(...);
  • use freopen("CON", stdout)
  • compile without -mwindows (#undef'ing main doesn't seem to have any effect)

but you should really just redirect stdout to e.g. cat, with main | cat (Always follow the rule "Don't #undef main unless you have to").

TL; DR

To capture stdout for MinGW, simply redirect your program to cat: main | cat. This is a hack which simply makes sure stdout and stderr don't point to nothing.
To capture both stdin and stdout, compile without -mwindows to create a Windows console application. This will open a new window if necessary.

Note: It is especially important to flush output when using one of the above methods. Relying on line buffering is bad practice anyway.

yyny
  • 1,623
  • 18
  • 20
1

(I couldn't post this yesterday because I didn't have enough reputation)

Ok, did a little experimenting on the lines of the batch file. My resulting and (almost) working batch file:

program.exe

Didn't realise it would be this simple, but still can't understand why double clicking on the program doesn't work. I said almost working because after the client connects to the server the console blanks out, so there is still an issue. So, I still would really apreciate any help with this problem.

(End of yesterday's prospective post)

(Begining of today's answer)

I tried Emartel's suggestions but it still didn't work. Did some testing and discovered that an infinite loop of printing a empty string was causing the issue of the blank screen after connecting the client. Fixed the loop and now it works properly, although I still have to use the batch script.

Would apreciate knowing if someone ever figures out why double-clicking doesn't work.

QubicGames
  • 63
  • 1
  • 7
0

Did you take a look at the SDL Console FAQ?

They provide many suggestions, including:

First try

freopen( "CON", "w", stdout );
freopen( "CON", "w", stderr );

If it doesn't work (like in your case), try

#include <fstream>
#include <iostream>
using namespace std;
....
ofstream ctt("CON");
freopen( "CON", "w", stdout );
freopen( "CON", "w", stderr );
...
ctt.close();

OR

FILE * ctt = fopen("CON", "w" );
freopen( "CON", "w", stdout );
freopen( "CON", "w", stderr );
...
ctt.close();

Another option is to recompile the SDLmain library or add the SDLmain code to your project and stop linking against the library.

emartel
  • 7,712
  • 1
  • 30
  • 58
  • (Couldn't edit comment) Thanks for your response, that article is actually where I got my code, but I should have tried the other two methods first. Thanks again! – QubicGames Jan 31 '13 at 00:19
  • Are the other methods working for you? Rebuilding SDLmain would probably be a pain but hopefully the other solution works! - never mind, just saw your other post, did you try rebuilding SDLMain? – emartel Jan 31 '13 at 00:57
  • No, I haven't... For one I don't have enough experience to do it, for another the batch file works fine for now, but I might look into it at some point. Do you just compile it like normal code (into a .o file that is?) – QubicGames Jan 31 '13 at 03:52
  • Yes, if im not mistaken you should be able to get the project to build it on their Mercurial repository – emartel Jan 31 '13 at 04:06
  • It Worked! I looked back at the FAQ and saw it gave a tutorial for recompiling the library. Went through the tutorial (which was relatively short) and the new .a file works, without the .bat file. Thanks for all your help, Emartel. – QubicGames Feb 01 '13 at 00:07
  • The code above (as per the suggestions from the SDL FAQ) simply creates a file where the output is dumped. It shows nada in the console during the part of the code where SDL runs. – rbaleksandar Oct 24 '15 at 14:58
0

Two reasons:

  • With SDL the console is disabled. SDL uses windows, not consoles.

  • SDL redirects the standard output (both cout and printf()) to a file named stdout.txt in the same folder where the *.exe is located directory.

You can use:

std::cout << "Hello World";

And the message will be stored in the file stdout.txt.

Chirry
  • 640
  • 6
  • 12
  • Frankly this seems not to apply to the version in the Debian repos. I get no such file and `std::cout` works just fine. `printf` is the one causing problems. So it's better to say that it depends on the shipped version. – rbaleksandar Oct 24 '15 at 14:59