<p>I have values stored as strings in a <code>DataTable</code> where each value could really represent an <code>int</code>, <code>double</code>, or <code>string</code> (they were all converted to strings during an import process from an external data source). I need to test and see what type each value really is.</p>

<p>What is more efficient for the application (or is there no practical difference)?</p>

<ol>
<li>Try to convert to <code>int</code> (and then <code>double</code>). If conversion works, the return <code>true</code>. If an exception is thrown, return <code>false</code>.</li>
<li>Regular expressions designed to match the pattern of an <code>int</code> or <code>double</code></li>
<li>Some other method?</li>
</ol>

[{'answer_id': 2001, 'author': 'gil', 'author_id': 195, 'author_profile': 'https://Stackoverflow.com/users/195', 'pm_score': 4, 'selected': True, 'text': '<p>Would use double.TryParse, it has performance benefits.</p>\n'}, {'answer_id': 2005, 'author': 'Matt Dawdy', 'author_id': 232, 'author_profile': 'https://Stackoverflow.com/users/232', 'pm_score': 2, 'selected': False, 'text': "<p>I'd personally use int.tryparse, then double.tryparse.  Performance on those methods is quite fast.  They both return a Boolean.  If both fail then you have a string, per how you defined your data.</p>\n"}, {'answer_id': 2009, 'author': 'Mike Stone', 'author_id': 122, 'author_profile': 'https://Stackoverflow.com/users/122', 'pm_score': 3, 'selected': False, 'text': "<p>I would say, don't worry so much about such micro performance.  It is much better to just get something to work, and then make it as clear and concise and easy to read as possible.  The worst thing you can do is sacrifice readability for an insignificant amount of performance.</p>\n\n<p>In the end, the best way to deal with performance issues is to save them for when you have data that indicates there is an actual performance problem... otherwise you will spend a lot of time micro-optimizing and actually cause higher maintenance costs for later on.</p>\n\n<p>If you find this parsing situation is really the bottleneck in your application, THEN is the time to try and figure out what the fastest way to solve the problem is.  I think Jeff (and many others) have blogged about this sort of thing a lot.</p>\n"}, {'answer_id': 7257, 'author': 'Keith', 'author_id': 905, 'author_profile': 'https://Stackoverflow.com/users/905', 'pm_score': 3, 'selected': False, 'text': "<p>You'll get different results for the different methods depending on whether you compile with optimisations on. You basically have a few options:</p>\n\n<pre><code>object o;\n\n//checking with is\no is int\n\n//check type\no.GetType() != typeof( int )\n\n//cast and catch exception\ntry{ int j = (int) o; } \ncatch {}\n\n//use the tryparse\nint.TryParse( Convert.ToString( o ), out j )\n</code></pre>\n\n<p>You can easily set up a console app that tries each of these 10,000 times and returns durations for each (test when o is an int and when it's something else).</p>\n\n<p>The <code>try-catch</code> method is the quickest if the object does hold an int, and by far the slowest if it doesn't (even slower than <code>GetType</code>).  <code>int.TryParse</code> is pretty quick if you have a string, but if you have an unknown object it's slower.</p>\n\n<p>Interestingly, with .Net 3.5 and optimisations turned on the <code>o is int</code> check takes the same time as <code>try-catch</code> when o actually is an int. <code>o is int</code> is only slightly slower if o actually is something else.</p>\n\n<p>Annoyingly FxCop will throw up warnings if you do something like:</p>\n\n<pre><code>if( o is int )\n    int j = (int) o;\n</code></pre>\n\n<p>But I think that's a bug in FxCop - it doesn't know int is a value type and recommends you to use <code>o as int</code> instead.</p>\n\n<p>If your input is always a string <code>int.TryParse</code> is best, otherwise the <code>is</code> operator is quickest.</p>\n\n<p>As you have a string I'd look at whether you need to know that it's an int, rather than a double.  If <code>int.TryParse</code> passes then so will <code>double.TryParse</code> so you could half the number of checks - return either double or string and floor the doubles when you expect an int.</p>\n"}, {'answer_id': 124065, 'author': 'gods gift', 'author_id': 21214, 'author_profile': 'https://Stackoverflow.com/users/21214', 'pm_score': 3, 'selected': False, 'text': '<p>The trouble you have is that there could be situations where the answer could be all three types.</p>\n\n<p>3 could be an int, a double or a string!</p>\n\n<p>It depends upon what you are trying to do and how important it is that they are a particular type. It might be best just to leave them as they are as long as you can or, alternatively, some up with a method to mark each one (if you have control of the source of the original string).</p>\n'}]
['https://Stackoverflow.com/questions/1995', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/51/']