Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le futur du compilateur Delphi dévoilé

Le , par Nono40

0PARTAGES

0  0 
Nick Hodges, responsable des produits Delphi et C++ Builder chez CodeGear, partage avec nous les dernières nouvelles du front concernant la direction prise pour l'avenir des compilateurs Delphi et C++ Builder.

Lisez Le futur du compilateur Delphi traduction de son article The Future of the Delphi Compiler.

Traduction réalisée par Eric GASPARD (Aka Guymelef).

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Telemak
Membre actif https://www.developpez.com
Le 19/01/2009 à 12:50
Bonjour,
Je n'utilise plus Delphi depuis quelques temps, on peut dire quelques années..
La raison est que j'ai migré de système d'exploitation.
Je suis passé de windows à linux...
Bien entendu je possède Kylix..la version linux de delphi...mais comme il n'y a jamais eu de suite, je me suis tourné vers d'autres langages..par exemple java avec netbeans..etc..

J'ai un peu lu en diagonale l'article et le fait de faire évoluer delphi et j'en suis très content...Mais néanmoins aucune annonce concernant des sorties sous linux... A moins que quelque chose ne se prépare de ce côté.. Je n'attends que celà...
a+
0  0 
Avatar de octal
Membre éprouvé https://www.developpez.com
Le 19/01/2009 à 15:35
Bonjour,
Décevant !!! (je parle de l'article, désolé).

Le Future du Compilateur Delphi;

tout un article pour, au final, nous apprendre qu'ils sont entrain de réécrire le compilo (front-end et back-end) à partir de zero, en conservant la compatibilité.
Franchement les choix de borland me semblent vraiment bizarre ces derniers temps.
En écrivant un Delphi2009, passage à l'UNICODE oblige, on casse une bonne partie des applications MODERNES écrite dans les règles de l'art, et n'utilisant que des constructions et fonctionnalités modernes du compilo (ce n'est pas une critique, je connais la problématique migration UNICODE et je la trouve dans D2009 très réussie). Par contre, Je ne vois pas trop pourquoi maintenir dans un compilo pareil, lors de migration (ennorme) pareille, pourquoi maintenir une notation en parenthèse_point ou même les trigraphes (pour C)... Cela n'a aucun sens. A la limite, de telles notations peuvent être simplement transformée via un rechercher/remplacer ou (pour les plus complexes) via le module de Refactoring (c'est censé utiliser la structure et la sémantique du langage ce trucs là pour y appliquer des transformations, n'est ce pas ) .
Borland (ou CodeGear ou Embarcadero, pardonnez moi cet abus de language, mais j'utilise les outils depuis DOS, plus précisément depuis TurboPascal3 - quand les array (.1..50.) étaient encore d'actualité). Des fois les choix fait par Borland sont étonnant. Je pense que les équipes de dév chez Borland doivent un peu oublier, de temps à autre, qu'ils ont été le STANDARD en pascal, l'ultime choix pour les outils de dev, qu'ils se retroussent les manches et qu'ils bossent sérieusement en prenant en compte qu'il y a un certain Visual Studio, NetBeans et/ou Eclipse. Le temps où les gens étaient étonnés de voir des menus déroulant dans un IDE est révolu!

Ce que personnellement, j'ai bien aimé dans D2009, c'était surtout le rajout des générique. Je pense que Borland devraient surtout se concentré sur le rajout de fonctionnalité pareils dans Delphi, des outils qui améliorent le confort dans la création de code réutilisable, des outils de modélisation beaucoup mieux intégrés et gérant le two-way-tools d'une manière plus sympa (plutot que des usines à gaz).
Le rajout du 64 bits est certainement très important. L'intégration de librairies standard le seraient plus, comme notamment rajouter une encapsulation (sous forme de composant VCL ou autre) d'une certaine OpenGL ou DirectX (principaux outils qui nécessitent du 64Bits à mon avis)...

Le aussi le rajout de la possibilité de générer du Code ARM (pour les PDA et autre milliers d'ordinateur embarqué ARM9) serait la bienvenue.

Ne me prenaient pas mal, le rajout du 64 bit pourrait être intéressant, mais pour nous les développeurs de solutions d'entreprises (de gestions principalement), que, je pense être majoritaires (en tous les cas plus important en nombre que les développeurs d'appli scientifiques), on s'enfoue un peu que le back end ou le front end soient réécrit ou pas, qu'ils deviennent compatible avec un C++ builder ou autre (je ne connait pas trops de sociétés utilisant les deux outils en parallel pour le meme projet - l'interet majeur était de pouvoir réutiliser la VCL dans C++ builder).
Ce que nous voulons c'est plus d'outils pour maintenir en vie nos appli existantes sans pour autant devoir les réécrire ou porter vers .NET (qui semble être une fatalité). C'est plus de fonctionnalité dans le langague pour faire du remoting, de l'accès sécurisé dans des appli multitiers sans devoir recourir à des usines à gaz développée par des tiers et mal entretenues ou migrées au fils du temps.
Le rajout de l'UNICODE ou des génériques en sont de très beaux exemples. Le maintien d'anciennes (très anciennes) fonctionnalité n'as aucun sens. je pense que pour du très vieux code, s'il est migré vers du 64bit, les parentheses_point ne sont absolument rien devant la gestion de l'unicode, de la taille des pointeurs (64bit oblige - ouilllee les getmem ou dispose ...), les variables integers qui changent de taille, ...
Le rajout de fonctionnalités (au seins du compilo) genre LINQ serait super (filtrer et recherche multicritère sur n'importe quel enumerable).
le rajout de fonctionnalités pour la gestion des champs de bits/byte/word comme dans les langages de l'embarqué serait un plus. Ce que j'entend par là c'est des outils pour accéder et modifier n'importe quelle section de bit d"un entier directement sans devoir recourir à des fonctions externes. Par exemple, pour changer le 6eme bit d'un nombre il serait sympa de pouvoir faire un truc du genre:
Code : Sélectionner tout
1
2
3
4
5
6
7
8
var i : Integer;
    j  : Word;
    k : byte;
begin
  i.Bits(6) := 1;  
  k := j.Bytes(2) //le second byte du word
end


Tout cela sans devoir recourir à des fonctions externes, et sans devoir jongler avec les record (cast vers des types record) et leur champs variants. Ca serait très utile et sympa.

Actuellement je continue à utiliser Delphi pour pas mal de projets, notement pour les appli s'interfaçant avec le matériel (l'électronique), pour les services windows, ... Pour ce genre de développement, je n'aime pas utiliser du code managé, surtout à cause du déploiment (les applis delphi n'utilisant pas de bdd sont un régal en déploiement)
J'espère ne pas avoir à switcher complètement de language (comme je l'ai déjà fais pour les appli de gestions depuis deux ans).

Cordialement.
octal
0  0 
Avatar de philnext
Membre expérimenté https://www.developpez.com
Le 19/01/2009 à 18:01
J'avoue que j'ai rarement vu un article aussi vide de sens.
Annoncer que l'on sort un nouvel IDE en gardant la compatibilité, c'est un peu une évidence.
Par contre quid de nouvelles fonctionnalités ? à part le 64 bits : pas grand' chose !
Bref : décevant !
0  0 
Avatar de VLDG
Membre éclairé https://www.developpez.com
Le 19/01/2009 à 19:23
ça me rappelle les modules de compilation quand j'étais jeune...

je ne pense pas que c'est avec ça que CodeGear fera vendre plus de Delphi mais sans ça : Delphi n'a pas d'avenir...

On peut donc encore espérer
0  0 
Avatar de Andnotor
Rédacteur/Modérateur https://www.developpez.com
Le 19/01/2009 à 20:30
Pour info (et ceci depuis la nuit des temps)

Code : Sélectionner tout
1
2
3
4
5
6
var
  j :Word;
  k :byte;
begin
  k := j.Bytes(2) //le second byte du word
end
égale

Code : Sélectionner tout
1
2
3
4
5
6
var
  j :Word;
  k :byte;
begin
  k := hi(j) //le second byte du word
end
Dés que Delphi sera estampillé x64, les ventes vont grimper d'office même si moi aussi j'aimerais que la programmation embarquée (appareils mobiles) soit plus à l'honneur.

J'ai testé certains de mes soft sur Seven (32) et le Win32 fonctionne parfaitement. On est cool pour les 5 prochaines années, le x64 pourrait attendre dans mon cas
0  0 
Avatar de philnext
Membre expérimenté https://www.developpez.com
Le 19/01/2009 à 21:24
Je voulais rajouter : bravo pour la traduction !
Même si j'ai trouvé l'article un peu 'frustrant' je suis content de l'avoir eu à disposition !
0  0 
Avatar de octal
Membre éprouvé https://www.developpez.com
Le 20/01/2009 à 0:38
Citation Envoyé par Andnotor Voir le message
Pour info (et ceci depuis la nuit des temps)

Code : Sélectionner tout
1
2
3
4
5
6
var
  j :Word;
  k :byte;
begin
  k := j.Bytes(2) //le second byte du word
end
égale

Code : Sélectionner tout
1
2
3
4
5
6
var
  j :Word;
  k :byte;
begin
  k := hi(j) //le second byte du word
end
le commentaire est erroné, le .bytes(2) retourne le 3eme byte !

super cool. depuis la nuit des temps (je pensais que c'était depuis que l'on écrivait les parentheses_point pour les arrays : ) ? merci pour la leçon.

Tu fait comment pour modifier le 3eme octet d'un quad sans recourir aux mask et rotations? (je sais que le compilo le fait de cette manière là "sur certains processeurs", mais j'aurais aimé avoir de telles fonctionnalités en natif pour plus de confort).

cordialement
octal
0  0 
Avatar de Andnotor
Rédacteur/Modérateur https://www.developpez.com
Le 20/01/2009 à 9:00
Code : Sélectionner tout
le commentaire est erroné, le .bytes(2) retourne le 3eme byte !
3ème byte d'un word, difficile.

Dans le cas d'un dword, tu peux faire ceci:
Code : Sélectionner tout
1
2
3
4
5
6
var
  dw :dword;
  b :array[0..3] of byte absolute dw;
begin
  b[2] := $FF;
end;
0  0 
Avatar de octal
Membre éprouvé https://www.developpez.com
Le 20/01/2009 à 10:08
Citation Envoyé par Andnotor Voir le message


Dans le cas d'un dword, tu peux faire ceci:
Code : Sélectionner tout
1
2
3
4
5
6
var
  dw :dword;
  b :array[0..3] of byte absolute dw;
begin
  b[2] := $FF;
end;
Super !
on fait comment alors quand on a plusieurs tableaux de variable structurées parmis lesquel on voudrais récupérer ou modifier certain bit? le "mappage" d'addresse n'est pas trop évident, à moins de se taper un calcul d'adresse par rapport à l'origine de la première variable dur encore quand il s'agit de variables allouées dynamiquement

Bref !

Je le redis ! le commentaire est eronné! l'écriture Bytes(2) retourne le 3eme byte. je n'ai pas dis que l'exemple fonctionnait ou que l'on pouvait avoir le troisieme byte d'un word! Si tu veux change l'exemple en Bytes(1) et qu'on en parle plus.
Ce n'etaient que des exemple rapidement ecrit pour fixer les idées sur ce que l'on voudrait avoir dans un futur Delphi.

Relis mon premier post!
Encore une fois le but c'est d'avoir de tel outils intégrés dans le compilo, et non de le faire via du cast ou "mem map" !
J'utilise un tas de routines que j'ai développé il y a un certain temps pour faire du mask-age, faire de l'arithmetique binaire et toutes les transformations binaires possibles. Cela n'est pas le pb. L'interret c'est d'avoir un niveau de confort plus élevé et surtout un range checking et un controle de types evolué en utilisant les fonctionnalités native du langage.

PS. Je trouve que l'on a trops pollué ce post (comme d'hab). Je ne voudrais que ce post se transforme en commentaires/débats stérile et inutiles autour d'éléments syntaxiques. On peut tout faire avec delphi est c'est tant mieux. on n'a plus besoin que du 64 bit.

Cordialement
octal
0  0 
Avatar de Paul TOTH
Expert éminent sénior https://www.developpez.com
Le 20/01/2009 à 12:25
allez, j'ajouterais que j.Bytes() n'existe pas sur les Delphi que j'utilise
0  0