[Dune] [Dune-Commit] dune-common r6877 - trunk/dune/common

[Martin Nolte]

Hi all,

semantically I think that changing the default constructor of the MultiIndex 
is the right way to go. We just have to make sure that it is never actually 
called with its old semantics.

On the other hand, I do think that every useful field type must be 
initializable by an integer (with its natural meaning). If 
std::complex<double> causes problems, here, then I'd like to know about this 
issue.

Finally, I am entirely sure about the default constructor. As far as I 
understand the language, the following two lines should be semantically 
identical (at least for non-built-in types):
double result;
double result = double();
But I think gcc would warn about an uninitialized variable in the first case, 
while in the second case it would initialize the variable to zero. Even if the 
standard clearly specifies this behavior, I am not sure whether we can trust 
all compilers on this.

My last point is slightly off-topic and is only abount FieldVector<K,1>. As 
far as I understand things, this object is supposted to behave like a scalar. 
Apart from the meaning of operator* (which is hopefully sorted out by now), 
the assumptions on the default constructor now force the FieldVector to 
initialize to zero (at least for SIZE=1). If I remember correctly, gcc does 
not initialize doubles to zero unless the default constructor is explicitly 
called (see above), which cannot be done for arrays.

In conclusion, I do favor initialization from an integer over the default 
constructor. However, Andreas mentioning the class Zero, another idea crossed 
my mind: Why not have a global variable zero (similar to nullptr). 
Implementing suitable cast operators, we could require each "vector" to be 
initializable to zero, e.g.,

FieldVector<double,3> v( zero );

Using this construction, we could eliminate the constructor taking an int from 
the FieldVector, which is (in my opinion) only useful for the initialization 
to zero.

One last thing: Maybe we should continue this discussion on the FlySpray.

Best,

Martin









On 07/31/2012 02:56 PM, Matthias Wohlmuth wrote:
> I don't like the int-constructor patch either, as sometimes the
> int-->complex<double> casts cause me trouble. That was the main reason to
> implement it stl-like in the original dotproduct patch:
>
> PromotedType result = PromotedType();
>
> My problem was, that I was not aware of further classes like MultiIndex which
> derive from some vectors. So I didn't test MultiIndex. Are we sure, that there
> are no further classes (like MultiIndex) which do not initialize to 0?
>
> IMHO, the main advantage of the last patch is, that it restores the behavior
> of the old operator* (befor the dotproduct patches)...
>
> Cheers,
> Matthias
>
>
> Am 07/31/2012 02:48 PM, schrieb Markus Blatt:
>> Hi Andreas,
>>
>> On Tue, Jul 31, 2012 at 12:19:06PM +0000, Dedner, Andreas wrote:
>>> Just yesterday I had a look at this and the MultiIndex can be initialized
>>> with zero
>>> apparently without breaking anything. So I assume that we can change that
>>> behavior.
>>> I wanted to discuss this with Martin and then commit it but Christian had
>>> then already
>>> make the change with the int constructor - but I was also wondering about
>>> that int constructor...
>>> So w.r.t. to MultiIndex the change is probably not required....
>>>
>> Sounds great. So once you sorted this out with Martin and changed the
>> MultiIndex behaviour I would propose to revert Christians patches to
>> common and istl. (Your other option with a Zero class would be fine,
>> too. But the less additional code needed the better.)
>>
>>
>> Cheers,
>>
>> Markus
>>
>
>

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany