[Dune] Dune on Windows MinGW
Carsten Gräser
graeser at math.fu-berlin.de
Wed May 4 15:28:57 CEST 2011
Am 04.05.2011 15:01, schrieb Martin Nolte:
> Hi Jö,
>
> I don't have any problem with a static variable -- as long as it is really
> faster. If Carstens suggestion is correct, the static variable variant might
> be slower due to an additional if-condition whether the variable has already
> been initialized.
>
> With respect to the specialization: You are right in that this is possible. On
> the other hand, your approach allows asking for MC< int >::e, which might give
> a pretty stupid error message. Such points are exactly what needs discussion.
>
> But I think there are more important points to be discussed: The names, static
> methods vs. static variables. These have an impact on code actually asking for
> these values. For example, I guess we want to change the use of Pi in the DGF
> parser (and the other places indicated by Bernd) soon. It would be great, if
> we agreed on an interface before these changes.
>
> You are, of course, right that templatized variables generate weak symbols --
> I indeed overlooked this. Does anyone know why numeric_limits uses static
> methods over static member variables? For me, this was the inspiration to
> suggest static methods.
I'd prefer the static methods. For other types where the compiler does
not optimize the call one could still use a static local member.
Carsten
PS:
You can check the optimization yourself with the attached example.
>
> Best,
>
> Martin
>
> On 05/04/2011 01:31 PM, Jö Fahlke wrote:
>> Am Wed, 4. May 2011, 12:46:38 +0200 schrieb Martin Nolte:
>>> Ok, I just added a first implementation of such a class to dune-common.
>>> Improvements are, of course, welcome. I also think that naming can still be
>>> discussed.
>>>
>>> The idea of the file math.hh is to have a "replacement" for the include of
>>> <cmath>, which is included by math.hh. Any objections, suggestions, etc.?
>>
>> Yes. Instead of
>>
>> static double e () { return std::exp( 1.0 ); }
>>
>> use
>>
>> static const double &e () {
>> static const double val = std::exp( 1.0 );
>> return val;
>> }
>>
>> This should should also avoid recomputation of the value on every call.
>>
>> Also, I don't see why this has to be specialized for every data type. One
>> templated class should be good for most if not all relevant types. Or are
>> there no overloads of std::exp() and std::acos() for GMPField? Even so, at
>> least long double would benefit from a general template, and it would make
>> maintanance easier.
>>
>> Thanks,
>> Jö.
>>
>
--
----------------------------------------------------------------------
Carsten Gräser | phone: +49-30 / 838-75349
Freie Universität Berlin | fax : +49-30 / 838-54977
Institut für Mathematik | email: graeser at math.fu-berlin.de
Arnimallee 6 |
14195 Berlin, Germany | URL : http://page.mi.fu-berlin.de/graeser
----------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compile_time_expressions.cc
Type: text/x-c++src
Size: 952 bytes
Desc: not available
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20110504/4ff664f7/attachment.cc>
More information about the Dune
mailing list