Interest in Barton-Nackman's fallible<T>?

Hi guys, I don't know how and how much boost:optional<> overlaps with this (last time I checked it was different, but I know there's a proposal in which the template has been changed), anyway: is there interest for a Barton-Nackman's fallible<T> template? Basically the idea is (warning: not compiled): #include <assert.h> template<typename T> class fallible { public : fallible(); explicit fallible(const T & value); bool is_valid() const; const T& value() const; operator T() const; const T& else_default_to(const T& default_value) const; void invalidate(); void validate(const T& value); // alternative to operator= private : T m_value; bool m_valid; }; template<typename T> fallible<T>::fallible() : m_valid(false) { } template<typename T> fallible<T>::fallible( const T& v ) : m_value(v), m_valid(true) { } template<typename T> bool fallible<T>::is_valid() const { return m_valid; } template<typename T> const T& fallible<T>::value() const { assert(m_valid); // <--- return m_value; } template<typename T> fallible<T>::operator T() const { return value(); } template<typename T> const T& fallible<T>::else_default_to(const T& default_value) const { return is_valid() ? static_cast<const T&>(value()) : static_cast<const T&>(default_value); } template<typename T> void fallible<T>::invalidate() { m_valid = false; } template <typename T> void fallible<T>::validate(const T& value) { m_value = value; m_valid = true; } -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

Hello, Gennaro Prota schrieb:
I don't know how and how much boost:optional<> overlaps with this
[...]
T m_value;
That means that T needs to be default-constructible, which for more complex types T means that T needs to be capable of knowing whether it is in an uninitialized state, which kind of makes this class pretty pointless. Simon

On Mon, 10 Jul 2006 14:50:20 +0200, Simon Richter <Simon.Richter@hogyros.de> wrote:
T m_value;
That means that T needs to be default-constructible, which for more complex types T means that T needs to be capable of knowing whether it is in an uninitialized state, which kind of makes this class pretty pointless.
Care to submit an example before being so categorical? -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

There is some overlap in function between this and the floating-point NaN(s). A way of representing 'missing values' is a very common requirement for numerical data in the sciences from physics to sociology. The potential value of this has been discussed, especially noting the need for way of inputting and outputing for serialization, for one important example, and I have made a proposal (of sorts) in http://www2.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2022.pdf Input and output of NaN and infinity. Without this, NaN (and infinity) is much less useful than it could be. 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. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennaro Prota | Sent: 10 July 2006 13:34 | To: boost@lists.boost.org | Subject: [boost] Interest in Barton-Nackman's fallible<T>? | | Hi guys, | | I don't know how and how much boost:optional<> overlaps with this | (last time I checked it was different, but I know there's a proposal | in which the template has been changed), anyway: is there | interest for | a Barton-Nackman's fallible<T> template? Basically the idea is | (warning: not compiled): | | #include <assert.h> | | template<typename T> | class fallible | { | public : | fallible(); | explicit fallible(const T & value); | | | bool is_valid() const; | | const T& value() const; | operator T() const; | | const T& else_default_to(const T& default_value) const; | | void invalidate(); | void validate(const T& value); // alternative to operator= | | private : | | T m_value; | bool m_valid; | | }; | | template<typename T> | fallible<T>::fallible() | : m_valid(false) | { | } | | | template<typename T> | fallible<T>::fallible( const T& v ) | : m_value(v), m_valid(true) | { | } | | template<typename T> | bool | fallible<T>::is_valid() const | { | return m_valid; | } | | template<typename T> | const T& | fallible<T>::value() const | { | assert(m_valid); // <--- | return m_value; | } | | template<typename T> | fallible<T>::operator T() const | { | return value(); | } | | template<typename T> | const T& | fallible<T>::else_default_to(const T& default_value) const | { | return is_valid() | ? static_cast<const T&>(value()) | : static_cast<const T&>(default_value); | } | | template<typename T> | void | fallible<T>::invalidate() | { | m_valid = false; | } | | template <typename T> | void | fallible<T>::validate(const T& value) | { | m_value = value; | m_valid = true; | } | | | -- | [ Gennaro Prota, C++ developer for hire ] | [ resume: available on request ] | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost |

On Mon, 10 Jul 2006 14:23:39 +0100, "Paul A Bristow" <pbristow@hetp.u-net.com> 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? -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Gennaro Prota | Sent: 10 July 2006 16:05 | To: boost@lists.boost.org | Subject: Re: [boost] Interest in Barton-Nackman's fallible<T>? | | On Mon, 10 Jul 2006 14:23:39 +0100, "Paul A Bristow" | <pbristow@hetp.u-net.com> 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 +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

Sorry for this late answer, I've just got back from vacation. Paul A Bristow wrote: [...]
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.
One solution to this problem is to supplement fallible<T> with a trait indicating whether an in-range invalid value is available and its value (an even more obvious example than NaN's is fallible<T *>). Cheers, Nicola Musatti

On Mon, 10 Jul 2006 17:04:31 +0200, Gennaro Prota <gennaro_prota@yahoo.com> wrote:
This discussion hasn't even begun and I'm already tired.
In retrospect I think I've to apologise for using such a tone. Sorry, it was a bad day. -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]
participants (4)
-
Gennaro Prota
-
Nicola Musatti
-
Paul A Bristow
-
Simon Richter