User-defined literals check for Intel C++ compiler

[speth]

When compiling with the Intel C++ compiler version 14 using c++11 mode, the check for whether user-defined literals can be used does not work. Including format.h leads to the error:

include/cantera/ext/format.h(3223): error: expected an operator
  operator"" _format(const char *s, std::size_t) { return {s}; }

This compiler version does not support user-defined literals (support is introduced in version 15, per https://software.intel.com/en-us/articles/c0x-features-supported-by-intel-c-compiler). However, the macro FMT_USE_USER_DEFINED_LITERALS ends up being defined only by the GCC version.

The Intel compiler version can be checked using the macros __ICC on Linux/OSX and __ICL on Windows, which returns the number 1400 for my compiler version. There is apparently no macro that is actually cross-platform.

I've only checked this on version 2.1, but it looks like the test for this hasn't changed in master.

[vitaut]

Thanks for reporting. Does ca33c93 fix the problem?

[dean0x7d]

The __INTEL_COMPILER macro should work cross-platform as far as I know. Note that Intel also defines the __GNUC__ family of macros or _MSC_VER depending on platform, which usually means that Intel's macro should be checked before anything else (it's a bit of a mess).

I have access to both older and newer icc versions so I can test it and/or make any required changes. Let me know if it's needed.

[vitaut]

I have access to both older and newer icc versions so I can test it and/or make any required changes. Let me know if it's needed.

That would be very helpful, thanks!

I am not sure if __INTEL_COMPILER is portable because https://software.intel.com/en-us/node/524490 says __INTEL_COMPILER (Linux*, OS X*).

[dean0x7d]

Yes, you're right. Sorry about that. I was using a compatibility layer which I forgot about and assumed to be the native macro. Anyhow, I'll test it out a bit later today.

[speth]

ca33c93 does not fix the problem for me. I'm working on Linux, so the problem is not the value of _MSC_VER, it's the value of FMT_GCC_VERSION which is 408, corresponding to the system installation of GCC 4.8. (Although I guess there could be similar issues on Windows depending on the combination of Intel and MSVC versions).

[dean0x7d]

@speth I believe #312 should fix the issue. I tested it with Intel C++ 14.0 on Linux. Perhaps you could try it out.

[speth]

Yes, this works for me. Thank you. If this could be applied to the 2.x branch as well, it would be very helpful.

[vitaut]

Thanks again, @dean0x7d.

@speth, I plan to release 3.0 in the next few days and recommend using it to avoid migrating to a new directory structure again in the future. Will it work for you?

[speth]

Yes, if the directory structure and naming conventions in the current master will be stable for the 3.0 release, that will work fine. Thanks again.

[vitaut]

Yes, the directory structure should be stable now. The naming conventions other than the library name itself (which doesn't affect API) haven't changed.