eval is definitely not more efficient. Quite the opposite, actually. When you take Function.prototype.apply into count, there's very few uses of eval where there is not a better, more efficient solution.
Well, let's give you a feature comparison:
Numerical operators (unary positive +; unary negative -; binary subtraction -; binary multiplicative *, /, %):
Gives a floating point result for an entire string. E.g. "08"-0 returns the number 8; +"1e6" returns the number 1000000; while 1*'1d6' returns the number NaN.
Using the Number function:
Gives the same results as the numerical operators, but might be easier to understand when they occur in the code.
Using the Number constructor:
Gives a number object instead of a number primitive, but in all other aspects behaves like the Number function.
Using the parseFloat function:
Gives a floating point number for characters in the string up to the point where they may no longer be interpreted as floating point numbers. E.g. parseFloat("08") returns the number 8; parseFloat("1e6") returns the number 1000000; parseFloat("1d6") returns the number 1; parseFloat("0x1d6") returns the number 0 (Inconsistent, op7.5 returns 470); and parseFloat("d") returns the number NaN.
Using the parseInt function:
Tails: You may get NaN as a result from all ways of converting a string to a number, as you can see from my examples above. You can also get different interpretations of the number entered depending on the code you use. If you really want to assure yourself it's a number, you should use a regular expression to detect anything you don't want to allow in the string, and then use the isNaN function to test the result anyway.
Originally Posted by Basscyst
Way to break it down. Excellent. Thank you professor Liorean. Is that in the FAQ? It should be.
It's not in the FAQ, though question 7 is related. I think it might belong in there, if one formats it better. (a table-like formatting with each of the test strings, and the results of applying each of the methods on it, perhaps?)
I've tried to cut down on my posting in them in an effort to try to get others to post there, so instead of adding it myself I invite you to adapt it to the FAQ form and post it there. Something that goes for all other similar cases of FAQ-worthy replies, of course.
I wouldn't rely on that. You might get a NaN error (Not a number).
I do it all the time. But of course you have to be working with a number to start with. If you have any doubt that the string value will contain anything other than a numeric and you want a number, you should be validating anyway.
Sorry Liorean; I did not see your last post before responding.
I've tried to cut down on my posting in them in an effort to try to get others to post there, so instead of adding it myself I invite you to adapt it to the FAQ form and post it there. Something that goes for all other similar cases of FAQ-worthy replies, of course.[/
OK, will do. At work right now though, will put it in there this evening.
Helping to build a bigger box. - Adam Matthews