Re: [boost] cache size runtime detection

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: 18 August 2015 10:12 To: boost@lists.boost.org Subject: Re: [boost] cache size runtime detection

On Tue, Aug 18, 2015 at 11:49 AM, Paul A. Bristow wrote:

...

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: 17 August 2015 18:09 To: boost@lists.boost.org Subject: Re: [boost] cache size runtime detection

On 17.08.2015 19:56, Joel FALCOU wrote:

...

...

...

It should definitely be a dedicated library. What I was thinking of for quite some time is a bit broader. My idea is a system capabilities library (Boost.SystemCaps) which would offer a generic interface for querying the current system properties such as:

- Number of CPU cores/threads.

...

...

Well, as far as creep goes, we can have a basic system put together adn expand it later.

Yes, that's my thought as well. Such a library can never be complete. :)

Not all systems will have all meaningful values for all features.

Can we establish a good 'NotANumber' right at the start

(preferably better than the -1 used in the C-ish

http://pubs.opengroup.org/onlinepubs/009695399/functions/sysconf.html)?

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.

I'd really like to avoid dependency on a math library for NaNs or big numbers.

If we absolutely need to report an error or absence of the actual data then I'd rather decide between boost::optional or an exception. I'm leaning towards 'return optional when the data may be legitimately absent, but

I wasn't implying THE FP math NaN - which is why 'NotANumber' is in quotes ;-) throw

exceptions when obtaining it results in an error'. With this approach get_memory_size() would return uintmax_t and throw in case of errors. On unsupported platforms (for which there is no implementation) it would be absent, and a config macro would be defined to indicate that.

Sounds reasonable - I'm just suggesting to give it some thought - which you have. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830