Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-11-13 18:06:38

On 11/13/2016 11:40 AM, Bruno Dutra wrote:
> 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?

I think it would be better to list all the versions that you have tested 
and which you know are working properly. I don't mind minimum versions 
but I did not understand from it that you are implying that all later 
versions have been tested and should work with Metal.

>
> [1]: http://brunocodutra.github.io/metal/#status
>
> Regards,
> Bruno