Hi, I'm using boost::logic::tribool for expressing logical flags that may be nulls by their nature (patient not asked, he/she doesn't know etc.). Default initialization to 'false' seems to be quite unnatural in this context and initialization to 'undetermined' seems to be prefered. Is any significant reason for boost::logic::tribool default constructor initializing the value to 'false'? TIA -- Serge
On Jun 29, 2005, at 2:24 AM, Serge Skorokhodov wrote:
Hi, I'm using boost::logic::tribool for expressing logical flags that may be nulls by their nature (patient not asked, he/she doesn't know etc.). Default initialization to 'false' seems to be quite unnatural in this context and initialization to 'undetermined' seems to be prefered. Is any significant reason for boost::logic::tribool default constructor initializing the value to 'false'?
Because default-constructing a bool gives a false value, and tribool tries to mimick bool as well as possible. Doug
Douglas Gregor wrote:
On Jun 29, 2005, at 2:24 AM, Serge Skorokhodov wrote:
Hi, I'm using boost::logic::tribool for expressing logical flags that may be nulls by their nature (patient not asked, he/she doesn't know etc.). Default initialization to 'false' seems to be quite unnatural in this context and initialization to 'undetermined' seems to be prefered. Is any significant reason for boost::logic::tribool default constructor initializing the value to 'false'?
Because default-constructing a bool gives a false value, and tribool tries to mimick bool as well as possible.
So there is no reason to prevent customization? Because an uninitialized value should be unknown from the domain point of view (at least in the domain I'm currently work in:) -- Serge
Serge Skorokhodov wrote:
So there is no reason to prevent customization? Because an uninitialized value should be unknown from the domain point of view (at least in the domain I'm currently work in:)
IIRC, there was a discussion of this during the development of tribool. Both the name and the purpose of the third state vary according to application. It could mean "not determined yet," or "we have found that it can never be determined," or possibly some others, depending on your understanding of the language. Your application must want the "not determined yet" meaning, which makes sense for the default value. Other meanings could choose any of the 3 states as the default value. If it makes sense for the rest of tribool's behavior, perhaps there is a way to make the default constructor value configurable, just as the name of the third state is configurable. At least, someone might like to add a rationale discussion in the docs, in order to lay the issue to rest. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
"Douglas Gregor" wrote:
Default initialization to 'false' seems to be quite unnatural in this context and initialization to 'undetermined' seems to be prefered. Is any significant reason for boost::logic::tribool default constructor initializing the value to 'false'?
Because default-constructing a bool gives a false value, and tribool tries to mimick bool as well as possible.
During review you agreed to make undeterminate as default value: http://lists.boost.org/boost/2004/06/6499.php What was the reason not to implement this? /Pavel
Pavel Vozenilek wrote:
"Douglas Gregor" wrote:
Default initialization to 'false' seems to be quite unnatural in this context and initialization to 'undetermined' seems to be prefered. Is any significant reason for boost::logic::tribool default constructor initializing the value to 'false'?
Because default-constructing a bool gives a false value, and tribool tries to mimick bool as well as possible.
During review you agreed to make undeterminate as default value: http://lists.boost.org/boost/2004/06/6499.php
What was the reason not to implement this?
/Pavel
The OP actually wanted 'uninitialised' semantics. If tribool offered uninit semantics, then yes, I agree that uninit should be the default. However, 'uninitialised' isn't the same as 'unknown'. For example, for 'unknown' semantics, (false == unknown) should evaluate to unknown. However, for 'uninitialised' semantics, (false == uninit) should evaluate to false, because the left operand *has* been initialised. I also want uninitialised semantics, so tribool isn't much use to me. For 'unknown' semantics (ie. tribool), should the default be false, true, or unknown? IMO, false. My preference would be to see tribool extended to 4-value (at least) logic (U,0,1,X), with U/uninitialsed as the default.
Hi,
Default initialization to 'false' seems to be quite unnatural in this context and initialization to 'undetermined' seems to be prefered. Is any significant reason for boost::logic::tribool default constructor initializing the value to 'false'?
Because default-constructing a bool gives a false value, and tribool tries to mimick bool as well as possible.
During review you agreed to make undeterminate as default value: http://lists.boost.org/boost/2004/06/6499.php
What was the reason not to implement this?
The OP actually wanted 'uninitialised' semantics. If tribool offered uninit semantics, then yes, I agree that uninit should be the default. However, 'uninitialised' isn't the same as 'unknown'. For example, for 'unknown' semantics, (false == unknown) should evaluate to unknown. However, for 'uninitialised' semantics, (false == uninit) should evaluate to false, because the left operand *has* been initialised.
I also want uninitialised semantics, so tribool isn't much use to me.
For 'unknown' semantics (ie. tribool), should the default be false, true, or unknown? IMO, false.
My preference would be to see tribool extended to 4-value (at least) logic (U,0,1,X), with U/uninitialsed as the default.
Still, why do not make it user configurable? Now I (and some others of course:) have to write a wrapper to use tribool for my purposes and (if undetermined were the default) somebody else will need the same. I don't believe that it is possible to satisfy everybody adding "null flavors". -- Serge
On Aug 5, 2005, at 7:26 AM, Serge Skorokhodov wrote:
Still, why do not make it user configurable? Now I (and some others of course:) have to write a wrapper to use tribool for my purposes and (if undetermined were the default) somebody else will need the same. I don't believe that it is possible to satisfy everybody adding "null flavors".
How would you make it configurable? Macros? A static "tribool" value somewhere that is used for initialization? Doug
Hi,
Still, why do not make it user configurable? Now I (and some others of course:) have to write a wrapper to use tribool for my purposes and (if undetermined were the default) somebody else will need the same. I don't believe that it is possible to satisfy everybody adding "null flavors".
How would you make it configurable? Macros? A static "tribool" value somewhere that is used for initialization?
Well, I agree that it can get rather ugly...:) Just for example:
class indetermined_uninitialized{};
class indetermined_value_not_possible{};
class indetermined_something_else_i_cannot_think_of_right_now{};
template <class flawor>
tribool { ... };
typedef tribool
Doug Gregor wrote:
On Aug 5, 2005, at 7:26 AM, Serge Skorokhodov wrote:
Still, why do not make it user configurable? Now I (and some others of course:) have to write a wrapper to use tribool for my purposes and (if undetermined were the default) somebody else will need the same. I don't believe that it is possible to satisfy everybody adding "null flavors".
How would you make it configurable? Macros? A static "tribool" value somewhere that is used for initialization?
Just some follow-up explaining why I need tribool with 'unknown' indetermined state sematics: I'm working in a domain (HL7 v3) that explicetely contain a type of boolean value that can be null (of several null flawors: just unknown, patient not asked, patient asked but does not know... etc.) -- Serge
Serge Skorokhodov wrote:
Just some follow-up explaining why I need tribool with 'unknown' indetermined state sematics:
I'm working in a domain (HL7 v3) that explicetely contain a type of boolean value that can be null (of several null flawors: just unknown, patient not asked, patient asked but does not know... etc.)
Pentabool, then? Or maybe you should just define an enumerated type for this specialised need. I don't think it's possible to define generally useful semantics for nulls, given the variety of uses they are put to. Ben.
Hi,
Just some follow-up explaining why I need tribool with 'unknown' indetermined state sematics:
I'm working in a domain (HL7 v3) that explicetely contain a type of boolean value that can be null (of several null flawors: just unknown, patient not asked, patient asked but does not know... etc.)
Pentabool, then? Or maybe you should just define an enumerated type for this specialised need. I don't think it's possible to define generally useful semantics for nulls, given the variety of uses they are put to.
Sure you're right! I use just an enum. But tribool with 'being_null' initial state was very convinient though;) -- Serge
I've had delivery turned off for the last month, so this probably won't thread correctly... This is similar to the issue of modelling logic in hardware description languages. Verilog, for example, has a 4-value type which is pretty much identical to tribool, except that it adds an additional 'tristate' value. Some objects default unknown, some tristate. VHDL has a more comprehensive (user-defined) 9-value logic type, which defaults to uninitialised. Logic on this type is fairly complex, but it includes both the obvious uninit and unknown semantics, and objects default to uninitialised. Having something like this as a tribool extension would be *very* useful. At a minimum, a usable type should have 4 values (U,0,1,X for uninit,0,1,unknown) and should default to U. Maybe I'll get around to this one day... :) Paul
participants (7)
-
Ben Hutchings -
Doug Gregor -
Douglas Gregor -
Paul Johnson -
Pavel Vozenilek -
Richard Hadsell -
Serge Skorokhodov