On Wed, Jun 01, 2005 at 01:07:25PM -0400, christopher diggins wrote:
----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> To: <boost@lists.boost.org> Sent: Wednesday, June 01, 2005 12:13 PM Subject: [boost] Re: Boost Array Initialization Technique
christopher diggins <cdiggins@videotron.ca> writes:
----- Original Message ----- From: "Neal Becker" <ndbecker2@gmail.com>
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