[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