[Dune] Default constructor in MultiLinearGeometry

[Martin Nolte]

Hi Christian,

my knowledge of the stl is definitely limited. Why does a std::vector< T > 
require T to have a default constructor? As far as I understand, you only need a 
copy constructor (and an assignment operator in old version 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 );

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
>

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: multilineargeometry.patch
Type: text/x-patch
Size: 4380 bytes
Desc: not available
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20121014/bc960469/attachment.bin>