Re: [boost] Interest in Barton-Nackman's fallible<T>?

From: Paul A Bristow (pbristow_at_[hidden])
Date: 2006-07-10 12:11:55

|  -----Original Message-----
|  From: boost-bounces_at_[hidden] 
|  [mailto:boost-bounces_at_[hidden]] On Behalf Of Gennaro Prota
|  Sent: 10 July 2006 16:05
|  To: boost_at_[hidden]
|  Subject: Re: [boost] Interest in Barton-Nackman's fallible<T>?
|  
|  On Mon, 10 Jul 2006 14:23:39 +0100, "Paul A Bristow"
|  <pbristow_at_[hidden]> wrote:
|  
|  >Although the fallible concept obviously can work, I see a 
|  key disadvantage
|  >for big arrays of data is the need for an extra byte to 
|  hold the valid bit.
|  >And after packing and/or loss of alignment, it could be a 
|  LOT worse -
|  >perhaps doubling the storage required. 
|  
|  This discussion hasn't even begun and I'm already tired. Can you give
|  an example of what you are thinking to?

If you have an array of 'fallible' data (measurements say), not all of which
are valid,
you can use doubles for the data, but you need an extra byte for each value
to
hold the valid/not valid bit - a bool in a byte, or more perhaps.

If you manage to persuade the compiler to pack the doubles and bytes
together,
the double won't be on speed-friendly boundaries,

or if you don't/can't pack each byte, the bool may end up taking as much
space as the double.

So for a few items, fallible is fine, but for hundreds and up, has a
downside.

A NaN by contrast is neatly stored in the double, and costs nothing extra,
and MAY be used to indicate 'fallibility'.

But don't let this make you too tired to continue - there are other cases
when fallible may be very useful.

Paul

---
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone] & SMS, Mobile [phone] & SMS
pbristow_at_[hidden]