tags:

views:

325

answers:

5

UPDATE: Question still unanswered. @Alastair_Pitts: Unless I'm missing something, it's a two part question. The second part, "If so, why is this done?" and not been answered.


Believe the question is clear, but if you have any questions -- just let me know. Thanks!

undefined = unknown and is a reference to system based on ternary logic.


Reference: http://en.wikipedia.org/wiki/Ternary_logic

+1  A: 

Not necessarily!

It depends on what you mean by "undefined". If you mean "uninitialized", then the answer is no.

In C or C++, assume there is a statement

int x;

in function scope. After the statement is executed, x is a legal integer variable, but it is not initialized. x can take any value. If it takes value 0, then it is false; for all other values (whose probability is much higher), it is true. However, at the end, it does not matter what value x actually acquires. From the program correctness standpoint, the it is "undefined behavior."

Though it is not provided by the language, it is also possible to implement a tri-state, e.g. true, false, unknown. See, for example, the tribool in Boost tribool.

ArunSaha
In C++, reading an uninitialized variable leads to undefined behavior. So there's no use pondering about what value you'll get i you read it.
GMan
To take GMan's comment a bit further, while it is true that `x` could be equal to `0` or could be equal to anything else, it is not meaningful to talk about the probability. It is allowed for all uninitialised values to actually be initialised to a fixed number (often done by debuggers), or it could be set in a way that is highly deterministic based on previous operations. But we can only meaningfully talk about this by looking at matters other than C++ itself, as far as C++ goes, it has nothing to say on the matter. Compliant compilers may leave the probability of `0` at 100%, 0% or anything.
Jon Hanna
@GMan and @Jon Hanna: Appreciate your comments. I mentioned that `x` is not initialized. And both of you are right that uninitialized variable may lead to undefined behavior. I also mentioned that, "If you mean "uninitialized", then the answer is no." I made some edits based on your comments. If you have more suggestions, on how can add or edit to improve the answer, I would love to hear your comments.
ArunSaha
+5  A: 

In many, if not most, languages values are either falsy, meaning that something doesn't exist or lacks value, or truthy, meaning that something exists or has value. The list of falsy values is usually: (these evaluate to false)

  1. 0 (zero, the number)
  2. '' (an empty string)
  3. null (if this value exists)
  4. undefined (if this value exists)
  5. false/False (if it has a boolean type)

Anything else is truthy and evaluates to true.

Edit: Made the answer a bit less biased towards JavaScript

indieinvader
this seems really really javascript-y
Nader Shirazie
Thats because it is (Professionally, I write A LOT of JavaScript so its rules come to mind first, generally) Python's rules are similar, though
indieinvader
**@indieinvader:** +1 Yes, your edit did make it more clear, and less JS biased. Thanks!
blunders
@indie, C#, C/C++, Java, Ruby, Lua, lisp, and many many languages do not evalute those values to false. You are completely wrong when you say "most" or even "many".
banister
The empty string one can swing so many ways depending on language. The others seem fair in the general senese.
Martin York
**@banister,@Martin_York:** Thanks for pointing out the conflicts in truthy/falsy eval difference between JavaScript and other languages.
blunders
For completeness's sake, there are some languages (*e.g.*, Haskell) where `True` is truthy, `False` is falsy, and everything else *isn't a boolean* and can't be used in conditionals. (Or it's the error value and you get an infinite loop/an exception.)
Antal S-Z
+2  A: 

I have only come across this with Javascript and when this occurs, the value is actually a string defined as 'undefined'

If you were to run a test on this:

if (someVar==true) {
document.write('True');
} else if (someVar==false) {
document.write('False');
} else {
document.write('Other');
}

It will output 'Other' as opposed to true or false - don't know if this helps...

dpmguise
Your first comment is not right (undefined is not a string, though if you cast it to a string, you will get the string `"undefined"`) but your second point is true for undefined *and* strings. This: `var x, y = "s"; alert(x == true || x == false); alert(y == true || y == false); alert(typeof x); alert(typeof y);` outputs false, false, undefined, string.
Douglas
+1  A: 

Depends what you mean with "equal to false". PHP specifically has two different operators. You could say value == false meaning that value is a scalar that evaluates to false, and value === false in that it is undefined.

Likewise, SQL has NULL, which is a special value that is not related to 0 (or FALSE).

C/C++ doesn't really have the concept of "undefined", only "uninitialized", in which case the variable exists, but its value is not defined and should not be read if you want your code to not suck.

In a scalar sense (i.e. IF you have something that holds a value), false is often defined as "0", and true as "non-zero", but that's not a standard across the board.

EboMike
In C++, reading an uninitialized variable leads to undefined behavior. (Which makes suckiest code.)
GMan
Exactly what I'm saying. Don't read uninitialized values if you don't want your code to suck.
EboMike
@EboMike: Sucky code isn't equivalent to having undefined behavior the former is an implication of the latter. :P (Having UB is a much stronger argument than saying it sucks.)
GMan
Depends on your threshold of suckiness :) But you're right, it should be spelled out to make sure there is no misunderstanding: Reading uninitialized values is undefined behavior and could result in unintended behavior across platforms or configurations, including crashes, incorrect results, you name it. It's actually one of the worst kinds of bugs - it's very common to have code that runs all nice and cool in a debug build and fails miserably in a release build. Have fun debugging that.
EboMike
+4  A: 

I think the answer is no, most languages do not consider "undefined" to be the same as false. Of course it's important to know the particulars of a language to understand how it handles true, false, NULL (or nil), etc.

You tagged this with Ruby, so here are some Ruby examples:

>> x # raises NameError: undefined local variable

>> x = nil # initializes x and assigns the value nil

>> x == true # false

>> x == false # false (in Ruby nil is not false, but see below)

>> x.nil? # true

>> x ? true : false # false -- Ruby treats nil values as false in conditions

>> x = 1 # now x has a value

>> x.nil? # false

>> x ? true : false # true

As to "why evaluate undefined as false", it can be handy when you need to know a variable is defined before you use it. For example in Ruby you often see this:

if x && x == "some interesting value"
  do_important_thing
end

If x is undefined, the first part of the condition returns false and the statement short-circuits. Which is much cleaner than:

if x.nil?
  if x == "some interesting value"
    do_important_thing
  end
end
zetetic
Douglas