Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2016-11-13 11:40:19

On Sun, Nov 13, 2016 at 3:34 PM, Edward Diener <eldiener_at_[hidden]>
wrote:

> 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]: 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.

Yes absolutely, in fact I use the development branches of these compilers
on my machine, while using Travis and Appveyor to check the minimum
required versions.

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.

I suppose you refer to the compatibility status table [1]? Do you think it
would be better not to mention the exact minimum versions that are tested
and known to work with Metal?

[1]: http://brunocodutra.github.io/metal/#status

Regards,
Bruno