Re: [boost] cache size runtime detection

On 20.08.2015 22:04, Rob Stewart wrote:

On August 18, 2015 4:23:24 PM EDT, Andrey Semashev wrote:

...

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.

I'd prefer to allow the ability to fill the (possibly partially filled) features object with an explicit function call. Also the static factory function makes an extra copy in the following pattern: void foo() { static cpu::features f = cpu::features::complete(); } I agree that using an enum or a special tag type instead of bool would be better. That way the code would be more descriptive.