As cinco principais alterações do VB 6 para o VB.NET

O Visual Basic 1.0 foi um grande terremoto ao longo da programação. Antes do VB1, era necessário usar C, C ++ ou outro ambiente de desenvolvimento horrível para criar aplicativos do Windows. Os programadores literalmente passaram semanas apenas desenhando janelas em telas com códigos exigentes, detalhados e difíceis de depurar. (A mesma coisa que você pode fazer arrastando um formulário da barra de ferramentas em alguns segundos.) O VB1 foi um sucesso e muitos milhões de programadores começaram a usá-lo imediatamente.

Mas, para fazer a mágica acontecer, a Microsoft fez alguns importantes compromissos de arquitetura. Em particular, como o VB1 criou os formulários e os controles, eles não permitiram ao programador acessar o código que o criou. Você deixou o VB criar tudo ou usou o C ++.

Os VB 2 a 6 mantiveram essa mesma arquitetura. A Microsoft fez algumas atualizações muito inteligentes que deram aos programadores muito mais controle, mas, na análise final, os programadores ainda não conseguiram integrar seu código ao código VB. Era uma caixa preta - e também não da boa maneira OOP. Outra maneira de dizer isso era que o programador não tinha acesso aos "objetos" internos do VB e outra maneira de dizer isso era que o VB6 ainda não estava totalmente "orientado a objetos".

Enquanto isso, Java, Python e muitas outras linguagens de programação orientadas a objetos WERE começaram a aparecer. Visual Basic estava sendo ignorado - grande momento! Esta é uma situação que a Microsoft não tolera... e eles resolveram resolver o problema de uma vez por todas. A solução é .NET.

Mas para fazer o que o .NET precisava fazer, a Microsoft decidiu que eles precisavam "quebrar a compatibilidade". Ou seja, os programas do Visual Basic foram (com exceções muito pequenas) "compatíveis com versões anteriores" do VB1 até o VB6. Um programa escrito nessa primeira versão do VB ainda seria compilado e executado na próxima versão. Porém, com o VB.NET, a Microsoft descobriu que eles simplesmente não conseguiam tornar o idioma completamente fora de controle e manter uma compatibilidade ascendente.

Depois de tomarem essa decisão fundamental, as comportas se abriram com dez anos de alterações acumuladas na "lista de desejos" e TODAS elas foram para o novo VB.NET. Como se costuma dizer na Grã-Bretanha, "por um centavo, por um quilo".

Sem mais demora, aqui está minha lista pessoal das cinco principais alterações do VB6 para o VB.NET em ordem inversa.

Wellllll... apenas mais um atraso. Como estamos mudando do VB6, onde uma matriz declarada como Dim myArray (5) tem 6 elementos, temos seis deles. É apenas adequado ...

(Por favor, rufem os tambores ...)

"Prêmio (5)", nosso 6º Lugar prêmio vai para a escolha de groupies C: Alterações de sintaxe tipo C!

Agora você pode codificar a + = 1 em vez de a = a + 1, economizando TRÊS KEYSTROKES TODOS!

Programadores do mundo, alegrem-se! O VB foi elevado ao nível C, e toda uma nova geração tentando aprender VB se aproximará um pouco da confusão em massa que confronta os estudantes de C ++.

Mas espere! Tem mais!

O VB.NET agora apresenta "lógica de curto-circuito" que introduz bugs sutis no código C ++ há anos para economizar preciosos nano-segundos de tempo do processador. A lógica de curto-circuito avalia apenas várias condições em uma instrução lógica, se necessário. Por exemplo:

Dim R As Boolean
R = Função1 () E Função2 ()

No VB6, ambas as funções são avaliadas independentemente de serem necessárias ou não. Com o VB.NET, se Function1 () for falsa, Function2 () será ignorada, pois "R" não pode ser True. Mas, e se uma variável global for alterada em Function2 () - por acaso (os programadores de C ++ diriam ", por programação ruim ".) Por que meu código produz a resposta errada algumas vezes quando é traduzido para VB.NET? Pode ser isso!

Para Experimentarmais difícil, o VB.NET Pegar um pouco de sorte e Finalmente seja reconhecido pelo tratamento de erros "excepcional".

O VB6 teve o último holdTo GoTo: "On Error GoTo". Mesmo eu tenho que admitir que o tratamento de exceção estruturada "Try-Catch-Finalmente" do estilo C ++ é uma grande melhoria, não apenas uma melhoria meia vasta.

O que você diz "On Error GoTo" ainda está no VB.NET? Wellll... Tentamos não falar muito sobre isso.

5º Lugar a seleção é um prêmio de grupo: O comando variado muda! Eles têm que compartilhar esse prêmio e há um bilhão deles. A Microsoft economiza há dez anos e eles realmente se soltam.

O VB.NET não oferece mais suporte às funções VarPtr, ObjPtr e StrPtr, que recuperavam o endereço de memória das variáveis. E não suporta VB6 LSet, que foi usado para converter um tipo definido pelo usuário para outro. (Não confunda com o VB6 LSet, que faz algo completamente diferente - veja abaixo.)

Também oferecemos lances para Let, Is Missing, DefBool, DefByte, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj, DefVar e (meu favorito pessoal!) GoSub.

O círculo se transformou em GDI + DrawEllipse. O mesmo vale para Line to DrawLine. No cálculo, agora temos Atan em vez de Atn, Sign entra para Sgn e Sqrt se adapta ao grande jogo em vez de Sqr.

No processamento de cadeias, mesmo que ainda estejam disponíveis se você referenciar uma compatibilidade da Microsoft namespace, temos PadRight para LSet do VB6 (novamente, totalmente diferente do LSet do VB6, é claro) e PadLeft para RSet. (Lá estão as três teclas que salvamos com "+ ="!)

E, é claro, como estamos no OOP agora, não se preocupe se Property Set, Property Let e ​​Property Get não forem atendidas no VB.NET, você pode apostar!

Finalmente, depure. A impressão torna-se Debug. Escreva ou depure. WriteLine. Somente nerds imprimem tudo de qualquer maneira.

Isso nem sequer toca em todos os NOVOS comandos do VB.NET, mas precisamos parar com essa bobagem em algum lugar.

Dentro 4º Lugar, temos Alterações nas chamadas de procedimento!

Este é o prêmio "bondade, pureza e virtude saudável" e representa muitas campanhas difíceis da facção "não há mais códigos desleixados".

No VB6, se uma variável de parâmetro de procedimento é um tipo intrínseco, é ByRef, a menos que você a tenha codificado ByVal explicitamente, mas se não estiver codificado como ByRef ou ByVal e não for uma variável intrínseca, será ByVal... Percebido?

No VB.NET, é ByVal, a menos que seja codificado por ByRef.

O padrão ByVal VB.NET, a propósito, também impede que alterações nas variáveis ​​de parâmetro nos procedimentos sejam propagadas acidentalmente de volta ao código de chamada - uma parte essencial da boa programação de OOP.

A Microsoft também "sobrecarrega" o VB.NET com uma alteração nos requisitos de parênteses nas chamadas de procedimento.

No VB6, os parênteses são necessários em torno dos argumentos ao fazer chamadas de função, mas não ao chamar uma sub-rotina quando não estiver usando a instrução Call, mas eles são necessários quando a instrução Call é usada.

No VB.NET, parênteses são sempre necessários em torno de uma lista de argumentos não vazia.

O Prêmio Bronze - 3º Lugar, vai para As matrizes são 0 baseadas em vez de 1!

É apenas uma alteração de sintaxe, mas essa alteração obtém o status de "pódio de medalhas" porque é votada como "mais provável que estrague sua lógica do programa". Lembre-se, 3º lugar É "Prêmio (2)" em nossa lista. Se você tiver contadores e matrizes em seu programa VB6 (e quantos não possuem), esse será um SUCESSO.

Por dez anos, as pessoas perguntam: "O que a Microsoft estava fumando quando fez dessa maneira?" E por dez anos, programadores têm universalmente ignorou o fato de que havia um elemento myArray (0) que apenas ocupava espaço e não era usado para qualquer coisa... Exceto aqueles programadores que o usaram e seus programas pareciam, quero dizer, apenas "estranhos".

Para I = 1 a 5
MyArray (I - 1) = Qualquer que seja
Próximo

Quero dizer, REALMENTE! ...

A Medalha de Prata de 2 º lugar vai homenagear um velho amigo que caiu no balde de programação com a passagem do VB6! Eu falo de ninguém menos que, O tipo de dados variante.

Provavelmente, nenhum outro recurso único do "notNet" do Visual Basic representa melhor a filosofia de "rápido, barato e flexível". Essa imagem perseguiu o VB até a introdução do VB.NET. Tenho idade suficiente para lembrar a introdução do Visual Basic 3.0 pela Microsoft: "Oh Uau! Olha aqui! Com o novo tipo de dados Variant aprimorado, você não precisa declarar variáveis ​​ou nada. Você pode apenas pensar neles e codificá-los. "

A Microsoft mudou muito rapidamente a música e recomendou a declaração de variáveis ​​com um tipo de dados específico quase imediatamente, deixando muitos de nós imaginando: "Se você não pode usar variantes, por que tê-los?"

Mas enquanto estamos no assunto de tipos de dados, devo mencionar que muitos tipos de dados foram alterados, além de colocar a Variant no cimento úmido. Há um novo tipo de dados Char e um tipo de dados Long que é de 64 bits. Decimal é muito diferente. Curto e Inteiro não têm mais o mesmo comprimento.

E há um novo tipo de dados "Objeto" que pode ser qualquer coisa. Eu ouvi alguém dizer "Filho de Variante"?

Finalmente! Medalha de Ouro, 1 º lugar, o maior prêmio que posso conceder vai para ...

SURPRESA!

O VB.NET está finalmente completamente Orientado a Objetos!

Agora, quando você vai à praia, os programadores de C ++ não chutam areia na sua cara e roubam sua (namorada / namorado - escolha uma). E você pode ainda codifique um Balancete completo do Razão enquanto eles tentam descobrir quais arquivos de cabeçalho devem ser incluídos.

Pela primeira vez, você pode codificar o mais próximo possível do chip e acessar todos os componentes internos do sistema que seu coração deseja sem tendo que recorrer a essas chamadas desagradáveis ​​da API do Win32. Você tem herança, sobrecarga de funções, multithreading assíncrono, coleta de lixo e tudo é um objeto. A vida pode ficar melhor?

Eu ouvi alguém dizer que o C ++ tem herança múltipla e o .NET ainda não?

Queime o herege!