Re: [boost] uBLAS formal review

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-06-28 00:20:26

----- Original Message -----
From: "Fernando Cacciola" <fcacciola_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, June 28, 2002 1:15 AM
Subject: Re: [boost] uBLAS formal review

[snip]

> > > ) Why does the default ctors for bounded_array<> et. al. dynamically
> > > allocate an empty array (of size 0)?
> >
> > Why shouldn't they?
> >
> Because that array is never used? Isn't it significantly faster to
> initialize data_ with NULL? Or is there a way that the array is used as is
> instead of reallocated?

No, you are right. Will be changed.

> > > ) Why does the destructor of bounded_array<> et. al throw bad_alloc()
if
> > > data_ has not been allocated? Destructors should not throw exceptions,
> and
> > > even this one in particular seems highly unnecesary.
> >
> > Bad behaviour due to MSVC education.
> >
> > > ) Why do all dynamic allocations via 'new' are followed by 'if
(!data_)
> > > throw std::bad_alloc'? "new" already throws bad_alloc if memory is
> > exausted.
> >
> > Not under MSVC.
> >
> Hmmm... which version?

6.0, sorry.

> In the worst case, new and delete should be overloaded for MSVC to do what
> they are supposed to do. But the BLAS code should not be affected.

Should we introduce MSVC's _set_new_handler?

> > > ) I highly dislike the names 'insert' and 'erase' here. They DO NOT
> insert
> > > or delete elements, they just set and reset the values of the already
> > > allocated elements. I'd prefer 'set' and 'reset'.
> >
> > But they insert and erase in the sparse case and they are used
generically
> > (without partial specialization again due to MSVC).
> >
> OK. If they conceptually insert and erase in some cases that's fine.
>
> > > ) both arrays could (should?) use valarray<> internally instead of
> > explicit
> > > heap allocated arrays. The difference would be significant because the
> > calls
> > > to std::copy could be replaced by valarray specific and usually
> optimized
> > > functions.
> >
> > Could, but shouldn't.
>
> Hmmm. I think this would have to be disucussed a bit more.
> Not using valarray<> prevents fast 'memcpy' optimizations... perhaps,
ublas
> could apply that optimization itself.

We recently discussed on the list, how to use valarray<> as an alternative
storage container using array_adaptor<>. Our arrays are primarily intended
to check for the effects of platform specific implementation's of the
standard library.

Regards

Joerg