I’ve used FsCheck with XUnit for writing and running unit tests, so will be interested to see how the concepts translate to C++ in QuickCheck++ and AutoCheck.
Impact of volatile and atomic on performance
Marc Brooker posted an interesting breakdown on the performance impact on use of volatile and atomic. He also points out that volatile alone doesn’t prevent concurrency issues – if you need synchronisation, then you need atomic.
Filed under C++
Dark Pools in the news
Two dark pools are in the news:
The two cases differ decidedly, according to industry pros. In the Pipeline case, the settlement was based on fraud and resulted in direct charges against individuals. Pipeline failed to disclose that more than 97 percent of orders in its dark pool at times were filled by a trading operation affiliated with the firm.
LeveL ATS is rebounding as 2012 comes to a close. It says clients are returning since its parent firm, eBX LLC, paid an $800,000 fine and settled charges that LeveL failed to properly safeguard information on customers’ unexecuted orders, which were stored and allegedly reused in a smart order router.
In the same article, news on brokers who are analysing the profile of those trading in their dark pools, e.g. The Light Pool by Credit Suisse:
The alternative system classifies users by how they trade. The venue categorizes participants, helping mutual funds, hedge funds, pensions and endowments trade only with parties they are comfortable with.
Filed under Finance
The Future of Life – from Biology to the Biosphere
I was fortunate to attend this excellent presentation by Stephen Emmott at the Institute of Engineering and Technology, London in December. They’ve now made the video available:
![]() |
The Future of Life: From Biology to the Biosphere Stephen Emmott The Future of Life Evening Lecture, 2012-12-13 00:00:00.0 IT Channel |
Filed under Technology, Video
Delegating Constructors in C++11
Here’s some code that tries out C++ 11 delegating constructors. These were announced as part of Visual Studio in the November CTP and avoid the need to refactor common code out of constructors into an “init” function. There are examples of their use in Stephan Levavej’s excellent video series too.
class Request
{
public:
enum class Priority{ High, Medium, Low };
static const Priority defaultPriority(){ return Priority::Low; }
// Constructor with all parameters fully specified
Request( Priority priority, const std::string& requestId ) :
m_priority( priority ),
m_requestId( requestId )
{
std::cout
<< "Request( Priority priority, const std::string& requestId ) called: "
<< "RequestId " << m_requestId << ", "
<< "Priority " << toString( m_priority ) << "\n";
}
// Delegate to fully specified constructor above
Request( const std::string& requestId ) :
Request( defaultPriority(), requestId )
{
std::cout
<< "Request( const std::string& requestId ) called: "
<< "RequestId " << requestId << "\n";
}
// Contrived example to demonstrate chaining delegating constructors
Request( const std::vector<int>& requestId ) :
Request( toString( requestId ) )
{
std::cout << "Request( const std::vector<int>& requestId ) called\n";
}
// Contrived example to show that ~Request() is called if the delegating constructor completed
Request( Priority priority ) :
Request( priority, "Empty" )
{
throw std::exception( "This constructor is deprecated, RequestId field is now mandatory." );
}
~Request()
{
std::cout
<< "~Request() called:"
<< "RequestId " << m_requestId << ", "
<< "Priority " << toString( m_priority ) << "\n";
}
private:
std::string toString( const std::vector<int>& requestId )
{
std::string tmpId;
for (auto elem : requestId)
{
if ( elem < 0 || 9 < elem )
throw std::exception("Invalid request id, should be digits");
tmpId.push_back(static_cast<char>(elem + '0'));
}
return tmpId;
}
std::string toString( Priority p )
{
if (p == Priority::Low ) return "Low";
else if ( p == Priority::Medium ) return "Medium";
else if ( p == Priority::High ) return "High";
else
throw std::exception( "Unexpected Priority" );
}
Priority m_priority;
const std::string m_requestId;
};
And here’s a program that exercises the Request class (this uses musingstudio::initialize to conveniently initialize a standard container):
int _tmain(int argc, _TCHAR* argv[])
{
std::cout << "\nCall fully specified constructor\n";
Request fullySpecified( Request::Priority::High, "HeartTransplant-749553" );
std::cout << "\nCall a delegating constructor\n";
Request defaultPriority( "BookDelivery-5542" );
std::cout << "\nCall chained delegating constructors\n";
Request legacy( musingstudio::initialize<std::vector<int>>( { 1, 6 } ) );
std::cout << "\nThis should throw without executing the destructor...\n";
try
{
// This should throw due to -ve input, but does NOT execute ~Request()
// because no constructor call completed
Request invalid( musingstudio::initialize<std::vector<int>>( {-1} ) );
}
catch( const std::exception& exc )
{
std::cout << "ERROR: " << exc.what() << std::endl;
}
std::cout << "\nThis should throw and execute the destructor...\n";
try
{
// This will throw because no requestId is not specified
// (contrived example to show that ~Request() is executed
// because the delegating constructor succeeded).
Request noRequestId( Request::Priority::Low );
}
catch( const std::exception& exc )
{
std::cout << "ERROR: " << exc.what() << std::endl;
}
std::cout << "\nRemaining destructors...\n";
return 0;
}

As with other Nov CTP features, Visual Studio intellisense hasn’t caught up yet, so expect to see red squiggly lines all over the code if you try this out.
What’s interesting is that it’s now possible for ~Request() to be called if a constructor fails to complete, as long as the delegatee (inner) constructor does complete.
Filed under C++ Code
Money and Speed: Inside the Black Box
HFT Review publicized this excellent video by Marije Meerman on the flash crash:
In her latest film ‘Money and Speed: Inside the Black Box’ she continues this format, talking of High Frequency Trading and the ‘Flash Crash’ of 6th May 2010 through the eyes of the regulators and market participants.
Paul Wilmott is one of the contributors.
Setting max_load_factor to infinity in an unordered_set (to avoid re-hashing)
This StackOverflow post was cited on the ISO C++ blog. Interesting that they set the max_load_factor to std::numeric_limits::infinity(), but the crux of the question is whether it’s ok to iterate over the newly inserted items as well as the original items.
Filed under C++
Another new C++ 11 feature: constexpr
Danny Kalev wrote this post about constexpr:
constexpr is a new C++11 keyword that rids you of the need to create macros and hardcoded literals. It also guarantees, under certain conditions, that objects undergo static initialization. Danny Kalev shows how to embed constexpr in C++ applications to define constant expressions that might not be so constant otherwise.
The new C++11 keyword constexpr controls the evaluation time of an expression. By enforcing compile-time evaluation of its expression, constexpr lets you define true constant expressions that are crucial for time-critical applications, system programming, templates, and generally speaking, in any code that relies on compile-time constants.
constexpr is not available in Visual Studio 2010 or Visual Studio 2012 (not even with the November CTP).
Filed under C++
iPad Mini wifi and photo issues
I’ve noticed that my new iPad Mini has occasional wifi connectivity issues. Tablet crunch has several suggestions and resetting the network settings after installing the latest iPad OS upgrade has worked for me.
A separate issue is that photos taken from my iPhone are frequently upside-down when viewed on my PC. Rotating them in Windows Explorer doesn’t work – although they are corrected on the PC, they become inverted once copied onto the iPad. Instead, use Microsoft Pro Photo Tools to rotate the pictures on the PC – this results in correctly oriented photos on both the PC and the iPad.
Another tip is to take iPhone photos with the Square button on the right or bottom – that way, photos won’t need to be rotated at all.
Filed under Technology
Experimental code for simulating Reflection in C++
Motivation for looking at Reflection in C++
At work, we have two frameworks for developing new components – one in C++ and the other in F#. The F# framework is newer and benefits from the insight of previous years working with the C++ framework. In particular, the new F# framework only requires developers to implement a reduced, strongly typed interface in F# by defining a few types (e.g. records) and associated functions between them. This reduced interface is inflated into a full model by the framework, making heavy use of .NET Reflection.
The F# framework has delivered productivity improvements (development time down to a third compared to the previous C++ framework). But the philosophical question remains – how much of that is due to the new architecture developed with the benefit of hindsight? And could we replicate that architecture in C++? The main functionality gap comes down to this: in F# you can use .NET Reflection to discover the names and types of fields in F# types such as unions, records and options, but in C++ you can’t.
Requirements
A full implementation of Reflection for C++ would include ability to discover type information, field names, properties and methods, as well as being able to create instances of types and invoke methods. I’m interested in a small subset of that scope – the ability to discover the names and values of fields in a C++ struct.
Solution
#include "stdafx.h"
#include <iostream>
#include <string>
#include <boost\preprocessor.hpp>
#include <boost\preprocessor\variadic\size.hpp>
#include <boost\type_traits.hpp>
#include <boost\mpl\range_c.hpp>
#include <boost\mpl\for_each.hpp>
#define REMOVE_BRACKETS(...) __VA_ARGS__
#define REMOVE_NEXT(x)
#define STRIP_TYPE(x) REMOVE_NEXT x
#define DECLARE_DATA_MEMBER(x) REMOVE_BRACKETS x
#define TYPE_ONLY(x) x REMOVE_NEXT(
#define REFLECTABLE(...) \
static const int number_of_fields = BOOST_PP_VARIADIC_SIZE(__VA_ARGS__); \
friend struct Reflector; \
\
template<int N, class Parent = void> \
struct FieldData {}; \
\
BOOST_PP_SEQ_FOR_EACH_I(REFLECT_EACH, data, BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__))
#define REFLECT_EACH(r, data, i, x) \
DECLARE_DATA_MEMBER(x); \
template<class Parent> \
struct FieldData<i, Parent> \
{ \
Parent & parent; \
FieldData(Parent& p) : parent(p) {} \
\
TYPE_ONLY x ) & get() const \
{ \
return parent.STRIP_TYPE(x); \
}\
const char * name() const \
{\
return BOOST_PP_STRINGIZE(STRIP_TYPE(x)); \
} \
}; \
struct Reflector
{
// Get a FieldData instance for the N'th field in type T
template<int N, class T>
static typename T::template FieldData<N, T> getFieldData(T& x)
{
return typename T::template FieldData<N, T>(x);
}
// Reflector is a friend of T, so has access to the private member T::number_of_fields
template<class T>
struct FieldCounter
{
static const int count = T::number_of_fields;
};
};
// FieldDispatcher - calls Visitor::visit for each field in T
template<class T, class Visitor>
struct FieldDispatcher
{
FieldDispatcher( T& t, Visitor visitor ) :
t(t),
visitor(visitor)
{
}
template<class FieldIterator>
void operator()(FieldIterator)
{
auto field = Reflector::getFieldData<FieldIterator::value>(t);
visitor.visit( field );
}
T& t;
Visitor visitor;
};
template<class T, class Visitor>
void for_each_field(T& t, Visitor visitor)
{
typedef boost::mpl::range_c<int, 0, Reflector::FieldCounter<T>::count> FieldList;
FieldDispatcher<T, Visitor> field_dispatcher( t, visitor );
// For each field in T, dispatch the visitor to that field
boost::mpl::for_each<FieldList>( field_dispatcher );
}
struct PrintNameValueVisitor
{
template<class FieldData>
void visit( FieldData field )
{
std::cout << field.name() << "=" << field.get() << std::endl;
}
};
struct Person
{
Person(const char *first_name, int age, const char* street, const char* town) :
first_name(first_name),
age(age),
street_name(street),
town(town)
{
}
REFLECTABLE
(
(const char *) first_name,
(int) age,
(std::string) street_name,
(std::string) town
)
};
int _tmain(int argc, _TCHAR* argv[])
{
Person p("John", 31, "Electric Avenue", "Harrogate" );
for_each_field(p, PrintNameValueVisitor());
return 0;
}
Output

Conclusions
The code above ‘works’ – it satisfies the requirements by providing a way to decorate a struct with metadata that can be used to return the names and values of each field. However, in Visual Studio 2010 and 2012, it produces compiler warnings (due to the macro hackery in TYPE_ONLY) and confuses intellisense (which doesn’t cope with the REFLECTABLE macro). In practical terms, that makes it unsuitable, because the productivity benefits are lost when intellisense and auto-complete stop working.
Filed under C++ Code
