On 18/08/2015 11:12, Andrey Semashev wrote:
For some data it is enough to return some meaningful pessimistic default in case if the actual value cannot be obtained. E.g. for ISA extensions we could return 'not supported', for cache size return 0, for OS version string return an empty string (or a fixed string based on the data available at compile time) and so on.
For other data this doesn't quite work though. We can't return 0 as the system RAM size, for instance - except we can but then the user's application would have to check for this special value. I'm not sure what is best in this case.
One other stuff to consider, as we had reort of this issue by our users, is that such facility should have cached and non-cached retrieval function. Using CPUID to grab SIMD facility for example is slow enough to have a noticable impact on computing in some cases, hence the need for caching. I think some of those config are static anyway (you won't remove a CPU feature midfight) and must be cached in static value at start-up. Others, like for example amount of available free RAM must not.