From: Dave Harris (brangdon_at_[hidden])
Date: 2005-06-05 12:10:53
cdiggins_at_[hidden] (christopher diggins) wrote (abridged):
> > 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.
I doubt we need a whole class. A special argument might do, to let us
boost::array<int,1000> b( boost::uninitialised );
boost::array<int,1000> b( boost::initialised );
The question for me is what the default should be. And in my view, the
default should be safe rather than fast.
---- For what it's worth, I think auto variables, std::complex and even std::vector should be the same: initialised by default but with uninitialised available as an option. And since this is now a language change, perhaps "boost::initialised" should be spelt "?" for brevity. int x; // x == 0. int y = ?; // y is uninitialised. int *px = new int; // *px == 0. int *py = new int( ? ) // *py is uninitialised. vector<int> vx( 100 ); // vx.front() is 0. vector<int> vy( 100, ? ); Vectors are complicated in that their elements currently need to be copyable. Either the standard needs to specify when they are copied, so that eg vy is OK as long as the vector is not resized; or else it could make initialisation implementation-defined in the ? case. Then on most platforms, vector<int> would not need initialisation but vector<double> would. User code would not be able to tell the difference. Basically, initialising with ? is telling the implementation that the user will always write to the variable before reading it. The implementation exploits that knowledge as best it can. -- Dave Harris, Nottingham, UK.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk