> Interesting metaprogramming, but I am not convinced that
> this approach would really improve software quality for
> real-world projects.

I probably should have mentioned in the article that this problem was posed to me by a client. They were developing games running across the internet, and they had the notion of "deterministic" code, which, as best I can recall, was code that yielded exactly the same results, regardless of the platform on which it was run. Some of their functions were "deterministic" and some were not, and they asked me if I could think of a way to make it impossible for "deterministic" functions to call ones that were not "deterministic."

I think that if we had tools to enforce code features, we'd find all kinds of places where they were useful.

> Everything is still based on programmer discipline. How
> does a "threadsafe" tag save me from calling strerror()
> instead of strerror_t()?

Enforcing code features doesn't save you from all your errors, but it gives you a tool to enforce certain interface contracts that are currently invisible to compilers. Think of it as a new feature of the type system. If you find type systems useful, I'd hope you'd see that this new feature could help prevent certain kinds of errors.

> Also, properties like "threadsafe" or "portable" are very
> hard to define and will probably change their meaning over
> time. This looks like a maintainance-nightmare to me.

Current code already depends on code features, and the definitions of those features are already subject to change. If the definition of some feature (such as "thread safe") changes, functions that depend on the new definition will likely behave improperly when calling functions offering only the old definition. We currently catch such errors via code reviews, testing, and debugging. Using the approach I describe, we'd just change the name of the code feature (e.g., from "ThreadSafeV1" to "ThreadSafeV2", possibly having the latter inherit from the former, as suggested in the "Open Issues" section of the article), update the code to use the new feature names in the appropriate places, and recompile. If the result was not consistent, the compiler would complain. I don't see how this would be any worse than the way we currently do things, and I'd expect it to be better.

Scott

The last article in The C++ Source was published in 2008.
Is the journal closed?

I was thinking further about my idea, and realized the problem with this. It works well for basic purposes: to enforce certain functions to have a set of features. However, it doesn't work for automatic overload resolution. For example, if we have a function with an overload that is thread safe, and another that is both thread safe and exception safe, and we call it with a requirement of being only thread safe, we will get an error of ambiguous overload.

The original solution uses virtual inheritance, which provides a built-in overload resolution choosing the closest possible match. With implicit conversion, we can't use this algorithm. We have to choose the overload "manually" via enable_if. I built a forwarding of enable_if that computes this without the need to write large expressions for every overload. The disadvantage is that we need to know all the overloads in advance. Here is how it works.

namespace mpl = boost::mpl;
namespace cf = CodeFeatures;

typedef cf::Features<mpl::vector<ThreadSafe>> TSafe;
typedef cf::Features<mpl::vector<ThreadSafe, ExceptionSafe>> TESafe;

typedef mpl::vector<TSafe, TESafe> CalleeFeaturesList;

template <class Features>
typename cf::SelectFeatures<Features, TSafe, CalleeFeaturesList>::type
callee()
{
	std::cout << "TSafe" << std::endl;
}


template <class Features>
typename cf::SelectFeatures<Features, TESafe, CalleeFeaturesList>::type
callee()
{
	std::cout << "TESafe" << std::endl;
}

This version has advantages over the original implementation as well. First, as it uses templates and decides which overload to use with the metafunction on the top, we don't even need to instantiate the feature variables. Second, the template makes these functions pass its requirement transitively. For example, we have a caller function like this:

template <class Features>
typename cf::SelectFeatures<Features, TESafe, mpl::vector<TESafe>>::type
caller()
{
	callee<Features>();
}

This function provides both thread safety and exception safety to its callers, and has no overloads. However, if we only need thread safety, it will call the TSafe version of callee, providing a more efficient program without needing to use overloads over the whole call hierarchy.

Of course, if we don't want to use templates, the original approach works just as fine:

typedef TESafe callerFeatures;
void callerNoTemplate(callerFeatures features)
{
	calleeNoTemplate(features); // the original way
	callee<callerFeatures>();   // of course we can't use the variable in the template parameter. We have to use the type name itself.
}

Here is the implementation. First, I introduced some new metafunctions because the lack of contains_if in Boost MPL.

template <typename Seq, typename Pred>
struct none_of: boost::is_same<
	typename boost::mpl::find_if<Seq, Pred>::type,
	typename boost::mpl::end<Seq>::type
> {};

template <typename Seq, typename Pred>
struct all_of: none_of<
	Seq,
	boost::mpl::not_<Pred>
> {};

With this, even the definition of Features becomes easier. Otherwise, it does the same as before (except that in my last post, I left out the default constructor).

template <typename S>
struct Features
{
	typedef S features_type;

	Features() {}
	
	template <typename OtherFeature>
	Features(
		const OtherFeature&,
		typename boost::enable_if<
			typename detail::all_of<
				typename OtherFeature::features_type,
				boost::mpl::contains<S, _>
			>::type,
			int
		>::type = 0)
	{}
};

Now comes the implementation for SelectFeatures. In human words, it does the following: "Enable this overload if T is convertible to ThisType and not convertible to any types in AllTypes which ThisType is also not convertible to."

template <typename T, typename ThisType, typename AllTypes, typename ValueType = void>
struct SelectFeatures: boost::enable_if<
	boost::mpl::and_<
		boost::is_convertible<T, ThisType>,
		detail::all_of<
			AllTypes,
			boost::mpl::or_<
				boost::is_convertible<ThisType, _1>,
				boost::mpl::not_<
					boost::is_convertible<T, _1>
				>
			>
		>
	>,
	ValueType
> {};