Boost logo

Boost :

Subject: Re: [boost] [MPL] A Proposal
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-11-13 09:34:41

On 11/13/2016 7:22 AM, Bruno Dutra wrote:
> On Sun, Nov 13, 2016 at 6:47 AM, Edward Diener <eldiener_at_[hidden]>
> wrote:
>> On 11/12/2016 5:26 PM, Bruno Dutra wrote:
>>> On Mon, Feb 29, 2016 at 1:52 PM, Bruno Dutra <brunocodutra_at_[hidden]>
>>>> [snip]
>>>> 2016-02-29 6:37 GMT-03:00, Jens Weller <JensWeller_at_[hidden]>:
>>>>> [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]:
>>> [2]:
>> 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
> 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

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

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]:
> [2]:
> [3]:

Boost list run by bdawes at, gregod at, cpdaniel at, john at