POSSO INVENTAR UM TIPO?
Sim, o LLAIA está certÃssimo.
Mas no exemplo eu apenas demonstro uma maneira de fazer o que você pede.
Estou levando em consideração que seus dados não são estáticos e que você os pega de algum lugar, seja ele um BD ou qualquer outro lugar.
No exemplo eu coloquei valores fixos apenas como demonstração.
Mas no exemplo eu apenas demonstro uma maneira de fazer o que você pede.
Estou levando em consideração que seus dados não são estáticos e que você os pega de algum lugar, seja ele um BD ou qualquer outro lugar.
No exemplo eu coloquei valores fixos apenas como demonstração.
Prezados colegas,
Pedi uma orientação, e recebi não uma mas várias sugestões muito boas.
Muito obrigado.
Mas,independente de qual solução eu adotar,gostaria de perguntar aos colegas se minha preocupação tem
fundamento ou não. O caso é que minha função tem por objetivo procurar um deteminado valor (Texto).
Por motivo que não vem ao caso agora,ela tem de retornar 3 valores possiveis:
[Ô]S[Ô] ------- Indicando que encontrou
[ô]N[Ô] --------Indicando que não encontrou
[Ô]#[Ô] -------Indicando que localizou parcialmente (O valor citado como parâmetro,na chamada da função)
Por isto,achei um exagero usar o tipo String ou mesmo Integer.
Existe mesmo, [Ô]Desperdicio de recurso ao declarar o retorno da a variável como String ou Integer[Ô], ( E minha preocupação é valida)
ou tecnicamente não faz diferença?????
Pedi uma orientação, e recebi não uma mas várias sugestões muito boas.
Muito obrigado.
Mas,independente de qual solução eu adotar,gostaria de perguntar aos colegas se minha preocupação tem
fundamento ou não. O caso é que minha função tem por objetivo procurar um deteminado valor (Texto).
Por motivo que não vem ao caso agora,ela tem de retornar 3 valores possiveis:
[Ô]S[Ô] ------- Indicando que encontrou
[ô]N[Ô] --------Indicando que não encontrou
[Ô]#[Ô] -------Indicando que localizou parcialmente (O valor citado como parâmetro,na chamada da função)
Por isto,achei um exagero usar o tipo String ou mesmo Integer.
Existe mesmo, [Ô]Desperdicio de recurso ao declarar o retorno da a variável como String ou Integer[Ô], ( E minha preocupação é valida)
ou tecnicamente não faz diferença?????
Vc fala exagero no sentindo de consumo computacional?
Se sua função retorna sempre um caractere, mesmo que vc venha a usar todas as letras do nosso alfabeto vai ter o mesmo custo computacional de usar só 3. A vantagem da restrição é a padronização em código.
Teoricamente, se cada caractere seja da tabela ASCII, cada [Ô]custa[Ô] 8 bits no VB, um Integer vsriando de -327?? a 327?? (preguiça de pesquisar ... :P), 16 bits.
Nesse seu caso aà no .Net, acho que o mais interessante seria o Nullable(Of Boolean) como retorno, pois vc teria 2 estados mais a condição nula para verificar.
Se sua função retorna sempre um caractere, mesmo que vc venha a usar todas as letras do nosso alfabeto vai ter o mesmo custo computacional de usar só 3. A vantagem da restrição é a padronização em código.
Teoricamente, se cada caractere seja da tabela ASCII, cada [Ô]custa[Ô] 8 bits no VB, um Integer vsriando de -327?? a 327?? (preguiça de pesquisar ... :P), 16 bits.
Nesse seu caso aà no .Net, acho que o mais interessante seria o Nullable(Of Boolean) como retorno, pois vc teria 2 estados mais a condição nula para verificar.
Uma classe serializável define um tipo de dados composto.
Uma estrutura define um tipo de dados composto.
Já uma enumeração é outra coisa. mais similar á uma lista, por exemplo, só que sem os métodos de uma lista convencional.
A classe Carro abaixo é um tipo.
Isso quer dizer que eu posso criar uma variável do tipo [Ô]Carro[Ô], posso enviar e receber valores do tipo [Ô]Carro[Ô] entre aplicativos, webservices e winservices, por exemplo, e posso ainda gerar esse tipo como uma extensão da própria linguagem, de modo que todos os aplicativos que referenciem a extensão saberão o que é o tipo [Ô]Carro[Ô].
Já em relação ao consumo de memória, é claro que um tipo composto é invariavelmente mais [Ô]pesado[Ô] que um tipo nativo. Enumerações normalmente apontam um valor inteiro á um endereço de referência (memória), de modo que [Ô]pesam[Ô] um pouco mais do que as variáveis [Ô]simples[Ô], mas menos do que um tipo composto.
Em todos os casos, o [Ô]custo[Ô] em memória só é efetivamente percebido, com o hardware atual, quando você lida com massas de informações, assim, a definição dos tipos não deve afetar / preocupar tanto quanto a lógica adequada. No entanto note que isso não significa que criar uma variável sem indicar o tipo é prática recomendável.
Uma estrutura define um tipo de dados composto.
Já uma enumeração é outra coisa. mais similar á uma lista, por exemplo, só que sem os métodos de uma lista convencional.
A classe Carro abaixo é um tipo.
<Serializable>
Public Class Carro
Public Enum Fabricantes
Volkswagen
Fiat
Ford
End Enum
Public Property Fabricante As Fabricantes = Carro.Fabricantes.Fiat
Public Property Marca As String = [Ô]Fiat 147[Ô]
Public Property Valor As Decimal = 6430D
Public Sub New
End Sub
End ClassIsso quer dizer que eu posso criar uma variável do tipo [Ô]Carro[Ô], posso enviar e receber valores do tipo [Ô]Carro[Ô] entre aplicativos, webservices e winservices, por exemplo, e posso ainda gerar esse tipo como uma extensão da própria linguagem, de modo que todos os aplicativos que referenciem a extensão saberão o que é o tipo [Ô]Carro[Ô].
Já em relação ao consumo de memória, é claro que um tipo composto é invariavelmente mais [Ô]pesado[Ô] que um tipo nativo. Enumerações normalmente apontam um valor inteiro á um endereço de referência (memória), de modo que [Ô]pesam[Ô] um pouco mais do que as variáveis [Ô]simples[Ô], mas menos do que um tipo composto.
Em todos os casos, o [Ô]custo[Ô] em memória só é efetivamente percebido, com o hardware atual, quando você lida com massas de informações, assim, a definição dos tipos não deve afetar / preocupar tanto quanto a lógica adequada. No entanto note que isso não significa que criar uma variável sem indicar o tipo é prática recomendável.
Tópico encerrado , respostas não são mais permitidas