Finalmente, tentei por Delphi2005. O dormitório era melhor que 512m. Falando em estabilidade, é muito melhor que o D8, mas eu ainda ouvi pessoas dizerem que há muitos bugs. ser usado. Afinal, não demora muito para Borland desenvolver compiladores usando .NET.
Não mencionarei os novos recursos do Delphi2005, está em toda parte na Internet.
Mas: eu realmente não entendo. O segundo ponto é que o diagrama UML pode gerar código diretamente. Saiba se esse é o motivo, mas o Delphi2005 não disse que pode fazer isso sem o Eco? O último ponto é que talvez o compilador de Borland seja de alto nível, mas o editor de código está longe de ser vs2005 OK, e a velocidade é extremamente rápida e sai instantaneamente. para correr por um tempo antes de sair. Mas, para ser justo, os avisos para o uso de vs são diretamente baseados no código. Será realmente um desastre. Falando em indentação automática de código, Borland é realmente incomparável. A última coisa que eu não gosto é que vou gerar automaticamente um modelo de anotação por 3 // em VS, mas Delphi não fornece as funções correspondentes, portanto, não é fácil comentar dessa maneira.
De volta ao tópico, o Delphi para.net fez alguns ajustes de sintaxe para se adaptar a alguns requisitos do .NET, mas existem poucos livros relacionados e eles não conseguem escrevê -los bem. Como escrever para eles. Agora que você tem Delphi2005, não pode esperar, continue explorando a si mesmo.
Hoje vou dar uma olhada na ajuda e aprender namespace
espaço para nome
Declare o espaço para nome
No arquivo de projeto de Delphi, um espaço para nome é declarado implicitamente, chamado de espaço para nome padrão do projeto. Suponha que o cabeçalho do arquivo do projeto esteja definido da seguinte forma:
Programa mycompany.programs.myprogram;
Em seguida, o espaço para nome padrão do projeto é mycompany.programs
Se um cabeçalho de unidade for definido como unidade ****;
Se um cabeçalho de unidade for definido como unidade ***. ****. ***;
A unidade declarada da primeira maneira é chamada de unidade genérica, que é sempre um subespaço do espaço de nome padrão do projeto
Nomeação de namespace é insensível a minúsculas. Em outras palavras, entre os vários segmentos de palavras divididas por., A última parte não é contada como um nome e não é compilada em montagem. , Unidade3. Usando esse recurso, se um grande espaço para nome precisar ser dividido em vários arquivos para gravar, você poderá tornar a parte inteira dessas unidades iguais, apenas diferente nesta seção do último.
Referências a espaços para nome
Use a instrução de usos. Suponha que exista a seguinte declaração:
usa aaa.bbb.unit1, unidade2;
Foi claramente especificado para AAA.BBB.Unit1.
1 o espaço de nome da unidade atual (se houver)
2 o espaço para nome padrão do projeto (se houver)
3 namespaces especificados por opções do compilador
Embora a última seção do nome da unidade não possa ser vista e indistinguível para compiladores externos, a última seção ainda é indispensável em Delphi; portanto, a última seção precisa ser incluída na declaração de usos, por exemplo, a classe1 é definida na unidade1 aaa.bb .Unit1. Não importa o quê, a unidade1 é essencial nos usos.
Na ajuda de Delphi, diz:
Várias unidades podem ser agrupadas em um espaço para nome usando uma extensão da cláusula IN no arquivo de origem do projeto.
usa myProgram.mynamespace em 'filepath/unit1.pas; outro caminho/unit2.pas';
Neste exemplo, o espaço de nome myProgram.Mynamespace contém logicamente todos os símbolos da interface da unidade1 e da unidade2. Símbolo chamado Mysymbol, o compilador relatará um erro na cláusula de uso.
Mas não importa como eu experimente, presto atenção aos erros de compilação e isso não pode ser implementado.
Até agora, não encontrei uma maneira de fazer referência à DLL gerada pela Delphi. Porque quando eu adiciono uma DLL compilada por Delphi para .Net no novo projeto do projeto Delphi e, em seguida, compilar, direi um erro fatal, não posso importar nada, use pacotes, etc. No entanto, não há problema em adicionar DLLs no vs.net, e o programa pode ser executado normalmente.
Até agora, encontrei apenas uma solução temporária, que é não gerar biblioteca e substituí -la pelo pacote, para que o arquivo de destino final também seja uma DLL, e também posso chamá -lo normalmente em vs.