Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk