Par contre, sans doute parce qu'il n'est pas édité par MS, Delphi est peu
utilisé comparativement aux languages .NET de Microsoft (C#, C++ et
VB.NET).
Par contre, sans doute parce qu'il n'est pas édité par MS, Delphi est peu
utilisé comparativement aux languages .NET de Microsoft (C#, C++ et
VB.NET).
Par contre, sans doute parce qu'il n'est pas édité par MS, Delphi est peu
utilisé comparativement aux languages .NET de Microsoft (C#, C++ et
VB.NET).
meilleur de chaque "école de pensée synthaxique".
meilleur de chaque "école de pensée synthaxique".
meilleur de chaque "école de pensée synthaxique".
>Hé oh, C++ n'est pas un langage NET !!
>Hé oh, C++ n'est pas un langage NET !!
>Hé oh, C++ n'est pas un langage NET !!
Hé oh, C++ n'est pas un langage NET !!
Hé oh, C++ n'est pas un langage NET !!
Hé oh, C++ n'est pas un langage NET !!
[...]
Je trouve ici que tu généralises rapidement sans avoir vraiment testé,
pourtant, c'est très rare dans ton cas...
Pour moi, le .NET Framework, c'est une des plus belles choses qui soit
arrivée dans l'environnement Windows.
Je comprend ton point de vue, probablement parce que tu es habitué au
Delphi, plate-forme de développement bien en avance sur son temps en
termes d'ergonomie et de fonctionnalités.
Par contre, sans doute parce qu'il n'est pas édité par MS, Delphi est peu
utilisé comparativement aux languages .NET de Microsoft (C#, C++ et
VB.NET).
[...]
L'arrivé du .NET framework, avec un compilateur en ligne de commande inclu
en bonus, sans installation de suite de développement a apporté plusieurs
avantages:
- Le langage C#, qui est le langage le plus "fun" à programmer, beau
mélange de syntaxe entre VB, C++ et Java, MS a selon moi, réussi à
intégrer le meilleur de chaque "école de pensée synthaxique".
- Le CLR (Common Langage Runtime), qui permet entre autre, de compiler des
applications identiques, qu'elles soient développées en C#, C++ et VB.NET.
- Une manière beaucoup plus simple et intuitive pour le programmeur
d'accéder aux API de Windows, en mode orienté objet.
- Une intégration très réussie du point de vue développeur (avec des
"Namesspaces" très complets et intuitifs).
Quand je développe en .NET, je ne publie que les exe, qui sont
généralement très petits, à moins d'y avoir inclu une multitude de
ressources multimédia ;-)
Exempel récent, sur une de mes babasses, sous VISTA, je n'ai pas réussi à
installer "XMLNotepad", un outil de Microsoft qui permet d'éditer
simplement des fichiers XML.
Quand je veux l'installer, j'ai droit à une injurebox
".NET Framework 2.0 doit être installé au préalable."
MAIS quand je lance le setup de .NET Framework 2.0 (dotnetfx.exe), j'ai
droit à une autre injurebox
".NET Framework 2.0 est déjà installé !"
http://www.cijoint.fr/cj200905/cijq2u7gMR.jpg
Vraiment bizarre, je n'ai jamais rencontré une telle erreur,
dans <DisqueSysteme>:WINDOWSMicrosoft.NETFramework,
quelles versions sont installées?
Je comprend tes frustrations... mais... bouse n'est pas un peu fort?
Pour une fois que Microsoft crée des API simples, efficaces et intuitifs?
(En passant, je ne suis pas un "vendu" Microsoft, j'écris à partir d'une
machine virtuelle hébergée dans mon placard sur un VMWare server sur
Fedora 10)...
Mais en tant que simple client contraint et forcé d'utiliser cette
saloperie, si quelqu'un(e) pouvait m'indiquer un moyen efficace pour la
remettre en état, je lui en serais éternellement reconnaissant ! :-)
Est-ce que le .NET Framework 2.0 apparaît quand tu vas sur Windows Update?
Est-ce qu'il apparaît dans le gestionnaire des programmes?
Essaie de voir de ce côté (je pense que je n'ai pas à t'indiquer quelles
clés de registres concernent les programmes et MAJ installés ;-)
Aussi, tu peux valider la clé suivante:
HKLMSOFTWAREMicrosoft.NETFrameworkpolicy
(cf.: http://www.codeproject.com/KB/mcpp/DotNetTester.aspx)
[...]
Je trouve ici que tu généralises rapidement sans avoir vraiment testé,
pourtant, c'est très rare dans ton cas...
Pour moi, le .NET Framework, c'est une des plus belles choses qui soit
arrivée dans l'environnement Windows.
Je comprend ton point de vue, probablement parce que tu es habitué au
Delphi, plate-forme de développement bien en avance sur son temps en
termes d'ergonomie et de fonctionnalités.
Par contre, sans doute parce qu'il n'est pas édité par MS, Delphi est peu
utilisé comparativement aux languages .NET de Microsoft (C#, C++ et
VB.NET).
[...]
L'arrivé du .NET framework, avec un compilateur en ligne de commande inclu
en bonus, sans installation de suite de développement a apporté plusieurs
avantages:
- Le langage C#, qui est le langage le plus "fun" à programmer, beau
mélange de syntaxe entre VB, C++ et Java, MS a selon moi, réussi à
intégrer le meilleur de chaque "école de pensée synthaxique".
- Le CLR (Common Langage Runtime), qui permet entre autre, de compiler des
applications identiques, qu'elles soient développées en C#, C++ et VB.NET.
- Une manière beaucoup plus simple et intuitive pour le programmeur
d'accéder aux API de Windows, en mode orienté objet.
- Une intégration très réussie du point de vue développeur (avec des
"Namesspaces" très complets et intuitifs).
Quand je développe en .NET, je ne publie que les exe, qui sont
généralement très petits, à moins d'y avoir inclu une multitude de
ressources multimédia ;-)
Exempel récent, sur une de mes babasses, sous VISTA, je n'ai pas réussi à
installer "XMLNotepad", un outil de Microsoft qui permet d'éditer
simplement des fichiers XML.
Quand je veux l'installer, j'ai droit à une injurebox
".NET Framework 2.0 doit être installé au préalable."
MAIS quand je lance le setup de .NET Framework 2.0 (dotnetfx.exe), j'ai
droit à une autre injurebox
".NET Framework 2.0 est déjà installé !"
http://www.cijoint.fr/cj200905/cijq2u7gMR.jpg
Vraiment bizarre, je n'ai jamais rencontré une telle erreur,
dans <DisqueSysteme>:WINDOWSMicrosoft.NETFramework,
quelles versions sont installées?
Je comprend tes frustrations... mais... bouse n'est pas un peu fort?
Pour une fois que Microsoft crée des API simples, efficaces et intuitifs?
(En passant, je ne suis pas un "vendu" Microsoft, j'écris à partir d'une
machine virtuelle hébergée dans mon placard sur un VMWare server sur
Fedora 10)...
Mais en tant que simple client contraint et forcé d'utiliser cette
saloperie, si quelqu'un(e) pouvait m'indiquer un moyen efficace pour la
remettre en état, je lui en serais éternellement reconnaissant ! :-)
Est-ce que le .NET Framework 2.0 apparaît quand tu vas sur Windows Update?
Est-ce qu'il apparaît dans le gestionnaire des programmes?
Essaie de voir de ce côté (je pense que je n'ai pas à t'indiquer quelles
clés de registres concernent les programmes et MAJ installés ;-)
Aussi, tu peux valider la clé suivante:
HKLMSOFTWAREMicrosoft.NETFrameworkpolicy
(cf.: http://www.codeproject.com/KB/mcpp/DotNetTester.aspx)
[...]
Je trouve ici que tu généralises rapidement sans avoir vraiment testé,
pourtant, c'est très rare dans ton cas...
Pour moi, le .NET Framework, c'est une des plus belles choses qui soit
arrivée dans l'environnement Windows.
Je comprend ton point de vue, probablement parce que tu es habitué au
Delphi, plate-forme de développement bien en avance sur son temps en
termes d'ergonomie et de fonctionnalités.
Par contre, sans doute parce qu'il n'est pas édité par MS, Delphi est peu
utilisé comparativement aux languages .NET de Microsoft (C#, C++ et
VB.NET).
[...]
L'arrivé du .NET framework, avec un compilateur en ligne de commande inclu
en bonus, sans installation de suite de développement a apporté plusieurs
avantages:
- Le langage C#, qui est le langage le plus "fun" à programmer, beau
mélange de syntaxe entre VB, C++ et Java, MS a selon moi, réussi à
intégrer le meilleur de chaque "école de pensée synthaxique".
- Le CLR (Common Langage Runtime), qui permet entre autre, de compiler des
applications identiques, qu'elles soient développées en C#, C++ et VB.NET.
- Une manière beaucoup plus simple et intuitive pour le programmeur
d'accéder aux API de Windows, en mode orienté objet.
- Une intégration très réussie du point de vue développeur (avec des
"Namesspaces" très complets et intuitifs).
Quand je développe en .NET, je ne publie que les exe, qui sont
généralement très petits, à moins d'y avoir inclu une multitude de
ressources multimédia ;-)
Exempel récent, sur une de mes babasses, sous VISTA, je n'ai pas réussi à
installer "XMLNotepad", un outil de Microsoft qui permet d'éditer
simplement des fichiers XML.
Quand je veux l'installer, j'ai droit à une injurebox
".NET Framework 2.0 doit être installé au préalable."
MAIS quand je lance le setup de .NET Framework 2.0 (dotnetfx.exe), j'ai
droit à une autre injurebox
".NET Framework 2.0 est déjà installé !"
http://www.cijoint.fr/cj200905/cijq2u7gMR.jpg
Vraiment bizarre, je n'ai jamais rencontré une telle erreur,
dans <DisqueSysteme>:WINDOWSMicrosoft.NETFramework,
quelles versions sont installées?
Je comprend tes frustrations... mais... bouse n'est pas un peu fort?
Pour une fois que Microsoft crée des API simples, efficaces et intuitifs?
(En passant, je ne suis pas un "vendu" Microsoft, j'écris à partir d'une
machine virtuelle hébergée dans mon placard sur un VMWare server sur
Fedora 10)...
Mais en tant que simple client contraint et forcé d'utiliser cette
saloperie, si quelqu'un(e) pouvait m'indiquer un moyen efficace pour la
remettre en état, je lui en serais éternellement reconnaissant ! :-)
Est-ce que le .NET Framework 2.0 apparaît quand tu vas sur Windows Update?
Est-ce qu'il apparaît dans le gestionnaire des programmes?
Essaie de voir de ce côté (je pense que je n'ai pas à t'indiquer quelles
clés de registres concernent les programmes et MAJ installés ;-)
Aussi, tu peux valider la clé suivante:
HKLMSOFTWAREMicrosoft.NETFrameworkpolicy
(cf.: http://www.codeproject.com/KB/mcpp/DotNetTester.aspx)
> Si, si, j'ai testé, j'ai même écrit des applis en .NET dès sa sortie, mais
çà ne m'a pas du tout convaincu ...
Et tu dois savoir que j'aime bien arborer une attitude provoc' ! ;-)
Ce n'est pas çà le problème !
En Delphi, ".NET" existe aussi !
J'ai le choix, quand je lance Delphi, entre "Delphi Win32" et "Delphi
.NET"
Le 1er fait appel aux API bien gentilles de Windows ,
Le 2ème passe par .NET Framework, et le mécanisme est le même (avec CLR,
...) qu'en C#, VB NET, ou autre langage ".NET"
Mais les 1ères versions d'API Windows (Win16 ou WIn32) étaient déjà
orientées objet, au moins dans leur esprit. Le plus bel exemple étant les
classes de fenêtres.
Et en ce qui concerne Delphi, c'est Orienté Objet à fond, avec ou sans
.NET.
- Une intégration très réussie du point de vue développeur (avec des
"Namesspaces" très complets et intuitifs).
Idem pour moi sans .NET !
Quand je développe en .NET, je ne publie que les exe, qui sont
généralement très petits, à moins d'y avoir inclu une multitude de
ressources multimédia ;-)
.NET, c'est de la pub mensongère ! ;-)
On fait croire que les applis sont toutes petites, ce qui est souvent vrai
mais uniquement pour l'exe de base, car EN RÉALITÉ il faut se trimballer
une méga usine à gaz avec le Framework , qui n'est rien d'autre qu'un
niveau intermédiaire entre les applis et les API Windows .
Il suffit de comparer les espaces mémoire occupés par une appli avec .NET
et la même écrite en "Win32" ...
Tout comme une appli écrite en assembleur sera nettement plus économique
(à moins de programmer comme une pantoufle) que son homologue écrite avec
un langage évolué.
C'est logique, quand on insère une interface supplémentaire, on ajoute
plein de trucs inutilisés, donc inutiles.
Je me satisfait à 100% de Shell32, de NetAPI32 (même si les fonctions
réseau rament à mort)
P.ex. depuis un programme Delphi je n'ai JAMAIS été bloqué pour appeler
une fonction dont je n'avais que la syntaxe en C, la transcription étant
nasodigitale.
(En passant, je ne suis pas un "vendu" Microsoft, j'écris à partir d'une
machine virtuelle hébergée dans mon placard sur un VMWare server sur
Fedora 10)...
:-)
Je suis un fan de VMWare depuis le 11 avril 2000 !!!
Mais j'utilise aussi VPC 2007...
Cela me dit quelque chose ....
Je vais lancer une session distante pour voir ...
> Si, si, j'ai testé, j'ai même écrit des applis en .NET dès sa sortie, mais
çà ne m'a pas du tout convaincu ...
Et tu dois savoir que j'aime bien arborer une attitude provoc' ! ;-)
Ce n'est pas çà le problème !
En Delphi, ".NET" existe aussi !
J'ai le choix, quand je lance Delphi, entre "Delphi Win32" et "Delphi
.NET"
Le 1er fait appel aux API bien gentilles de Windows ,
Le 2ème passe par .NET Framework, et le mécanisme est le même (avec CLR,
...) qu'en C#, VB NET, ou autre langage ".NET"
Mais les 1ères versions d'API Windows (Win16 ou WIn32) étaient déjà
orientées objet, au moins dans leur esprit. Le plus bel exemple étant les
classes de fenêtres.
Et en ce qui concerne Delphi, c'est Orienté Objet à fond, avec ou sans
.NET.
- Une intégration très réussie du point de vue développeur (avec des
"Namesspaces" très complets et intuitifs).
Idem pour moi sans .NET !
Quand je développe en .NET, je ne publie que les exe, qui sont
généralement très petits, à moins d'y avoir inclu une multitude de
ressources multimédia ;-)
.NET, c'est de la pub mensongère ! ;-)
On fait croire que les applis sont toutes petites, ce qui est souvent vrai
mais uniquement pour l'exe de base, car EN RÉALITÉ il faut se trimballer
une méga usine à gaz avec le Framework , qui n'est rien d'autre qu'un
niveau intermédiaire entre les applis et les API Windows .
Il suffit de comparer les espaces mémoire occupés par une appli avec .NET
et la même écrite en "Win32" ...
Tout comme une appli écrite en assembleur sera nettement plus économique
(à moins de programmer comme une pantoufle) que son homologue écrite avec
un langage évolué.
C'est logique, quand on insère une interface supplémentaire, on ajoute
plein de trucs inutilisés, donc inutiles.
Je me satisfait à 100% de Shell32, de NetAPI32 (même si les fonctions
réseau rament à mort)
P.ex. depuis un programme Delphi je n'ai JAMAIS été bloqué pour appeler
une fonction dont je n'avais que la syntaxe en C, la transcription étant
nasodigitale.
(En passant, je ne suis pas un "vendu" Microsoft, j'écris à partir d'une
machine virtuelle hébergée dans mon placard sur un VMWare server sur
Fedora 10)...
:-)
Je suis un fan de VMWare depuis le 11 avril 2000 !!!
Mais j'utilise aussi VPC 2007...
Cela me dit quelque chose ....
Je vais lancer une session distante pour voir ...
> Si, si, j'ai testé, j'ai même écrit des applis en .NET dès sa sortie, mais
çà ne m'a pas du tout convaincu ...
Et tu dois savoir que j'aime bien arborer une attitude provoc' ! ;-)
Ce n'est pas çà le problème !
En Delphi, ".NET" existe aussi !
J'ai le choix, quand je lance Delphi, entre "Delphi Win32" et "Delphi
.NET"
Le 1er fait appel aux API bien gentilles de Windows ,
Le 2ème passe par .NET Framework, et le mécanisme est le même (avec CLR,
...) qu'en C#, VB NET, ou autre langage ".NET"
Mais les 1ères versions d'API Windows (Win16 ou WIn32) étaient déjà
orientées objet, au moins dans leur esprit. Le plus bel exemple étant les
classes de fenêtres.
Et en ce qui concerne Delphi, c'est Orienté Objet à fond, avec ou sans
.NET.
- Une intégration très réussie du point de vue développeur (avec des
"Namesspaces" très complets et intuitifs).
Idem pour moi sans .NET !
Quand je développe en .NET, je ne publie que les exe, qui sont
généralement très petits, à moins d'y avoir inclu une multitude de
ressources multimédia ;-)
.NET, c'est de la pub mensongère ! ;-)
On fait croire que les applis sont toutes petites, ce qui est souvent vrai
mais uniquement pour l'exe de base, car EN RÉALITÉ il faut se trimballer
une méga usine à gaz avec le Framework , qui n'est rien d'autre qu'un
niveau intermédiaire entre les applis et les API Windows .
Il suffit de comparer les espaces mémoire occupés par une appli avec .NET
et la même écrite en "Win32" ...
Tout comme une appli écrite en assembleur sera nettement plus économique
(à moins de programmer comme une pantoufle) que son homologue écrite avec
un langage évolué.
C'est logique, quand on insère une interface supplémentaire, on ajoute
plein de trucs inutilisés, donc inutiles.
Je me satisfait à 100% de Shell32, de NetAPI32 (même si les fonctions
réseau rament à mort)
P.ex. depuis un programme Delphi je n'ai JAMAIS été bloqué pour appeler
une fonction dont je n'avais que la syntaxe en C, la transcription étant
nasodigitale.
(En passant, je ne suis pas un "vendu" Microsoft, j'écris à partir d'une
machine virtuelle hébergée dans mon placard sur un VMWare server sur
Fedora 10)...
:-)
Je suis un fan de VMWare depuis le 11 avril 2000 !!!
Mais j'utilise aussi VPC 2007...
Cela me dit quelque chose ....
Je vais lancer une session distante pour voir ...
Si, si, j'ai testé, j'ai même écrit des applis en .NET dès sa sortie,
mais çà ne m'a pas du tout convaincu ...
Et tu dois savoir que j'aime bien arborer une attitude provoc' ! ;-)
Ok, ok...lolCe n'est pas çà le problème !
En Delphi, ".NET" existe aussi !
J'ai le choix, quand je lance Delphi, entre "Delphi Win32" et "Delphi
.NET"
Le 1er fait appel aux API bien gentilles de Windows ,
Le 2ème passe par .NET Framework, et le mécanisme est le même (avec CLR,
...) qu'en C#, VB NET, ou autre langage ".NET"
Moi aussi, avant de m'habituer au modèle du .NET framwork, je me demandais
où était l'intérêt puisque je n'avais jamais été bloqué... Je suis un peu
rentré dans le .NET par la bande, via le développement web. Visual Studio
est de loin (et j'en ai connu des langages web... des cgi en C++ sur
Solaris, à php sur Apache/Linux, en passant par ASP/IIS) la plus
fonctionnelle et intuitive des interfaces de développement web...
Par contre, je suis d'accord pour dire qu'au départ, .NET n'était qu'une
interface supplémentaire entre les API des Windows et le programmeur. Mais
maintenant, le .NET framework inclu beaucoup plus que les API (notamment
pour le développement web).
De plus, j'aime bien lire une clé de régistre en une seule ligne, sans
ajouter de déclarations d'API, mais celà, c'est une simple question de
confort...
Aussi, il est vrai qu'un programme 100% WIN32 utilise moins de ressources
qu'un programme .NET.Mais les 1ères versions d'API Windows (Win16 ou WIn32) étaient déjà
orientées objet, au moins dans leur esprit. Le plus bel exemple étant les
classes de fenêtres.
Et en ce qui concerne Delphi, c'est Orienté Objet à fond, avec ou sans
.NET.
C'est tout à fait vrai.- Une intégration très réussie du point de vue développeur (avec des
"Namesspaces" très complets et intuitifs).
Idem pour moi sans .NET !
C'est la beauté de Delphi!Quand je développe en .NET, je ne publie que les exe, qui sont
généralement très petits, à moins d'y avoir inclu une multitude de
ressources multimédia ;-)
.NET, c'est de la pub mensongère ! ;-)
On fait croire que les applis sont toutes petites, ce qui est souvent
vrai mais uniquement pour l'exe de base, car EN RÉALITÉ il faut se
trimballer une méga usine à gaz avec le Framework , qui n'est rien
d'autre qu'un niveau intermédiaire entre les applis et les API Windows .
Il suffit de comparer les espaces mémoire occupés par une appli avec .NET
et la même écrite en "Win32" ...
Tout comme une appli écrite en assembleur sera nettement plus économique
(à moins de programmer comme une pantoufle) que son homologue écrite avec
un langage évolué.
Justement, écris-tu encore tes applis en assembleur ou bien tu utilises
quand même un langage évolué, pour des raisons évidentes de productivité,
et ce même si les ressources utilisées sont plus grandes et que l'appli
est moins performante.
Je fais le même comparatif, oui .NET ajoute une couche et ses
inconvénients, mais il apporte aussi son lot d'avantages...
C'est logique, quand on insère une interface supplémentaire, on ajoute
plein de trucs inutilisés, donc inutiles.
Mais très utiles lorsque bien utilisés ;-)Je me satisfait à 100% de Shell32, de NetAPI32 (même si les fonctions
réseau rament à mort)
Elles rament tout autant dans le .NET... mais je pense que c'est une autre
question...P.ex. depuis un programme Delphi je n'ai JAMAIS été bloqué pour appeler
une fonction dont je n'avais que la syntaxe en C, la transcription étant
nasodigitale.
C'était la même chose pour VB...
Mais je réitère, les opérations communes d'accès aux fichiers, au
registre, etc. sont plus simples (et la différence de performance est
négligeable) à utiliser que leurs homologues de l'API WIN32. Mais selon
moi, la question n'est pas sur le "Wrap-up" des API dans le .NET mais sur
ce que le .NET apporte en plus des API...(En passant, je ne suis pas un "vendu" Microsoft, j'écris à partir d'une
machine virtuelle hébergée dans mon placard sur un VMWare server sur
Fedora 10)...
:-)
Je suis un fan de VMWare depuis le 11 avril 2000 !!!
Mais j'utilise aussi VPC 2007...
Moi aussi, je suis un fan... surtout de la version gratuite de VMWare
Server qui tourne sous Linux...
J'utilise aussi VPC 2007 et, depuis quelques mois HyperV sur 2K8 64b,
j'avoue être impressionné de la stabilité et de la performance!
Cela me dit quelque chose ....
Je vais lancer une session distante pour voir ...
Si tu trouves, essaie de poster la solution, ça m'intéresse...
Etienne
Si, si, j'ai testé, j'ai même écrit des applis en .NET dès sa sortie,
mais çà ne m'a pas du tout convaincu ...
Et tu dois savoir que j'aime bien arborer une attitude provoc' ! ;-)
Ok, ok...lol
Ce n'est pas çà le problème !
En Delphi, ".NET" existe aussi !
J'ai le choix, quand je lance Delphi, entre "Delphi Win32" et "Delphi
.NET"
Le 1er fait appel aux API bien gentilles de Windows ,
Le 2ème passe par .NET Framework, et le mécanisme est le même (avec CLR,
...) qu'en C#, VB NET, ou autre langage ".NET"
Moi aussi, avant de m'habituer au modèle du .NET framwork, je me demandais
où était l'intérêt puisque je n'avais jamais été bloqué... Je suis un peu
rentré dans le .NET par la bande, via le développement web. Visual Studio
est de loin (et j'en ai connu des langages web... des cgi en C++ sur
Solaris, à php sur Apache/Linux, en passant par ASP/IIS) la plus
fonctionnelle et intuitive des interfaces de développement web...
Par contre, je suis d'accord pour dire qu'au départ, .NET n'était qu'une
interface supplémentaire entre les API des Windows et le programmeur. Mais
maintenant, le .NET framework inclu beaucoup plus que les API (notamment
pour le développement web).
De plus, j'aime bien lire une clé de régistre en une seule ligne, sans
ajouter de déclarations d'API, mais celà, c'est une simple question de
confort...
Aussi, il est vrai qu'un programme 100% WIN32 utilise moins de ressources
qu'un programme .NET.
Mais les 1ères versions d'API Windows (Win16 ou WIn32) étaient déjà
orientées objet, au moins dans leur esprit. Le plus bel exemple étant les
classes de fenêtres.
Et en ce qui concerne Delphi, c'est Orienté Objet à fond, avec ou sans
.NET.
C'est tout à fait vrai.
- Une intégration très réussie du point de vue développeur (avec des
"Namesspaces" très complets et intuitifs).
Idem pour moi sans .NET !
C'est la beauté de Delphi!
Quand je développe en .NET, je ne publie que les exe, qui sont
généralement très petits, à moins d'y avoir inclu une multitude de
ressources multimédia ;-)
.NET, c'est de la pub mensongère ! ;-)
On fait croire que les applis sont toutes petites, ce qui est souvent
vrai mais uniquement pour l'exe de base, car EN RÉALITÉ il faut se
trimballer une méga usine à gaz avec le Framework , qui n'est rien
d'autre qu'un niveau intermédiaire entre les applis et les API Windows .
Il suffit de comparer les espaces mémoire occupés par une appli avec .NET
et la même écrite en "Win32" ...
Tout comme une appli écrite en assembleur sera nettement plus économique
(à moins de programmer comme une pantoufle) que son homologue écrite avec
un langage évolué.
Justement, écris-tu encore tes applis en assembleur ou bien tu utilises
quand même un langage évolué, pour des raisons évidentes de productivité,
et ce même si les ressources utilisées sont plus grandes et que l'appli
est moins performante.
Je fais le même comparatif, oui .NET ajoute une couche et ses
inconvénients, mais il apporte aussi son lot d'avantages...
C'est logique, quand on insère une interface supplémentaire, on ajoute
plein de trucs inutilisés, donc inutiles.
Mais très utiles lorsque bien utilisés ;-)
Je me satisfait à 100% de Shell32, de NetAPI32 (même si les fonctions
réseau rament à mort)
Elles rament tout autant dans le .NET... mais je pense que c'est une autre
question...
P.ex. depuis un programme Delphi je n'ai JAMAIS été bloqué pour appeler
une fonction dont je n'avais que la syntaxe en C, la transcription étant
nasodigitale.
C'était la même chose pour VB...
Mais je réitère, les opérations communes d'accès aux fichiers, au
registre, etc. sont plus simples (et la différence de performance est
négligeable) à utiliser que leurs homologues de l'API WIN32. Mais selon
moi, la question n'est pas sur le "Wrap-up" des API dans le .NET mais sur
ce que le .NET apporte en plus des API...
(En passant, je ne suis pas un "vendu" Microsoft, j'écris à partir d'une
machine virtuelle hébergée dans mon placard sur un VMWare server sur
Fedora 10)...
:-)
Je suis un fan de VMWare depuis le 11 avril 2000 !!!
Mais j'utilise aussi VPC 2007...
Moi aussi, je suis un fan... surtout de la version gratuite de VMWare
Server qui tourne sous Linux...
J'utilise aussi VPC 2007 et, depuis quelques mois HyperV sur 2K8 64b,
j'avoue être impressionné de la stabilité et de la performance!
Cela me dit quelque chose ....
Je vais lancer une session distante pour voir ...
Si tu trouves, essaie de poster la solution, ça m'intéresse...
Etienne
Si, si, j'ai testé, j'ai même écrit des applis en .NET dès sa sortie,
mais çà ne m'a pas du tout convaincu ...
Et tu dois savoir que j'aime bien arborer une attitude provoc' ! ;-)
Ok, ok...lolCe n'est pas çà le problème !
En Delphi, ".NET" existe aussi !
J'ai le choix, quand je lance Delphi, entre "Delphi Win32" et "Delphi
.NET"
Le 1er fait appel aux API bien gentilles de Windows ,
Le 2ème passe par .NET Framework, et le mécanisme est le même (avec CLR,
...) qu'en C#, VB NET, ou autre langage ".NET"
Moi aussi, avant de m'habituer au modèle du .NET framwork, je me demandais
où était l'intérêt puisque je n'avais jamais été bloqué... Je suis un peu
rentré dans le .NET par la bande, via le développement web. Visual Studio
est de loin (et j'en ai connu des langages web... des cgi en C++ sur
Solaris, à php sur Apache/Linux, en passant par ASP/IIS) la plus
fonctionnelle et intuitive des interfaces de développement web...
Par contre, je suis d'accord pour dire qu'au départ, .NET n'était qu'une
interface supplémentaire entre les API des Windows et le programmeur. Mais
maintenant, le .NET framework inclu beaucoup plus que les API (notamment
pour le développement web).
De plus, j'aime bien lire une clé de régistre en une seule ligne, sans
ajouter de déclarations d'API, mais celà, c'est une simple question de
confort...
Aussi, il est vrai qu'un programme 100% WIN32 utilise moins de ressources
qu'un programme .NET.Mais les 1ères versions d'API Windows (Win16 ou WIn32) étaient déjà
orientées objet, au moins dans leur esprit. Le plus bel exemple étant les
classes de fenêtres.
Et en ce qui concerne Delphi, c'est Orienté Objet à fond, avec ou sans
.NET.
C'est tout à fait vrai.- Une intégration très réussie du point de vue développeur (avec des
"Namesspaces" très complets et intuitifs).
Idem pour moi sans .NET !
C'est la beauté de Delphi!Quand je développe en .NET, je ne publie que les exe, qui sont
généralement très petits, à moins d'y avoir inclu une multitude de
ressources multimédia ;-)
.NET, c'est de la pub mensongère ! ;-)
On fait croire que les applis sont toutes petites, ce qui est souvent
vrai mais uniquement pour l'exe de base, car EN RÉALITÉ il faut se
trimballer une méga usine à gaz avec le Framework , qui n'est rien
d'autre qu'un niveau intermédiaire entre les applis et les API Windows .
Il suffit de comparer les espaces mémoire occupés par une appli avec .NET
et la même écrite en "Win32" ...
Tout comme une appli écrite en assembleur sera nettement plus économique
(à moins de programmer comme une pantoufle) que son homologue écrite avec
un langage évolué.
Justement, écris-tu encore tes applis en assembleur ou bien tu utilises
quand même un langage évolué, pour des raisons évidentes de productivité,
et ce même si les ressources utilisées sont plus grandes et que l'appli
est moins performante.
Je fais le même comparatif, oui .NET ajoute une couche et ses
inconvénients, mais il apporte aussi son lot d'avantages...
C'est logique, quand on insère une interface supplémentaire, on ajoute
plein de trucs inutilisés, donc inutiles.
Mais très utiles lorsque bien utilisés ;-)Je me satisfait à 100% de Shell32, de NetAPI32 (même si les fonctions
réseau rament à mort)
Elles rament tout autant dans le .NET... mais je pense que c'est une autre
question...P.ex. depuis un programme Delphi je n'ai JAMAIS été bloqué pour appeler
une fonction dont je n'avais que la syntaxe en C, la transcription étant
nasodigitale.
C'était la même chose pour VB...
Mais je réitère, les opérations communes d'accès aux fichiers, au
registre, etc. sont plus simples (et la différence de performance est
négligeable) à utiliser que leurs homologues de l'API WIN32. Mais selon
moi, la question n'est pas sur le "Wrap-up" des API dans le .NET mais sur
ce que le .NET apporte en plus des API...(En passant, je ne suis pas un "vendu" Microsoft, j'écris à partir d'une
machine virtuelle hébergée dans mon placard sur un VMWare server sur
Fedora 10)...
:-)
Je suis un fan de VMWare depuis le 11 avril 2000 !!!
Mais j'utilise aussi VPC 2007...
Moi aussi, je suis un fan... surtout de la version gratuite de VMWare
Server qui tourne sous Linux...
J'utilise aussi VPC 2007 et, depuis quelques mois HyperV sur 2K8 64b,
j'avoue être impressionné de la stabilité et de la performance!
Cela me dit quelque chose ....
Je vais lancer une session distante pour voir ...
Si tu trouves, essaie de poster la solution, ça m'intéresse...
Etienne
> Et le simple utilisateur de logiciels...Y fait quoi avec tout ça ?
> Et le simple utilisateur de logiciels...Y fait quoi avec tout ça ?
> Et le simple utilisateur de logiciels...Y fait quoi avec tout ça ?
Et le simple utilisateur de logiciels...Y fait quoi avec tout ça ?
Et le simple utilisateur de logiciels...Y fait quoi avec tout ça ?
Et le simple utilisateur de logiciels...Y fait quoi avec tout ça ?
Jean-Pierre Forestier [MVP[ a écrit :Et le simple utilisateur de logiciels...Y fait quoi avec tout ça ?
Ben oui, y fait quoi ?
J'installe la SP1 ou je jette le tout ?
Jean-Pierre Forestier [MVP[ a écrit :
Et le simple utilisateur de logiciels...Y fait quoi avec tout ça ?
Ben oui, y fait quoi ?
J'installe la SP1 ou je jette le tout ?
Jean-Pierre Forestier [MVP[ a écrit :Et le simple utilisateur de logiciels...Y fait quoi avec tout ça ?
Ben oui, y fait quoi ?
J'installe la SP1 ou je jette le tout ?
