[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