On August 18, 2015 4:23:24 PM EDT, Andrey Semashev
namespace boost::sys_info::cpu {
enum class feature_tag { // Arch-specific values sse, sse2... _count };
template< typename... Features > struct feature_list;
// This struct can be specialized for different feature tags template< feature_tag Tag > struct feature { // In specializations, we can describe pre-requisites // for each feature, e.g. there must be OSXSAVE and // the OS must be saveing/restoring YMM registers // in order to be able to use AVX. typedef feature_list< ... > prerequisites; };
constexpr feature< feature_tag::sse > sse = {}; constexpr feature< feature_tag::sse2 > sse2 = {}; ...
class features { // The flags indicate which features have been queried std::bitset< feature_tag::_count > m_cached; // The flags indicate which features are supported std::bitset< feature_tag::_count > m_values;
public: // By default creates an empty object. // The only thing it may need to do // is to obtain the max cpuid function number. // If do_init == true, calls init() automatically. explicit features(bool do_init = false);
This is the only thing which looks odd to me. It would be better to use an enumerated type, rather than bool here, or you could use the named constructor idiom (and make init() private). That is, create a default constructed features for no caching, or use features::complete(), say, to get one pre-populated. Otherwise, pass something like pre_load rather than true.
// Obtains all features at once void init();
// If not cached already, tests for the feature and its // pre-requisites and returns the flag template< feature_tag Tag > bool operator[] (feature< Tag >); };
} // namespace boost::sys_info::cpu
// Usage example void foo() { namespace cpu = boost::sys_info::cpu; cpu::features f; if (f[cpu::sse]) // SSE-optimized code foo_sse(); else // generic code foo_generic(); }
I know there are complications and possible ways of optimization. In particular, we actually discover multiple features with one cpuid call, so we might want to fill multiple flags per feature query. And for /proc/cpuinfo backed solution we might want to always parse the whole file at once. But I like this interface and the design looks extensible.
It looks very interesting and I like "sys_info". ___ Rob (Sent from my portable computation engine)