Essayé par Delphi2005. Le dortoir était meilleur que 512 m. En parlant de stabilité, c'est beaucoup mieux que D8, mais j'ai toujours entendu des gens dire qu'il y a beaucoup de bugs. être utilisé. Après tout, il ne faut pas longtemps à Borland pour développer des compilateurs en utilisant .NET.
Je ne mentionnerai pas les nouvelles fonctionnalités de Delphi2005, elle est partout sur Internet.
Mais: je ne comprends vraiment pas. Le deuxième point est que le diagramme UML peut générer directement du code. Sachez si c'est la raison, mais Delphi2005 Vous n'avez pas dit que vous pouvez le faire sans Eco? Le dernier point est que le compilateur Borland est peut-être de haut niveau, mais l'éditeur de code est loin de VS2005. OK, et la vitesse est extrêmement rapide, et il sort instantanément. se précipiter un moment avant de sortir. Mais pour être juste, les invites pour l'utilisation de VS sont directement basées sur le code. Ce sera vraiment une catastrophe. En parlant d'indentation automatique du code, Borland est vraiment incomparable. La dernière chose que je n'aime pas, c'est que je générerai automatiquement un modèle d'annotation par 3 // dans VS, mais Delphi ne fournit pas les fonctions correspondantes, il n'est donc pas vraiment facile de commenter de cette manière.
Retour au sujet, Delphi pour.net a fait des ajustements de syntaxe pour s'adapter à certaines exigences de .NET, mais il y a peu de livres connexes et ils ne sont pas en mesure de bien les écrire. Comment les écrire. Maintenant que vous avez Delphi2005, vous ne pouvez pas attendre, continuez simplement à vous explorer.
Aujourd'hui, je vais jeter un œil à l'aide et apprendre l'espace de noms
espace de noms
Déclarer l'espace de noms
Dans le fichier de projet de Delphi, un espace de noms est implicitement déclaré, appelé l'espace de noms par défaut du projet. Supposons que l'en-tête du fichier de projet est défini comme suit:
Programme MyCompany.Programs.MyProgram;
Ensuite, l'espace de noms par défaut du projet est MyCompany.Programs
Si un en-tête d'unité est défini comme l'unité ****;
Si un en-tête d'unité est défini comme l'unité ***. ****. ***;
L'unité déclarée dans la première façon est appelée unité générique, qui est toujours un sous-espace de l'espace de noms par défaut du projet
La dénomination de l'espace de noms est insensible à la casse. En d'autres termes, parmi les plusieurs segments de mots divisés par., La dernière partie n'est pas comptée comme un nom et n'est pas compilée en assemblage. , Unit3. En utilisant cette fonctionnalité, si un grand espace de noms doit être divisé en plusieurs fichiers à écrire, vous pouvez rendre toute la partie de ces unités identiques, tout simplement différente dans cette section de la dernière.
Références aux espaces de noms
Utilisez l'instruction USE. Supposons qu'il y ait la déclaration suivante:
utilise aaa.bbb.unit1, unit2;
Il a été clairement spécifié pour AAA.BBB.Unit1.
1 L'espace de noms d'unité actuel (le cas échéant)
2 L'espace de noms par défaut du projet (le cas échéant)
3 espaces de noms spécifiés par les options du compilateur
Bien que la dernière section du nom de l'unité ne puisse pas être vue et indiscernable pour les compilateurs externes, la dernière section est toujours indispensable à Delphi, de sorte que la dernière section doit être incluse dans l'instruction USE, par exemple, la classe1 est définie dans unité 1 aaa.bb .Unit1. Quoi qu'il en soit, l'unité1 est essentielle dans les utilisations.
Dans l'aide de Delphi, il dit:
Plusieurs unités peuvent être regroupées en un seul espace de noms à l'aide d'une extension de la clause dans le fichier source du projet.
utilise myProgram.myNamespace dans 'filepath / unit1.pas; autrepath / unit2.pas';
Dans cet exemple, l'espace de noms MyProgram. Symbole nommé MySymbol, le compilateur rapportera une erreur dans la clause Utilisation.
Mais peu importe comment j'expérimente, je fais attention aux erreurs de compilation, et elle ne peut pas être mise en œuvre.
Jusqu'à présent, je n'ai pas trouvé de moyen de référencer la DLL générée par Delphi. Parce que lorsque j'ajouterai une DLL compilée par Delphi pour .NET dans le nouveau projet du projet Delphi, puis à compiler, je dirai une erreur fatale, je ne peux rien importer, veuillez utiliser des packages, etc. Cependant, il n'y a aucun problème à l'ajout de DLL dans VS.NET, et le programme peut s'exécuter normalement.
Jusqu'à présent, je n'ai trouvé qu'une solution temporaire, qui ne doit pas générer de bibliothèque et la remplacer par un package, afin que le fichier cible final soit également une DLL, et je peux également l'appeler normalement dans Vs.