Subject: Re: [ublas] Why is there no constructor taking an initial value?
From: Karl Meerbergen (karl.meerbergen_at_[hidden])
Date: 2009-01-26 02:51:16
Thorsten Ottosen wrote:
> Karl Meerbergen skrev:
>> Thorsten Ottosen wrote:
>>> Gunter Winkler skrev:
>>>> Am Donnerstag, 22. Januar 2009 16:13 schrieb Thorsten Ottosen:
>>>>> I was a bit surprised that there is no way to fill a
>>>>> triangular_matrix with a default value. Say, I would have expected
>>>>> this to work:
>>>>> triangular_matrix<double> m(42,42,42);
>>>>> Is there any reason why this constructor is not provided?
>>>> because it is not needed:
>>>> // untested
>>>> triangular_matrix<double,lower> m((
>>> Right. I do something similar to get a zero matrix. But that syntax
>>> is *so* verbose. Normal STL containers has this type of constructor,
>>> and so users expect it to be provided.
>> I think a special constructor is not needed.
> This is not a question about if it is needed. Clearly you can
> initalize your matrix objects, it's just somewhat inelegant.
>> It is not because STL containers have such constructors that other
>> packages should follow the same ideas.
> It's one of boost's hallmarks, that we try to make as much as possible
> similar to the STL. It's much easier to learn new libraries that way.
Fine. Following your reasoning, we should have functions such as
norm_2( v.begin(), v.end() )
dot (v.begin(), v.end(), w.begin() )
This would be even more consistent with STL.
> Any newbie would expect that constructor to exist, and so does more
> experienced developers. I took me some time to look through the docs
> to find the function, and to look into the code. Other people will go
> through the same steps and loose time that could be better spend
>> I would suggest a function fill(a, value) which is much clearer than
>> a constructor with three arguments.
> A constructor with three aguments is pretty clear IMO.
> For vectors, it would of course be a constructor with two arguments.
Would you add an additional argument to the constructors of
vector_range, matrix_range etc... ?
I do not think
vector<double> v( 5, 0 );
is more elegant (or easier to understand) than
vector<double> v(5) ;
fill( v, 0 ) ;
Personally, I do not object strongly against such constructors, but I
think it only adds confusion.