Re: [boost] Re: Boost Array Initialization Technique

From: Jonathan Wakely (cow_at_[hidden])
Date: 2005-06-01 12:36:08

On Wed, Jun 01, 2005 at 01:07:25PM -0400, christopher diggins wrote:

> ----- Original Message ----- 
> From: "David Abrahams" <dave_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Wednesday, June 01, 2005 12:13 PM
> Subject: [boost] Re: Boost Array Initialization Technique
> 
> 
> >christopher diggins <cdiggins_at_[hidden]> writes:
> >
> >>----- Original Message ----- 
> >>From: "Neal Becker" <ndbecker2_at_[hidden]>
> >
> >>>I strongly disagree.  Forcing initialization makes code that is not 
> >>>useful
> >>>for high performance numerical processing.  When we declare a container 
> >>>of
> >>>1000000 elements, we don't want to waste time initializing each, unless 
> >>>we
> >>>want to.
> >>
> >>
> >>I think the best solution in this case is to use an alternative 
> >>"collection"
> >>for numerical processing. Using a class intended as general purpose array
> >>for numerical processing I think would not be a good idea.
> >
> >...because...?
> 
> 
> I stated that far too strongly, sorry. My reasoning is that the 
> implementation and interface of a numerical array could be optimized versus 
> a general array. I would not design numerical arrays and general purpose 
> arrays in the same way. For instance I would design a general purpose array 
> to be default initialized, while I would permit a numerical array to be 
> non-initialized. However, this is all moot because it is now perfectly 
> clear to me that Boost.Array has the mandate to be as much like a built-in 

Actually, it's moot because it's been semi-standardised in TR1, not
because you now understand the design goals ;)

> array as possible. Even if I do not particularly like that decision choice 
> it is of course an acceptable choice to make. Making it a pseudo-container 
> on the other hand is in my opinion a very big mistake.

There are good reasons for that too, see the descriptions of
Stroustrup's c_array and Austern's block for the basics. It's useful.
Would you rather have an array type that cannot be used with STL-style
algorithms, because it doesn't provide iterators?

You've presented one argument against, namely that generic code that
requires models of the container concept will misbehave when given a
type that doesn't model the container concept.  That's a simple
violation of preconditions - which can be statically enforced with
concept checks.

jon

-- 
"Simplicity is prerequisite for reliability."
	- Edsger Dijkstra