[Dune-devel] Replace Dune C++11 by plain C++11
Oliver Sander
sander at igpm.rwth-aachen.de
Wed Mar 12 21:33:50 CET 2014
>
> As to deprecating the imports: I don't think you can easily do that.
I was thinking to deprecate the entire files with a #warning. Did I miss something?
--
Oliver
Moreover, we are heading for 3.0, which "might contain non-backward compatible changes". IMHO we should just drop them (if so
> desired).
>
> Moving the compatiblity headers does not sound like a good idea to me, here. We would need to deprecate the old ones anyway.
>
> As to using std:: in the core modules: From my point of view, the import serves the purpose to easily use a fallback implementation in case the std:: variant is buggy (e.g., std::array on xlc).
> However, I agree that there is no need to support such compilers and a simple sed-command (combined with a find) will replace all std::array by Dune::array (or whatever name I would like to use).
>
> Personally, I do (maybe no longer) have an opinion on the matter. If the majority of interesed people think it is simpler to use std::array instead of the import Dune::array, then so be it.
>
> But: I do dislike reverting Christoph's work just for an extremely tiny bit of potential compatiblity (not to say out of pure spite). Therefore, I do have one request: Can we please either vote on the
> matter or allow Christoph to drop the imports without any further discussion?
>
> Best,
>
> Martin
>
> On 03/12/2014 11:07 AM, Oliver Sander wrote:
>> Am 12.03.2014 11:04, schrieb Christian Engwer:
>>> Hi Oli,
>>>
>>> I just checked again.
>>>
>>> a) with respect to static_Assert I was wrong and we actually decided
>>> to drop dune_static_assert completely.
>>> b) if we follow you suggestion
>>> > We cannot drop the namespace imports without deprecating them first.
>>> > But we can start using the std:: versions explicitly inside the
>>> > core modules, which is what Christoph did, IIRC.
>>> we basically revert the decision to have namespace import to ease the
>>> use of unsupported compilers. Which is something, where I don't have a
>>> strong opinion, besides we should stick to what we decided until we
>>> decided differently.
>>
>> I think it is a little bizarre to officially state a list of supported
>> compilers, and then jump through loops to (kind-of) support the unsupported
>> ones, too. But I don't have a strong opinion on this, either.
>> --
>> Oliver
>>
>>>
>>> Ciao
>>> Christian
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Dune-devel mailing list
>> Dune-devel at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 534 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20140312/68389577/attachment.sig>
More information about the Dune-devel
mailing list