A maioria maneira eficiente de testar o tipo de objeto

votos
17

I têm valores armazenados como cadeias em um DataTableonde cada valor poderia realmente representam um int, doubleou string(eles foram todos convertidos em cadeias durante um processo de importação de uma fonte de dados externa). Eu preciso testar e ver que tipo cada valor realmente é.

O que é mais eficiente para a aplicação (ou não há diferença prática)?

  1. Tentar converter para int(e depois double). Se as obras de conversão, o retorno true. Se uma exceção é lançada, o retorno false.
  2. As expressões regulares destinados a corresponder ao padrão de um intoudouble
  3. Algum outro método?
Publicado 05/08/2008 em 08:49
fonte usuário
Em outras línguas...                            


5 respostas

votos
9

Usaria Double.TryParse, tem benefícios de desempenho.

Respondeu 05/08/2008 em 08:54
fonte usuário

votos
6

Eu diria, não se preocupe tanto sobre tais micro desempenho. É muito melhor, é só pegar algo para trabalhar, e, em seguida, torná-lo mais claro e conciso e fácil de ler quanto possível. A pior coisa que você pode fazer é a legibilidade sacrifício por uma quantia insignificante de desempenho.

No final, a melhor maneira de lidar com problemas de desempenho é para salvá-los para quando você tiver dados que indica que há um problema de desempenho real ... caso contrário, você vai gastar um monte de tempo micro-otimização e realmente fazer com que os custos de manutenção mais elevados para mais tarde.

Se você encontrar esta situação análise é realmente o gargalo na sua aplicação, então é o momento para tentar descobrir o que a maneira mais rápida para resolver o problema. Eu acho que Jeff (e muitos outros) têm um blog sobre esse tipo de coisa muito.

Respondeu 05/08/2008 em 09:04
fonte usuário

votos
5

O problema que você tem é que pode haver situações em que a resposta poderia ser todos os três tipos.

3 poderia ser um int, um casal ou uma corda!

Depende do que você está tentando fazer e como é importante que eles são um tipo particular. Poderia ser melhor apenas para deixá-los como eles são, contanto que você pode ou, em alternativa, alguns até com um método para marcar cada um (se você tem o controle da fonte da string original).

Respondeu 23/09/2008 em 22:38
fonte usuário

votos
5

Você obterá resultados diferentes para os diferentes métodos dependendo se você compilar com otimizações diante. Você basicamente tem algumas opções:

object o;

//checking with is
o is int

//check type
o.GetType() != typeof( int )

//cast and catch exception
try{ int j = (int) o; } 
catch {}

//use the tryparse
int.TryParse( Convert.ToString( o ), out j )

Você pode facilmente configurar um aplicativo de console que tenta cada um desses 10.000 vezes e retorna durações para cada (teste quando o é um int e quando é algo mais).

O try-catchmétodo é o mais rápido se o objeto não realizar um int, e de longe o mais lento, se isso não acontecer (ainda mais lento do que GetType). int.TryParseé muito rápido se você tiver uma corda, mas se você tem um objeto desconhecido é mais lento.

Curiosamente, com .Net 3.5 e otimizações ligado a o is intverificação leva o mesmo tempo que try-catchquando o fato é um int. o is inté apenas um pouco mais lento se o realmente é outra coisa.

Irritantemente FxCop vai vomitar advertências se você fizer algo como:

if( o is int )
    int j = (int) o;

Mas eu acho que é um bug no FxCop - ele não sabe int é um tipo de valor e recomenda que você use o as intem seu lugar.

Se a sua entrada é sempre uma string int.TryParseé melhor, caso contrário, o isoperador é mais rápida.

Como você tem uma seqüência que eu olhar para saber se você precisa saber que é um int, em vez de um duplo. Se int.TryParsepasses então assim será double.TryParseassim que você poderia metade o número de cheques - voltar casal ou corda e andar as duplas quando você espera um int.

Respondeu 10/08/2008 em 18:43
fonte usuário

votos
3

Eu pessoalmente uso int.tryparse, então Double.TryParse. Desempenho nesses métodos é bastante rápido. Ambos retornam um booleano. Se ambos falharem, então você tem uma corda, por como você define os seus dados.

Respondeu 05/08/2008 em 09:02
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more