[dune-functions] TypeTree now works with dune-functions again

[Steffen Müthing]

> Am 15.09.2015 um 21:08 schrieb Carsten Gräser <graeser at mi.fu-Berlin.de>:
> 
> 
> Am 15.09.2015 um 20:54 schrieb Oliver Sander:
>> Hi Steffen,
>> thanks for all the work.  Any simplifications to dune-typetree are
>> always much appreciated. :-)
>> 
>> Am 15.09.2015 um 17:54 schrieb Steffen Müthing:
>> 
>>> 
>>> I also really liked Carsten’s idea of having an index_constant that’s a template alias for an
>>> integral_constant<std::size_t,…>, so I put that into TypeTree and started to use it extensively. There’s
>>> also a standard-compliant reimplementation of the integer_range and index_range functionality in
>>> Dune::TypeTree::Std (BTW, it’s *really* bad that we have something not quite correct in Dune::Std).
>> Why can't we simply fix that?  We claim that stuff in Dune::Std is
>> standard-compliant, so what
>> you describe is a simple bug that should be fixed.  We may advertise
>> this beforehand to warn
>> people about the behavioral changes, but still... isn't this simply a
>> bug that needs fixing?
> No, we can't fix index_sequence in dune-common, because this
> requires C++11, namely template aliases. The standard says,
> that index_sequence<i> _is_ an interger_sequence<size_t,i>,
> not derived, convertible, or anything else. But this can't
> be achieved without template aliases.

Yes, that’s the problem right now. Whether we can fix the problem after 2.4 depends on what we decide regarding
compiler requirements at the developer meeting (template aliases are 4.7, but I sincerely hope we go beyond 4.7!).

> 
>>> The pre-made index objects now live in Dune::TypeTree::Indices (I thought the „Static“ was a little redundant).
>>> I really like the idea of those constants and would like to see them in dune-common after the release of 2.4.
>> Seconded -- then I could use them for MultiTypeBlockVector.
>> 
>> Nitpicking: wouldn't constant_index be a better name than index_constant?
>> (I won't even try to enforce 'standard Dune' camelCase with you :-) )
> My proposal 'index_constant' tried to stay in line with index_sequence
> that also specializes some static index thingy for size_t. But t´since
> it's not in the standard using IntergerConstant would also be fine.

index_constant was just lifted from Carsten. I actually thought it was for consistency with integral_constant,
and if the committee ever comes up with something similar (which I doubt, but you never know), I’m pretty sure
that they would pick index_constant for those consistency reasons. At the same time, it looks really similar to
std::integral_constant, which is good, because that’s what it is in the end...

But I’m not overly attached to the name, I really picked it because it seemed fitting for something so general purpose
C++ish that is very close to the standard.

Steffen

> 
> Carsten
> 
> 
> _______________________________________________
> dune-functions mailing list
> dune-functions at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-functions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20150915/662ecee8/attachment.sig>