Boost logo

Glas :

Re: [glas] unallocated fill

From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-10-03 07:37:27


Neal Becker wrote:

>On Monday 03 October 2005 7:56 am, Karl Meerbergen wrote:
>
>
>>Neal Becker wrote:
>>
>>
>>>On Monday 03 October 2005 3:19 am, Karl Meerbergen wrote:
>>>
>>>
>>>>On Friday 30 September 2005 20:22, Neal Becker wrote:
>>>>
>>>>
>>>>>Suggest adding to dense_vector.hpp:
>>>>> dense_vector(size_type size, value_type const& init)
>>>>>
>>>>> : size_( size )
>>>>>
>>>>> {
>>>>> begin_ = alloc_.allocate( size ) ;
>>>>> std::uninitialized_fill (begin(), end(), init);
>>>>>
>>>>> }
>>>>>_______________________________________________
>>>>>glas mailing list
>>>>>glas_at_[hidden]
>>>>>http://lists.boost.org/mailman/listinfo.cgi/glas
>>>>>
>>>>>
>>>>Hi Neal,
>>>>
>>>>Personally, I prefer a free function fill( v, init ) ;
>>>>Similarly, clear_values() and clear() also are free functions.
>>>>rather than a member function. I agree that some form of initialization
>>>>is quite useful.
>>>>
>>>>
>>>It is important to separate allocation and initialization for HPC. Here
>>>is what I believe. The default construction should not perform
>>>initialization. It looks to me that glas already follows this. If you
>>>want initialization, use the alternative constructor as I show above.
>>>
>>>
>>I agree about the point on separation of initialization and allocation.
>>This is indeed how GLAS now works.
>>
>>The only difference with your suggestion is not to provide an
>>initializing constructor, but use a free function. I prefer not to
>>overload the collections with constructors, if it is not really needed.
>>Is there a reason why you would prefer a constructor?
>>
>>
>>
>
>Thanks. The free function is fine. I suggested this because it is consistent
>with STL, so maybe more familiar.
>
>

Consistency with STL is a strong argument though. So, perhaps we should
consider it for a dense_vector. For a sparse_vector, it does not make
sense, I suppose.

To what extent do we want to be consistent with STL? I suppose the
answer is very personal.

Karl