[SDL] I/O problem (stdio and stderr redirection to txt files)
tarini at isti.cnr.it
Tue Mar 15 10:16:36 PST 2005
> I didn't know [stdio redirection] crashed SDL though, that should be fixed.
> -Sam Lantinga"
Stdio and stderr redirection is probably the worst idea I've heard these years.
Honestly, I was shocked when I've seen it, I almost lost my confidence is STL in
How bad stdio/stderr redirection is? I dunno where to start. It's just too bad.
1- If, say, the video initialization fails, your application is totally dumb to
the user, it will not even have the breath to say "cannot initalize video
because..." in any way that an honest end-user would expect. Totally dumb. Maybe
use loud voice from the speakers to communicate error messages ;) ?
2- It cannot be turned off, it will last all the way down to the final release
and to the final user. Who will be really puzzled/pissed.
3- Your binary will not run double clicking it, if it is stored on a write-only
media like a CD-rom. But admittedly this is just a guess of mine. Is it really
the case? Even if crashes are avoided, the "from-CD" applcation functionality
would be still impaired (no output).
3- It's useless. Us window users are used to the "window disappearing before you
read the message" problem and known _sensible_ ways to get around it during
developement. Thank you.
4- If I wanted my messages (a log, whatever) to be written in a file rather than
on the screen I would just do that, really, I've no problem with that.
5- If the final user wanted the textual output of the application to be written
on a file rather than on the screen _he_ would just do that, as with any other
application, using the ">" command-line syntax (yes, that works in windows too).
Also, if you want to do that for them you can write a ".bat" file for them. Just
as for any other application!
5- If two applications are executed from the same directory, or the same
application is executed twice, their output collide! This is my case. I'm
developing a client server application and to test it I execute the
just-compiled executable twice - once as client and once as server. Of course
this can be worked around, but it really _is_ annoying.
5- The time I executed my first SDL application it costed me, as for many other
I guess, a puzzling quarter-of-hour before I found the shocking true on the web.
6- It needlessy negates, forever, any and every access I should have to the
command line screen. Now, just how bad is that? SDL is supposed to be the key
unlocking cross-platorm-programming and yet it denies me the access to the
single most cross-platform feature of C, namely, the stdout. Heck, I could have
a 1980's machine with no monitor at all, just a printer and still enjoy my
standard textual output fine.
7- It negates many possibile elegant solutions. For example, in my client-server
application the "waiting to connect" phases takes place before even initializing
the video or opening any window - which is nice. Using SDL, I cannot do that. I
bet there would be similar examples.
8- As noticed, it is a unneeded element of behaviour dependence of the same code
on the system where it is complied. Bad, bad.
9- It negates a quick useful way to let the user know what the thing is doing
(and why it is taking so long).
As in: "Loading textures... " <time passes> "done".
<Time passes> does not get written to txt files.
So I my personal suggestion is:
Don't just give the possibility to turn it off (leaving it on by default).
Don't just turn it off by default (leaving the possibility to turn it on).
Instead, remove it. It is evil. Take it to Mount Doom!
Can I be of any help about this? It seems to me that this is just a choice, not
a matter of "finding someone who implements it", but if that is not the case...
Since I've been such a negative critic in this contribution, let me add how much
I liked most of the rest of SDL. It is really great. Too bad for this (and a
very few other) "minor" details.
More information about the SDL