Support std::endl in custom C++ streams

I’ve been working on a custom Logging system for Vortex. After thinking about it for a while, I decided to go with a stream-based API for logging. I figured this would allow me to both: provide output capabilities for custom data types and also to format log messages “on the fly”.

This is where I started to play with the idea of being able to handle std::endl just like the standard streams.

Even though I’ve been a C++ programmer for a while (10 years since my first “hello world” program), I realized I actually didn’t know the type of std::endl. I looked around until I finally found something at Stack Overflow. Much to my surprise, it turns out std::endl is a function template! The correct way to handle it is, in the stream insertion operator (<<), call the passed-in endl function with the stream you are outputting to as the parameter.

// The code in Vortex is more involved, 
// but this is the general idea
Logger& Logger::operator<<(std::ostream& (*f)(std::ostream&))
{
    f(std::cout);
    return *this;
}

For Vortex, it was enough just to support std::endl taking and receiving std::ostream instances, it might be different in your code, depending on the degree of customization you want to provide.

Now that everything’s in place, we can handle std::endl just like any other stream:

Logger debug;
debug << "running loggerTest() in file.cpp:12" << std::endl;

QuakeCon 2011 Keynote

John Carmack, founder and lead developer of Id Software opens the 2011 QuakeCon conference.

In this Keynote, John Carmack discusses some implementation details of the engine powering Id’s next game: Rage. He addresses the issues faced while developing the engine for the PC, the XBox 360 and the PlayStation 3 and the problems they had to address while trying to maintain a steady 60 FPS while managing the game’s huge data sets.

The talk also emphasizes the importance of using Static Analysis tools to find bugs in large code bases. Some tools mentioned include “Microsoft Analyse”, “PVS Studio” and “PC lint”.

John Carmack also shares his views on in-game script interpreters. He mentions these are hard to debug and develop as well as the fact that they significantly impact performance and game quality. He recommends not going with dynamic languages, but instead having a strong type system and a very restrictive language. His views are that it is better to find bugs “as early as possible”, ideally at script compile time. He sees the best direction to go is with a Java-like subset of C++: a very strict, C or C++-ish language.

Finally, he closes the Keynote by looking back into the “early days” of game development and comparing that to the process studios have to go through today. He also announces the upcoming release of the Doom 3 source code later this year and recommends getting a copy of Doom 3 from Steam.



YouTube link.