Re: [boost] [MPL] A Proposal

On 11/13/2016 7:22 AM, Bruno Dutra wrote:

On Sun, Nov 13, 2016 at 6:47 AM, Edward Diener wrote:

...

On 11/12/2016 5:26 PM, Bruno Dutra wrote:

...

On Mon, Feb 29, 2016 at 1:52 PM, Bruno Dutra

...

[snip]

2016-02-29 6:37 GMT-03:00, Jens Weller :

...

[snip] Do you compile as fast as Brigand?

My next efforts will be directed toward developing a framework for running benchmarks. I'll be sure to add Brigand, as well as other alternatives of which I am aware, for comparison purposes.

[snip]

Now, finally, back to the question: Yes, Metal compiles just as fast as Brigand on both Clang and GCC and even considerably faster for some algorithms [1].

I should also mention that meanwhile I have completely overhauled Metal a few too many times already to make sure I explored all the possibilities modern C++ offers TMP and even though it's still subject to some minor refactoring, I'm confident that its current API is close to what will eventually make it to a stable release. In fact I've already written most of the reference documentation as I don't expect it to change significantly anymore and as such I'd like to invite all of those interested in metaprogramming to take a look at it [2]. Any feedback will be greatly appreciated.

[1]: http://metaben.ch/ [2]: http://brunocodutra.github.io/metal/

A quick note. Since the latest released clang version is 3.9 and the latest released gcc version is 6.2, wouldn't it be better if metal was tested with these versions.

Metal itself is setup to run unit tests on Clang 3.9 on Travis CI [1], but unfortunately that version of Clang is still not supported on their recommended container-based images [2]. For that same reason we are currently unable to publish benchmark data for Clang 3.9 compiler on metaben.ch.

Regarding GCC, Metal is in fact tested on version 6.2 on Travis [3], but due to some recent changing in the versioning scheme of GCC, Ubuntu abolished the minor version from their packaging of GCC, which means GCC 6 translates to the latest minor release, currently 6.2. Likewise GCC 5 currently translates to 5.4. The same goes for benchmark results published on metaben.ch.

My point really is that whatever Travis CI or any other CI supports you yourself should test on your local computer using the latest version of compilers which will support better the level of C++ compliance you need.

...

I also noticed that Travis CI uses old versions of both clang and gcc, so I wonder why so much software is still using old versions when new, better ones are available, especially as relates to C++11 on up support.

I believe Travis CI provides the original versions of development tools that are available by default on the OS images they use. Since their recommended container-based environment still runs on Ubuntu 12.04, one can imagine that the versions of GCC and Clang available there are pretty ancient by now. One can always install more recent versions of compilers from some selected external sources, but that must go through a process of whitelisting, which unfortunately takes much too long sometimes.

I think that is why CI cannot be the only method of testing libraries. While I find Travis CI useful the fact that CI services may be well behind the curve as far as the latest testing environments means that local testing is still very important. This is especially true for C++11 on up implementations which may well need the latest versions of compilers to certify that their use of the latest features of C++ work correctly. Even if someone were to write a C++ library which needs only basic C++03 compliance to work properly I think he would still want to promote the library as working on the latest versions of popular compilers ( gcc, clang, VC++ ) rather than much older releases.

[1]: https://github.com/brunocodutra/metal/blob/master/.travis.yml#L83 [2]: https://github.com/travis-ci/apt-source-whitelist/issues/300 [3]: https://travis-ci.org/brunocodutra/metal/jobs/166841250#L563