Cool Link Stash, January 2013

C++

There's a good video talk up on Channel 9 from the C++ and Beyond 2012 conference called You don't know blank and blank on the different meaning of const and mutable in C++11.
In summary, the const keyword in C++11 no longer means logical const as it did in C++98. In C++11 const has the sense of bitwise const (or at least internally synchronized to make a function or const-declared object thread-safe).
This follows from the fact that the C++11 standard library guarantees that const means thread-safe for its own types and all operations it calls on your types.
Thread-safe means bitwise const (i.e. no modifications) or internally synchronized. Copy constructors need to be thread-safe in C++11!
It follows that any object that is declared const is fully thread-safe, i.e. truly immutable or internally synchronized.
Note that it's already undefined behavior in C++98 to cast away const from an object declared const!
The new meaning of mutable in C++11 is also thread-safe. A mutable-declared mutex, for example, is now basically a thread-safe object (this means that even its non-const member functions are thread-safe).

Another good Channel 9 talk from C++ and Beyond 2012 that got posted recently is Herb Sutter's talk called C++ Concurrency.

Graphics

Sébastien Lagarde has an interesting (and still ongoing) blog post series on rendering real-time water.

In the SIGGRAPH brief A 2.5D Culling for Forward+ Takahiro Harada presents a new light culling approach for Forward+ (aka Tile-Based Forward Rendering). The idea is to basically split the frustum for a tile along the depth axis into 32 buckets and then create a bit mask that contains a 1 for a bucket with geometry and a 0 for a bucket with empty space. The same bit mask is computed for the volume of influence of a light. By comparing the bit masks lights can be quickly culled along the depth of a tile's frustum.

NVIDIA has a new, interesting paper titled Toward Practical Real-Time Photon Mapping: Efficient GPU Density Estimation.

PolyVox is a C++ library by indie game developer Volumes Of Fun that provides storage and processing of voxel-based environments. It's released under a liberal zlib license and the source code is available on BitBucket.

Inigo Quilez has an excellent article up on Multiresolution Ambient Occlusion with plenty of pictures. Well worth the read.

A pretty nifty idea for denoising images generated via Monte Carlo ray tracing is presented in the paper Robust Image Denoising using a Virtual Flash Image for Monte Carlo Ray Tracing by Boochang Moon et al. Here's the companion website with a video (download the file, don't watch it on youtube because the strong video compression makes it pointless). The idea is to generate a virtual flash image (by putting a flash-like light source at the camera position and summing that with direct illumination of diffuse surfaces and all interaction with specular surfaces). This virtual flash image is then used to guide the denoising process. The technique is somewhat similar to a paper from several years ago where a real-life flash picture is used to denoise a non-flash picture of the same scene via bilateral filtering.

The I3D paper from the Technical University of Vienna Fast Light-Map Computation with Virtual Polygon Lights describes a quality improvement to the typical VPL-based instant radiosity method to quickly generate light maps on the GPU.

Chris­t­ian Schüler has a nice article on his blog titled Normal Mapping Without Precomputed Tangents. As you might guess, it's about doing normal mapping in a pixel shader without passing a tangent frame via vertex attributes.

Web Development

Developing Backbone.js Applications is an early, online pre-release of a book by Addy Osmani on the popular JavaScript MVC framework Backbone.js.

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS

RudeBuild Version 1.3 Released

I just released version 1.3 of RudeBuild, my unity/bulk C++ build tool for Visual Studio 2008-2012. Check out the release notes and download information at http://www.martinecker.com/rudebuild/version-1-3-released/

For those not familiar with the tool, here's a description:

RudeBuild is a non-intrusive bulk/unity C++ build tool that seamlessly integrates into Visual Studio 2008, 2010, and 2012 as an add-in. It can speed up build times of large C++ projects by a factor of 5 or more. RudeBuild also supports the use of IncrediBuild to speed up your build times even more.

RudeBuild comes in two flavors, as a command-line tool that works on Visual Studio solution files and as a Visual Studio add-in complete with toolbar and menus.

When used as an add-in the toolbar acts and looks just like the regular build toolbar but behind the scenes a bulk/unity build of C++ projects is triggered, automatically combining the .cpp files into unity files in a cache location and running devenv to build the modified solution/project. Using RudeBuild in this manner is transparent to the developer and requires no modification to the original source code or project files whatsoever given that the codebase is bulk/unity build-safe. Being bulk/unity-build safe means that there are no symbols with the same name in two different translation units. For example, it is invalid to have a static function called GetFileTime in both File1.cpp and File2.cpp.

The command line version of RudeBuild is useful for automated builds, for example on build servers. A solution file, build configuration and optionally a project name must be specified on the command line.

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS

C++11 Wrap Pattern

Herb Sutter gave a great talk at the C++ and Beyond 2012 conference on concurrency in C++11.

The talk had an interesting interlude on how to wrap all functions performed on an existing type T in order to inject any desired behavior, and that's what this post is all about.
The pattern basically looks like this:

template <typename T>
class wrap
{
public:
	wrap(T wrapped = T{}) : m_wrapped{wrapped}
	{}
	
	// operator() takes any code that accepts a wrapped T
	// will usually be a lambda
	template <typename F>
	auto operator()(F func) -> decltype(func(m_wrapped))
	{
		// do any pre-function call wrapper work 
		auto result = func(m_wrapped);
		// do any post-function call wrapper work 
		return result;
	}
	
private:
	T m_wrapped;
	// ... other state required by wrapper
};

This wrap class template can now be used by instantiating it and calling operator() on it with an anonymous lambda function that accepts the wrapped type as single argument.

wrap<X> wrapper;
wrapper([](X& x)
{
	x.call_something(foo, bar);
	x.do_something_else();
	std::cout << x.print() << std::endl;
});

A concrete example of using this pattern is a monitor wrapper class, which is similar to the synchronized keyword in Java.
A monitor wraps every function call (or a group of function calls) on an existing class in a mutex lock to make the class thread-safe.

template <typename T>
class monitor
{
public:
	monitor(T wrapped = T{}) : m_wrapped{wrapped}
	{}
	
	template <typename F>
	auto operator()(F func) -> decltype(func(m_wrapped))
	{
		std::lock_guard<mutex> lock{m_mutex};
		return func(m_wrapped);
	}

private:
	mutable T m_wrapped;
	mutable std::mutex m_mutex;
};

Note that m_wrapped is mutable, which is required so that func(m_wrapped) works if func takes the T as a non-const reference T&.

Mutable in C++11 means thread-safe, which means either bitwise const or internally synchronized. Our mutex lock guard guarantees that by the time the m_wrapped is used in func(m_wrapped) it will be internally sychronized, so making m_wrapped mutable is perfectly acceptable.

monitor<string> s = "start\n";
std::vector<std::future<void>> tasks;

// start a bunch of tasks
for (int i = 0; i < 5; ++i)
{
	tasks.push_back(async([&,i]
	{
		// single transaction, synchronized modification of s
		s([=](string& s)
		{
			s += "transaction " + to_string(i) + " of 5";
			s += '\n';
		});
		
		// do some more work
		
		// single transaction, synchronized read of s
		s([](string& s)
		{
			std::cout << s;
		});
	});
}

// join all tasks
for (auto& task : tasks)
	task.wait();

Note that T used in wrap or monitor could also be a reference, if you don't want to make a copy of T. This is useful for capturing stateful objects, such as std::cout.
So it is perfectly valid to do:

monitor<ostream&> sync_cout{std::cout};

sync_cout([=](ostream& cout)
{
	cout << "Writing stuff to cout..." << std::endl;
	cout << "in a synchronized way" << std::endl;
});

That's a wrap, folks! 🙂

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS