Discussion :

[cpdump]

1) Quand vous dites que dotnet c'est lent c'est un mythe. Par exemple les applications VB.NET sont beaucoup plus performantes qu'une application VB6.

Si je ne m'abuse, VB6 est interprété donc il y rien d'extraordinaire à ce que VB.NET soit plus rapide (interpreté + compilation JIT), ce qu'il faut voir c'est la différence de vitesse entre du VB.NET et du binaire x86.

[Wilco]

Oui Higgins, ton retour d'expérience sur l'adaptation de l'outil de développement (C++ pour une appli PDA ) illustre bien le propos de mon précédent post.

Certes les environnements managés .NET seront incontournables puisqu'ils vont faire partie intégrante des futurs systèmes d'exploitation que nous trouverons sur nos machines.

Comme je l'ai dit, il n'est pas question de refuser cette évolution technologique, cependant, il faut toujours garder à l'esprit que le temps et le confort de l'utilisateur sont plus importants que ceux du développeur.

Il est évident que plus on va vers les environnements managés, plus on s'éloigne du temps réel, ce qui n'est pas toujours compatible avec certaines applications.

Il faut que donc que ces nouveaux outils ne nous interdisent pas d'utiliser nos anciennes techniques et langages de développement et, c'est à ce titre qu'il est regrettable de ne plus pouvoir acheter un Delphi7 par exemple (dernière version Win32) sans être obligé de se payer le Dephi.NET. Certaines applications ne nécessitent pas à ce jour autre chose qu'un langage Win32.

Wilco

[Marc Lussac]

Bon et bien ca deviens beaucoup plus intéréssant comme opinions, c'est déjà plus nuancé

[Marc Lussac]

Je viens de mettre cette discussion en post it, pour éviter de la recommencer toutes les 2 semaines, et que par ailleurs je vais utiliser ce lien à partir d'une annonce club, et de la newsletter.

[Laurent Dardenne]

Voici ce que j'avais ecrit aprés qq jours passé sur la beta de Delphi 2005 au mois d'octobre alors que toutes les fonctionnalités n'étaient pas implémentées :

Avec cette version on peut penser que Delphi pour Win32 n'est pas en fin de course mais continue son aventure sous d'autre forme.
On pouvait craindre avec la version de Delphi 8, que la plateforme Delphi pour Win32 était vouée à disparaitre et les programmeurs perdent leurs compétences ( certains diraient leur "employabilité") Delphi 9 nous démontre le contraire.
A-t-on donc droit aux meilleurs des 2 mondes ? Dot Net étant pour moi assez flou, partir à sa découverte avec ce produit n'est pas un probléme, mais un levier.
Delphi étant un produit vraiment bien conçu on s'apercoit qu'il peut migrer vers Dot Net sans laisser tomber les bons réflexes, mieux il les affine.
...

Aprés 15 jours sur Dot-NET avec Delphi 2005 je dois vous dire que je suis vraiment emballé par .NET mais cela nécessite un effort d'apprentissage non négligeable. Et Delphi 2005 même s'il a qq difficultés de lancement m'impressione autant que Delphi 1 !
De plus je n'ai pas à apprendre un nouveau langage c'est déjà ça de gagné

Voici qq possibles évolutions du C# et quelque part peut être de Delphi si Borland veut rester dans la course :-)


On a beau décrier MS, regardez les liens vers le futur possible de la programmation en .NET:

C#, les possibles évolutions ( les types générics )

Extrait d'un interview de Danny Thorpe au sujet de Delphi 2005 :

Microsoft has .NET 2.0 announced for the next year. When can we expect Delphi 10 and what have you planned for it?
Probably the biggest item in terms of the compiler/language is implementing parameterized type syntax (generic types) in Delphi. We've had parameterized type syntax sketched out on the whiteboards here for ages but other stuff (platforms) kept taking priority. The general goal is to have a product release in 2005, shortly after .NET 2.0 is finalized and released.

C# 3.0 (Comega ) la fusion POO/SQL/XML ?

Exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
{
  Database db = new Database("db://amazon.com");
  XML list = db.Search("Author like 'Hugh Darwen'");
  foreach (XML book in list) {
    wishlist.Add(book.Title + ", " + book.ISBN);
}

Moi je prends :-)

[laffreuxthomas]

Par contre, le fait que le FrameWork de .Net ne soit pas installé par défaut avec Win me gène.

Il est en standard dans Windows 2003 Server. Il est aussi en standard dans mon Windows XP sp2 home edition, pré-installé sur mon portable Toshiba, et j'ai l'impression que c'est une généralité maintenant.

[soccersoft]

Merci d'avoir remis Delphi 6 personnel en téléchargement.

Je voulais creer un petit programme de tournoi de championnat de foot sous windows. De là à acheter Delphi 2005 pour faire ca....

Dommage qu'avec l'édition personnel, les composants database ne soit pas fournis....

Toujours pas de solution.
Les licences DELPHI ne sont pas cédable il me semble, non ?

La seule solution qui se présente à moi aujourd'hui est d'acheter Delphi 2005 ou de changer de language de programmation.

Tu n'as pas besoin obligatoirement des bases de données pour faire celà, ni de Delphi 2005, j'utilise Delphi 5 sans base de données...et j'arrive à faire tout ce dont j'ai besoin :

http://soccersoft.free.fr/Presentation.htm

Mais j'en suis à plusieurs dizaines de milliers de lignes de code et là, quand je lis ce post, je me dis que ça va être chaud pour passer tout ça en .NET mais j'ai bien envie de m'y mettre au .NET car ceux qui s'y mettent dès maintenant auront "peut être" un temps d'avance sur les autres et je préfère prévoir à l'avance...!

Le but de Delphi, c'est de programmer en se débarrassant des taches répétitives comme la gestion des handles, de la mémoire et de se consacrer qu'au programme en lui même en augmentant la productivité du développeur donc si y-a moyen d'aller plus vite avec .NET, c'est clair que ça vaut le coup de s'y mettre, sinon bof ! Et à voir si le .NET pourra permettre de tourner sous plusieurs OS, j'ai pas mis encore le nez dedans mais j'ai vu un projets Linux sympathique...donc un logiciel en un langage qui tournerait ensuite sous Win/Linux et Mac sans émulateur, ça serait sympa ...

[ihpled]

Bonjour

Pour tous ceux qui souhaite rester en Win 32 Borland à lancer dans la limite des stocks disponibles Borland Delphi 7 pro FR à 377€HT et Borland Delphi 7 entreprise à 777€HT c'est une bonne

plus d'information sur la new's Borland en bas à gauche de la page http://info.borland.fr/DesktopDefault.aspx?tabid=238

Attention, cet offre est composée uniquement du CD Rom et de la licence pas de documentation papier...

Bon développement à tous

Ihpled

[monmien]

Bonjour,
quelqu'un a des infos sur la gestion du 64 bits par Borland ?

[Laurent Dardenne]

Pour l'instant il existe une option du compilateur en ligne de commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 --platform:[x86|x64] = PE executable format (default x86)

Mais pour DCCIL .NET.
Pour le moment pas pour 'Win64'. il n'existe pas de programme 'DCC64.EXE' dans les distributions.

[rt15]

Pour tous ceux qui souhaite rester en Win 32 Borland à lancer dans la limite des stocks disponibles Borland Delphi 7 pro FR à 377€HT et Borland Delphi 7 entreprise à 777€HT c'est une bonne

377 euros, snif.

Petite remarque sur dotnet. J'vais y aller alors que je sais pas trops de quoi je parle, donc merci de me corriger.

Le processeur mange des 0 et des 1.
Ces 0 et ces 1 représentent des instructions processeurs, avec leur opérandes. Par exemple, suposons que 0010.1010.0010 signifit xor eax,eax. Cela revient à mettre le registre du processeur eax à 0. Ce registre est un des plus important du processeur. Lorsque l'on compile en natif, le fichier sur le disque comportera 0010.1010.0010 si le comilo a décider qu'à un moment il fallait mettre le registre eax à 0. Sauf erreur si on code par exemple allo(0), le compilo vat faire un xor eax, eax suivit d'un push eax (a condition de demander un cadre de pile dans la déclaration de la routine allo).

Bref, le compilo de Delphi 7 et précédent compile en 0 et en 1 qui sont chargés tel quel par le loader de Windows, puis l'execution commence, et les 0 et les 1 vont arriver tel quel au processeur.

Pour les processeurs, AMD, Intel, qu'ils soient sous UNIX, Linux, Windows et Dieu sait quoi (Pas MAC), 0010.1010.0010 aura le même résultat.

Je sais pas si quelqu'un a remarqué, mais AMD et Intel ce font une guerre de vitesse. Les processeurs sont devenus des monstres, avec des algorithmes de prédictions, des pipes à plus savoir quoi en faire, des caches niveau je sais plus combien. Tout ça fait que 0010.1010.0010 sera mangé plus vite que sur une antiquité.

Mais non, .NET débarque.

Avec un processeur virtuel.

Un interpréteur se charge de traduire les 0 et les 1 d'un fichier executable, le résultat de l'interprétation et l'interpréteur étant eux même en natif: le seul vrai processeur ne connaît que ça !

Prenez une F1, arrimez là sur un chassis (bas de caisse, roues) d'une autre F1. Connectés les roues de la F1 qui a un moteur à celle qui n'en à pas, et faîte roulez le tout.
Vous aurez du mal à faire du 380 (Je sais, j'y connais rien en F1).

Bon, java étant les possibilitées puisque le chassis rajoutés fait aussi bien du rallye que du bitume.

Mais pour .NET, là je comprend pas.

Les processeurs seraient-ils devenus tellement rapide que l'on peut se permettre de faire attendre les gens ?

Dans 5 ans, Microsoft vat-il nous proposer un processeur virtuel tournant sur .NET tournant sous IA32 ?

Et Age of Empire III, ils l'ont fait en .NET peut être?
(Si oui, je suis déscrédité !)

Et pour la comparaison avec le DOS, je comprend pas. DOS et Windows, ce sont des systèmes d'exploitation. Windows a apporté une interface conviviale. .NET n'apporte rien. (du moins sur le plan du résultat, mais c'est vrai qu'y a quand même de bonnes idées, genre de plus s'orienter objet).

.NET, c'est comme java, sauf que c'est moins portable.

[Merlin]

C'est un vieux thread qui ne bouge plus depuis novembre, mais bon je passais dessus par hasard. Et en fait je me suis tâté, mais ça m'embete de laisser passer des grosses bêtises pareilles sans une réponse derrière.
Il y a plein de gens qui viennent ici pour s'informer malgré tout...

Donc bon, tout le monde s'en fichera certainement, vu que ça fait trois mois que le thread prend la poussière mais je serais soulagé :-)

Le processeur mange des 0 et des 1.

Non, il "mange" des instructions sur 1 ou plusieurs octets.
Les ordinateurs travaillant bit par bit ça n'existe plus depuis les années 50 environ :-)

Bref, le compilo de Delphi 7 et précédent compile en 0 et en 1 qui sont chargés tel quel par le loader de Windows, puis l'execution commence, et les 0 et les 1 vont arriver tel quel au processeur.

non, Delphi ou autre compilo win32 compile en langage machine, qui associe des codes de 1 à plusieurs octets qui sont des instructions que le microprocesseur doit interpréter...

Mais non, .NET débarque.
Avec un processeur virtuel.

non, .NET n'a pas de processeur virtuel.
Il met juste en place un langage pivot dans lequel les compilateurs génère leur code au lieu de générer du code machine.
Ceci permet la portabilité du code compilé. Car sur la machine cible ce langage pivot est à nouveau compilé avant d'être exécuté. Et cette fois ci il est compilé en langage machine.
Un logiciel .NET qui tourne sur une machine est donc toujours compilé en langage machine, ce qui ne fait donc aucune différence avec les compilos win32 "classiques" par exemple.
Lors de la première utilisation d'une classe il y a juste un petit délai pour la compilation en langage machine. Il est même possible de pré-compiler natif pour une cible donnée, ce qui évite même ce petit temps perdu lors de la première utilisation.

Un interpréteur se charge de traduire les 0 et les 1 d'un fichier executable, le résultat de l'interprétation et l'interpréteur étant eux même en natif: le seul vrai processeur ne connaît que ça !

non, il n'y a aucun interpréteur. voir ci-dessus.

Bon, java étant les possibilitées puisque le chassis rajoutés fait aussi bien du rallye que du bitume.

non, java n'étend rien du tout. Au contraire, c'est un langage qui lui est à la base interprété donc très lent. Des compilateurs sont venus après compléter le tableau mais ce sont des verrues sur un langage initialement interprété. De plus la compilation devient native alors que la compilation .NET permet de rester multi plate-forme...

Mais pour .NET, là je comprend pas.

rassure toi, ça se voit :-)

Les processeurs seraient-ils devenus tellement rapide que l'on peut se permettre de faire attendre les gens ?

non, on ne fait attendre personne le code exécuté est natif de la plate forme, systématiquement, sans interprétation.

Dans 5 ans, Microsoft vat-il nous proposer un processeur virtuel tournant sur .NET tournant sous IA32 ?

non, aucun intérêt. L'intérêt de .NET c'est justement de pouvoir compiler tout en restant portable.
A l'heure actuelle une code .NET peut fonctionner sous Windows, Linux, Windows CE, etc. C'est l'avenir : justement pas de processeur dédié, mais un langage pivot et un petit bout de compilo qui sait traduire ce langage pivot dans le langage natif de chaque machine. Comme ça le langage ne freine pas les évolutions hardware et il n'est pas à la traîne sur ces évolutions non plus.

Et pour la comparaison avec le DOS, je comprend pas. DOS et Windows, ce sont des systèmes d'exploitation. Windows a apporté une interface conviviale. .NET n'apporte rien. (du moins sur le plan du résultat, mais c'est vrai qu'y a quand même de bonnes idées, genre de plus s'orienter objet).

Win32 n'apporte rien de visuel par rapport à win16. Pourtant tout le monde a préféré passé à Win32 en raison de nombreux apports en terme de qualité et de services rendus.
.NET c'est pareil.

Tu cites les programmes de jeu, tu dis que .NET n'apporte rien au niveau interface. Je déduis que tu es très jeune et que pour toi un ordinateur c'est avant un truc pour jouer, frimer ses potes avec des graphiques de la mort qui tue.
Quand tu auras muri un peu, tu verras qu'un ordinateur est une machine qui sert, heureusement, à des choses plus sérieuses qu'épater la galerie avec des animations et que dès lors, faire des logiciels professionnels de meilleure qualité impose de faire évoluer ce qui ne soit pas au premier coup d'oeil, en tout cas pour un accro de console de jeu... .NET est une évolution de ce type et elle est essentielle.

.NET, c'est comme java, sauf que c'est moins portable.

Non, .NET et Java n'ont en réalité rien en commun. L'un est à la pointe de la technologie, l'autre est déjà une antiquité...

[rt15]

C'est vrai que j'y étais allé un peu fort.
Je m'excuse.
Voila qui devrait relever un peu le niveau du débat :

Non, il "mange" des instructions sur 1 ou plusieurs octets.
Les ordinateurs travaillant bit par bit ça n'existe plus depuis les années 50 environ :-)

C'est une question de point de vue.
Par exemple, quand une appli souhaite demander au proce de ne rien faire (Autrefois parfois utilisé pour temposriser le flux) on peut considéré que l'on envoie au processeur:

NOP (assembleur)
90 (hexa, la représentation classique d'un octet)
1001 0000 (binaire)

Et les processeurs actuels sont surtout composés de transistors, donc ne travaillent que sur des 0 et des 1 du point de vue de l'électronicien.

non, .NET n'a pas de processeur virtuel.
Il met juste en place un langage pivot dans lequel les compilateurs génère leur code au lieu de générer du code machine.
Ceci permet la portabilité du code compilé. Car sur la machine cible ce langage pivot est à nouveau compilé avant d'être exécuté. Et cette fois ci il est compilé en langage machine.
Un logiciel .NET qui tourne sur une machine est donc toujours compilé en langage machine, ce qui ne fait donc aucune différence avec les compilos win32 "classiques" par exemple.
Lors de la première utilisation d'une classe il y a juste un petit délai pour la compilation en langage machine. Il est même possible de pré-compiler natif pour une cible donnée, ce qui évite même ce petit temps perdu lors de la première utilisation.

Avec .NET, Microsoft introduit sa première machine virtuelle. Très proche des concepts de la Java Virtual Machine (JVM), le Common Language Runtime (CLR) se charge d’exécuter les applications précompilées dans un langage intermédiaire (Microsoft Intermediate Language ou MSIL).

Le rapport entre Java et la CLR c'est bonnet blanc et blanc bonnet. Compilation Just In Time= Compilation à la volée = Compilation à l'execution = Moins performant

A l'heure actuelle une code .NET peut fonctionner sous Windows, Linux, Windows CE, etc.

A l'heure actuelle ce n'est pas vrai. La compatibilité avec mono nécessite vraiment des précautions importantes.

C'est l'avenir : justement pas de processeur dédié, mais un langage pivot et un petit bout de compilo qui sait traduire ce langage pivot dans le langage natif de chaque machine. Comme ça le langage ne freine pas les évolutions hardware et il n'est pas à la traîne sur ces évolutions non plus.

Le langage universel est un vieux rêve. Mais la prog a passablement évolué depuis sa naissance. Evenementiel, objet, de nos jour la monté en puissance des services web... Le langage intermédiaire de MS est moins bien armé que l'assembleur pour affronter ces évolutions: il est plus spécialisé.

Tu cites les programmes de jeu, tu dis que .NET n'apporte rien au niveau interface. Je déduis que tu es très jeune et que pour toi un ordinateur c'est avant un truc pour jouer, frimer ses potes avec des graphiques de la mort qui tue.
Quand tu auras muri un peu, tu verras qu'un ordinateur est une machine qui sert, heureusement, à des choses plus sérieuses qu'épater la galerie avec des animations et que dès lors, faire des logiciels professionnels de meilleure qualité impose de faire évoluer ce qui ne soit pas au premier coup d'oeil, en tout cas pour un accro de console de jeu... .NET est une évolution de ce type et elle est essentielle.

A l'heure actuelle, la puissance des processeurs n'augmente plus autant qu'avant. On arrive dans les limites du silicium, et passer à une autre technologie prendra du temps. L'homme à tendance à préférer les systèmes les plus rapide, que ce soit pour les jeux, mais aussi pour des appli de calcul de rdm, pour des accès à des bases de données... Si un logiciel à besion d'être rapide, les développeur peuvent choisir de le compiler directement en natif, de simple peur qu'un concurrent le fasse à leur place, et proposent ainsi une appli plus performante (Et d'aspect équivalent), remporte le marché.

[Merlin]

C'est vrai que j'y étais allé un peu fort.
Je m'excuse.

un peu fort, oui, c'est l'expression qui va bien :-)

Voila qui devrait relever un peu le niveau du débat :

.. en tout cas ça réveille le thread c'est déjà pas mal :-)

C'est une question de point de vue.
Par exemple, quand une appli souhaite demander au proce de ne rien faire (Autrefois parfois utilisé pour temposriser le flux) on peut considéré que l'on envoie au processeur:

non, c'est pas une question de point de vue, c'est juste que tu es de très mauvaise foi :-)
Si justement il y a eu des tentatives pour développer des processeurs RISC c'est parce que justement les processeurs CISC classiques supportent un jeu d'instruction de plus en plus complexe et lourd et que la _majorité_ des instructions réclament 2, 3 , voire 8 ou 10 octets.
Le fait qu'un NOP qui est une vieille instruction portant donc un "numéro" très petit dans le jeu d'instruction existe encore par nécessité ne démontre rien. La plupart des applications compilées contiennent généralement plus d'instructions longues que des NOP :-)

Et les processeurs actuels sont surtout composés de transistors, donc ne travaillent que sur des 0 et des 1 du point de vue de l'électronicien.

Un cpu est autant constitué de transistors que de résistances et de condensateurs... tirer des conclusions sur l'ensemble en prenant comme exemple que l'un des composants est déjà une erreur. De plus comme un chimie, le corp composé n'a pas les caractéritiques de ces composants... (l'eau c'est vraiment pas pareil que l'oxygene ou l'hydrogene pris séparément..).
Enfin, les transistors ne travaillent absolument pas avec des 0 ou des 1, ce sont au contraire des composants capables de moduler une source en fonction d'une tension de commande. Ils sont les rois de l'analogique, on les retrouve dans les amplificateurs, les gradateurs, etc...
Le fait de les faire fonctionner en mode "tout ou rien" est une astuce electronique, mais ce n'est pas la nature du transistor :-)

Enfin, un cpu est constitué de millions de composants qui forment des portes logiques et plein d'autres structures qui se déclenchent, justement sur la réception d'instructions complexes. Qu'en interne ça soit des 0 ou des 1 n'y changent rien : le cpu ne comprend pas les 0 et 1 mais uniquement des instructions complexes...

C'est un peu comme si tu disais "ma voiture à un moteur dont le principe repose sur des explosions de vapeur d'essence, donc le meilleur moyen de faire avancer ma voiture c'est directement de faire des explosions dans le réservoir"... tu peux essayer, mais prend une bonne assurance avant :-)

Avec .NET, Microsoft introduit sa première machine virtuelle. Très proche des concepts de la Java Virtual Machine (JVM), le Common Language Runtime (CLR) se charge d’exécuter les applications précompilées dans un langage intermédiaire (Microsoft Intermediate Language ou MSIL).

Cet article est un ramassis d'aneries... il y a aussi plein de coneries sur le web, faut pas tout prendre à la lettre :-)

Le rapport entre Java et la CLR c'est bonnet blanc et blanc bonnet. Compilation Just In Time= Compilation à la volée = Compilation à l'execution = Moins performant

C'est une contre vérité technique comme je te l'ai expliqué. Si tu persistes tu passeras pour idiot en société :-)
Il n'y a aucune machine virtuelle sous .NET et la compilation à la volée des classes Java interprétée ne ressemble en rien à la compilation native réalisée par le CLR lors de la première utilisation d'une classe.
Il y a certes de vagues similitudes mais un technicien ne fonde pas ses conclusions sur de "vagues similitudes"...

A l'heure actuelle ce n'est pas vrai. La compatibilité avec mono nécessite vraiment des précautions importantes.

Ce n'est pas parce qu'il y a des précautions à prendre que ça ne marche pas...
Quand on développe on fait quoi d'autre que de prendre des précautions... et pourtant ça marche :-)

Le langage universel est un vieux rêve. Mais la prog a passablement évolué depuis sa naissance. Evenementiel, objet, de nos jour la monté en puissance des services web... Le langage intermédiaire de MS est moins bien armé que l'assembleur pour affronter ces évolutions: il est plus spécialisé.

MS n'a pas voulu créer de langages universel... Et CIL est tout aussi armé que l'assembleur, même mieux puisqu'il est plus moderne et prend plus en compte les réels besoins des applications.

Mais de toute façon, personne, à moins d'être naif, ne dit que .NET est là pour la fin des temps... Les technos ne durent guère plus de 10 ans.
En 2016 MS sortira autre chose, qui sera "mieux"...
Mais cela laisse 10 ans à venir de supériorité techniques pour .NET, c'est déjà pas mal :-)

A l'heure actuelle, la puissance des processeurs n'augmente plus autant qu'avant. On arrive dans les limites du silicium, et passer à une autre technologie prendra du temps

Mais non. IBM notamment à publier dernièrement les résultats de certaines de ses recherches qui prouvent que la loi de Moore restera vraie pour les 10 ans à venir encore...

Donc tu vois, au moins durant toute la durée de vie de .NET on est garanti que ça sera comme avant :-)

L'homme à tendance à préférer les systèmes les plus rapide, que ce soit pour les jeux, mais aussi pour des appli de calcul de rdm, pour des accès à des bases de données... Si un logiciel à besion d'être rapide, les développeur peuvent choisir de le compiler directement en natif, de simple peur qu'un concurrent le fasse à leur place, et proposent ainsi une appli plus performante (Et d'aspect équivalent), remporte le marché.

C'est pas faux. Et c'est bien pour cela que .NET qui compile en natif permet d'avoir le meilleur de tous les mondes : un code compilé portable en langage pivot et une compilation native offrant des performances égales à n'importe quel compilo natif...

[rt15]

Qu'en interne ça soit des 0 ou des 1 n'y changent rien : le cpu ne comprend pas les 0 et 1 mais uniquement des instructions complexes...

C'est un peu comme si tu disais "ma voiture à un moteur dont le principe repose sur des explosions de vapeur d'essence, donc le meilleur moyen de faire avancer ma voiture c'est directement de faire des explosions dans le réservoir"... tu peux essayer, mais prend une bonne assurance avant :-)

Bin je le répète, c'est une question de point de vue... On peut même descendre un peu plus bas : On peut dire que les transistors sont composés de semi-conducteurs dopés P et N, et que ce sont avant tout des électrons, et pas des 0 et des 1 qui circulent dedans. Plus bas par contre, je serais pas descendre.

Mais c'est vrai que du point de vue du prog on peut considérer que le processeur travail sur des instructions assembleur codées sur 1 ou plus octets. (Leur taille en octet n'aillant d'ailleurs rien à voir avec le temps nécessaire à les executer).

Cet article est un ramassis d'aneries... il y a aussi plein de coneries sur le web, faut pas tout prendre à la lettre :-)

Tu n'aimes pas cette article ? Moi non plus. J'aurais dû mettre ça directement :

La Common Language Runtime (CLR) est un environnement d'exécution sécurisé et robuste qui supporte du code écrit dans plusieurs langages différents (C++, VB, C#, Pascal, Cobol ...) et simplifie le développement, la gestion et le déploiement d'applications. On peut la comparer à la Java Virtual Machine (JVM) ou au Runtime Visual Basic 6 (msvbvm60.dll).

Il n'y a aucune machine virtuelle sous .NET et la compilation à la volée des classes Java interprétée ne ressemble en rien à la compilation native réalisée par le CLR lors de la première utilisation d'une classe.

La compilation JIT n'est pas réalisée classe par classe mais fonction par fonction par la runtime. Voilà un cour plutôt pro sur le sujet :
rmdiscala.free.fr/livres/CsharpPart1.pdf

Ce n'est pas parce qu'il y a des précautions à prendre que ça ne marche pas...
Quand on développe on fait quoi d'autre que de prendre des précautions... et pourtant ça marche :-)

Tu as essayé ? Parce qu'apparement, la CLR galope et mono fait ce qu'il peut pour suivre le rythme: pas mal d'API ne sont pas encore implémentées. Et MS est vraiment désagréable vis à vis de ce projet.
http://www.mono-project.com/FAQ:_Technical

Mais non. IBM notamment à publier dernièrement les résultats de certaines de ses recherches qui prouvent que la loi de Moore restera vraie pour les 10 ans à venir encore...

A tient vi :
http://www.pcinpact.com/actu/news/26813-Une-percee-dIBM-qui-sauverait-la-loi-de-Moor.htm

C'est pas faux. Et c'est bien pour cela que .NET qui compile en natif permet d'avoir le meilleur de tous les mondes : un code compilé portable en langage pivot et une compilation native offrant des performances égales à n'importe quel compilo natif...

Le pb, c'est que la compilation se fait à l'execution. Rien que de ce fait, on peut remettre en question la qualité de la compilation. La CLR a des contraintes de temps de compilation que les compilos classiques ont nettement moins. Un autre problème est la compatibilité: Des applications compilée pour la 1.1 ont crashées quand ont à essayé de les faire tourner sur la 2.0. Ce type de problème à pas mal de chance de se compliquer au file des versions...

[femtosa]

Après avoir parcouru ce "vieux" thread, j'en reviens au titre original qui était "Delphi ? version présentes et futures ? Pourquoi dotnet ?" ... Sans descendre jusqu'à la composition d'un microprocesseur ...

J'ai lu également ce thread qui parle des retours d'expériences avec Delphi.NET.

A en croire la dates des derniers messages postés dans ces débats, Delphi.NET n'as pas encore vraiment pris ? Qu'en ai-t-il maintenant, dans la deuxième moitié de l'année 2007 ?

Et que pensez-vous de l'arrivée de Vista ? Mettra-t-il fin à Delphi win32 ? Faut-il absolument passé à Delphi.NET lorsqu'on vise, en plus de Windows2000/XP, Windows Vista ?

Je n'ai testé Delphi.NET qu'une après-midi () et je dois prendre la décision d'utiliser Delphi 2006 ou rester sur Delphi7 pour développer une application qui est destiné à une durée de vie de 5 ans minimum ... ! Que faire ... ?

[gb_68]

Delphi n'est pas passé exclusivement vers le .Net après Delphi 7 (j'ai l'impression que beaucoup pense que Delphi est passé au .Net comme VB, en oubliant le reste).

Depuis Delphi 2005, il est possible de faire du Delphi pour Win32 et/ou du Delphi .Net. On peut les voir comme deux langages différents, l'un pour le natif, l'autre pour le .Net. Mais Borland/CodeGear essaye de les maintenir les plus proches possibles en minimisant leurs différences, si bien qu'on est quasiment face à un unique langage compilable à la fois vers Win32 et .Net.

D'ailleurs à ma connaissance, il n'y a pas d'autre langage capable qui permette de créer aussi facilement des applications compilables vers ces deux plateformes.

Et que pensez-vous de l'arrivée de Vista ? Mettra-t-il fin à Delphi win32 ? Faut-il absolument passé à Delphi.NET lorsqu'on vise, en plus de Windows2000/XP, Windows Vista ?

La dernière version de Delphi (2007) n'est pour l'instant sortie que pour le Win32.
Elle permet de développer des applications pour Vista/Xp/2000 natives, fonctionnant sans le framework .Net (et donc sans garbage collector).
http://www.codegear.com/products/delphi/win32

Delphi for Win32 is the only IDE that supports creating native code applications compatible with Windows 2000, XP, AND Vista.

Il y a parfois une confusion avec les pré-requis qui demandent le Microsoft .NET Framework 2.0 ; ce n'est que pour l'IDE. Les applications seront bien natives Win32.

[femtosa]

Delphi n'est pas passé exclusivement vers le .Net après Delphi 7 (j'ai l'impression que beaucoup pense que Delphi est passé au .Net comme VB, en oubliant le reste).

Effectivement, je faisait partie de ces personnes ! Je pensais qu'à partir de Delphi 2005, l'accent était sévèrement mis sur .NET !

Depuis Delphi 2005, il est possible de faire du Delphi pour Win32 et/ou du Delphi .Net. On peut les voir comme deux langages différents, l'un pour le natif, l'autre pour le .Net. Mais Borland/CodeGear essaye de les maintenir les plus proches possibles en minimisant leurs différences, si bien qu'on est quasiment face à un unique langage compilable à la fois vers Win32 et .Net. ... La dernière version de Delphi (2007) n'est pour l'instant sortie que pour le Win32.

Voilà une vision des choses très intelligente de la part de Borland je trouve ! C'est très bien pour le future des deux langages, un passage progressive est en marche !

Merci beaucoup pour tes informations et ton avis gb_68 !

[Laurent Dardenne]

Femtosa tu devrais lire, si ce n'ai déjà fait, les interviews de la rubrique Delphi ainsi que les articles sur les évolutions du langage et de l'EDI.

[Yepazix]

Woulaaaaaa les gars, je viens de lire tout ce sujet.... Attendez une minute j'arrive.....


Ah ça va mieu maintenant que je me suis envoyé une demi boite de Dafalgan.
Faut vous dire que quand on est pas un informateux c'est un peu

pour moi le PC c'est une boite magique remplie de petits lutins qui font se qu'on leur demande quand on leur parle en Delphi, alors vos trucs de processeurs qui allignent des électrons et des transistors pour faire des bits sur des octets et tout ce bazard... dur !

Donc pour revenir sur Delphi et ses versions la vrai question que je me pose et qui ne fait que s'embrouiller plus encore à la lecture de ce forum c'est :

Il y a quelques mois (années ?) je faisais des petits programmes gentils avec Delphi 5 puis Delphi 7.
Une nouvelle version de Delphi était sortie ensuite (je sais plus son nom) avec une interface toute différente. A l'époque ça me semblait lours, compliqué, bref en un mot chiant et j'ai laissé tombé.
Aujourd'hui motivé par un besoin (je voudrais faire une apli qui fusionne des sous-calendriers Outlook dans le calendrier principal) je me dis que je m'y remetrais bein. Seulement voila entre temps le "bordel" dans les versions de Delphi n'a fait que s'agraver. Je pige plus rien !
Y faut lequel et pour faire quoi ?
L'OS a t'il une importance (en ce qui me concerne c'est Outlook 2007 et Vista).
Etc...
Bref, simple, conscis... Clair quoi ;-)