[Dune] [#801] Int2Type vs. integral_constant

Dune flyspray at dune-project.org
Wed Aug 25 13:50:52 CEST 2010


THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#801 - Int2Type vs. integral_constant
User who did this - Jö Fahlke (joe)

----------
[ I'm on holiday currently, so don't expect quick responses for the next 3 ]
[ weeks                                                                    ]

I did look for a template with a behaviour like Int2Type in Dune before
introducing integral_constant -- apparently I didn't look hard enough, so
sorry for the confusion, I guess.

@Christi: it is used in PDELab, once in MultiTypeTree (which can be easily
replaced by Int2Type) and several times in WeightedSumLocalOperator
(weightedsum.hh) and InstationarySumLocalOperator (sum.hh).

@Robert: When introducing integral_constant, I did it the same way as Dune
already does for several other components from C++0x: if the compiler supports
C++0x (e.g. "g++ -std=c++0x") introduce the class provided by the compiler
into the Dune namespace by a "using" declaration, otherwise ("g++ -ansi")
implement it ourselves.

I have used integral_constant mostly for TMP: where I had an integral template
parameter, bu I needed to instanciate a template metaprogram with a type
template parameter.  As far as I can see, Martin has used Int2Type mostly for
differenciating different overloads of a function, probably because partial
specialization (or even total specialization) was impossible.  Martins code is
all over the place (generic geometries, generic reference elements,
albertagrid, parts of localfunctions).

If we want to migrate from Int2Type to integral_constant we have to take these
overloads into account.  As far as I can quickly see, the calls to the
overloaded functions always happen inside some set of cooperating classes and
are thus implementation details.  So it should be relatively uncomplicated to
migrate to integral_constant.  Of course it will still be tedious due to the
number of occurances of Int2Type.  And I suppose that Martin and possibly
others are using Int2Type in their private modules, but I can't say anything
about that.

Migrating back to Int2Type is relatively easy.  It would require doing boolean
operations with "int"s though, which makes it slightly ugly in my opinion.  In
the end I would possibly opt to copy the definition integral_constant to
PDELab instead.

The third possibility is to keep both Int2Type and integral_constant.  Since
both are really small classes this should not create too much overhead.  It
has the two benefits that we do have a standard-conforming integral_constant,
while at the same time we don't have to migrate existing code.

So I guess my list of favorite options is currently like this (most favorite
first):
1. keep both (best of both worlds)
2. remove integral_constant (removing Int2Type more trouble than it's worth)
3. deprecate Int2Type
My favours are not very strong though, I really can live with any of the three
options.

----------

More information can be found at the following URL:
http://www.dune-project.org/flyspray/index.php?do=details&task_id=801#comment2119

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.




More information about the Dune mailing list