[Dune] Default constructor in MultiLinearGeometry

[Martin Nolte]

Hi Oli,

the long compile time is due to the reference elements. In my branch it compiles 
within less than 30s. Let's discuss the reference element stuff, so that compile 
time goes down (for all of us); even though this means less time for fetching 
coffee ;-).

Best,

Martin

On 10/14/2012 03:33 PM, Oliver Sander wrote:
> Hi,
>
>> of gcc, if I remember correctly). To fill an std::vector with a default
>> value, you can always use
>>
>> const T default( your default arguments here );
>> std::vector< T > myVector( size, default );
>>
>
> I tried that and it seems compile.
> ['Seems to' because compiling test-multilineargeometry with an additional
> line std::vector< T > myVector( size, default ); made my compiler run
> longer than I was willing to wait, and using all my 4GB :-) ]
>
> Best,
> Oliver
>
> PS: Let's not discuss this in FlySpray -- I don't think anyone but us three
> is interested. I retire my wish for a default constructor. Christian,
> what do you say?
>
>> If you fill the vector linearly, you can even use
>>
>> std::vector< T > myVector;
>> myVector.reserve( size );
>> for( std::size_t i = 0; i < size; ++i )
>> myVector.push_back( T( arguments for element i ) );
>>
>> Anyway, attached you first version of a possible patch to allow
>> uninitialized MultiLinearGeometry objects. I have not tested anything,
>> it just shows what this could basically look like.
>>
>> Best,
>>
>> Martin
>>
>>
>> On 10/14/2012 11:32 AM, Christian Engwer wrote:
>>> Hi Martin,
>>>
>>>> Apart from this, my feeling is that uninitialized objects are a very
>>>> bad thing. Especially unexperienced programmers will have a hard
>>>> time finding bugs caused by this. A default constructor would, of
>>>> course, create an "uninitialized" geometry (in the sense that you
>>>> may not use it at all).
>>>
>>> while I agree, that RAII is a good idea, default constructors aren't a
>>> bad thing in general. For example you won't be able to store objects
>>> in a std::vector, unless they have a default constructor. This is due
>>> to std::vectors' memory management, which tries to avoid
>>> reallocations.
>>>
>>> So I think a defaults constructor would be helpful. E.g. in dune-udg
>>> we construct a set of entity-parts (geometries + something) between a
>>> grid entity and a levelset. These entity-parts are stored (on demand,
>>> for a single intersection) in an std::vector -- we are doing nearly
>>> the same as return a copy on the fly, but we have to return a set and
>>> thus need std::vector. A default constructor would allow us to switch
>>> to MultiLinearGeometry, allowing faster computations.
>>>
>>> In case the corner storage does not allow default-construction, we
>>> still get a useful error message.
>>>
>>> Cheers
>>> Christian
>>>
>>
>>
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune

-- 
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