"" a écrit
news:3f5ccfae$0$10414$
> Bonjour bonsoir,
>
> Dans Pc Expert de septembre 2003 Olivier Gaussin dit à propos de .Net
> framework repose sur Windows mais on n'est pas loin d'arriver à la
> inverse , où Windows reposera sur le framework. En effet, le prochain
> système d'exploitation de Microsoft, Longhorn, qui n'arrivera pas avant
> 2004, officialisera . Net comme API dans certains domaines. Exit les Api
> Win32: Il faudra nécessairement passer par .Net pour accéder au service
> systèmes"
>
> Cela me fait peur. En effet, je commence à faire de la programmation
> Windows avec du c avec les Api 32 .
>
> 1- Avez vous des informations plus précises ?
> 2- Est ce vrai ?
> 3- Dois je arrêter et changer de système si je veux utiliser le C ?
>
C'est du flan....c'est pour inciter les développeurs à migrer vers
pour COM.
"Nospam999@free.fradressenoncomplete.com" <nospam999j@free.fr> a écrit
news:3f5ccfae$0$10414$626a54ce@news.free.fr...
> Bonjour bonsoir,
>
> Dans Pc Expert de septembre 2003 Olivier Gaussin dit à propos de .Net
> framework repose sur Windows mais on n'est pas loin d'arriver à la
> inverse , où Windows reposera sur le framework. En effet, le prochain
> système d'exploitation de Microsoft, Longhorn, qui n'arrivera pas avant
> 2004, officialisera . Net comme API dans certains domaines. Exit les Api
> Win32: Il faudra nécessairement passer par .Net pour accéder au service
> systèmes"
>
> Cela me fait peur. En effet, je commence à faire de la programmation
> Windows avec du c avec les Api 32 .
>
> 1- Avez vous des informations plus précises ?
> 2- Est ce vrai ?
> 3- Dois je arrêter et changer de système si je veux utiliser le C ?
>
C'est du flan....c'est pour inciter les développeurs à migrer vers
pour COM.
"" a écrit
news:3f5ccfae$0$10414$
> Bonjour bonsoir,
>
> Dans Pc Expert de septembre 2003 Olivier Gaussin dit à propos de .Net
> framework repose sur Windows mais on n'est pas loin d'arriver à la
> inverse , où Windows reposera sur le framework. En effet, le prochain
> système d'exploitation de Microsoft, Longhorn, qui n'arrivera pas avant
> 2004, officialisera . Net comme API dans certains domaines. Exit les Api
> Win32: Il faudra nécessairement passer par .Net pour accéder au service
> systèmes"
>
> Cela me fait peur. En effet, je commence à faire de la programmation
> Windows avec du c avec les Api 32 .
>
> 1- Avez vous des informations plus précises ?
> 2- Est ce vrai ?
> 3- Dois je arrêter et changer de système si je veux utiliser le C ?
>
C'est du flan....c'est pour inciter les développeurs à migrer vers
pour COM.
>ben c'est simple : wizard -> Create a win32 DLL -> Create a simple dll
>project et le tour est joué ... Tous les symboles a exporter dans un
>nommé : madll.def
Je suppose que tu parles du développement d'une DLL. Mais je parlais
d'une DLL dont je ne suis pas l'auteur, mais dont je voudrais bien
utiliser les fonctions.
Je suis sûr que c'est tout bête en fait (à la rigueur, je peux
réutiliser le fichier .def de LCC qui me génère bien les libs, lui.)
J'arrête, j'ai plus posté ici que dans mon fil :)
--
Alussinan, l'internette que ça fout la trouille.
>ben c'est simple : wizard -> Create a win32 DLL -> Create a simple dll
>project et le tour est joué ... Tous les symboles a exporter dans un
>nommé : madll.def
Je suppose que tu parles du développement d'une DLL. Mais je parlais
d'une DLL dont je ne suis pas l'auteur, mais dont je voudrais bien
utiliser les fonctions.
Je suis sûr que c'est tout bête en fait (à la rigueur, je peux
réutiliser le fichier .def de LCC qui me génère bien les libs, lui.)
J'arrête, j'ai plus posté ici que dans mon fil :)
--
Alussinan, l'internette que ça fout la trouille.
>ben c'est simple : wizard -> Create a win32 DLL -> Create a simple dll
>project et le tour est joué ... Tous les symboles a exporter dans un
>nommé : madll.def
Je suppose que tu parles du développement d'une DLL. Mais je parlais
d'une DLL dont je ne suis pas l'auteur, mais dont je voudrais bien
utiliser les fonctions.
Je suis sûr que c'est tout bête en fait (à la rigueur, je peux
réutiliser le fichier .def de LCC qui me génère bien les libs, lui.)
J'arrête, j'ai plus posté ici que dans mon fil :)
--
Alussinan, l'internette que ça fout la trouille.
Que MS commence par reprogramer entièrement ses softs en .NET (IE, Office,
les jeux videos, VStudio, ...) et après moi je veux bien abandonner win32.
Bah, on parle juste de quelques dizaines de millions de lignes de codes.
Pc Expert a dit que ce sera fait pour 2004, ça doit être vrai.
Histoire d'enrichir le débat, comment l'intégration de .NET au sein de
va-t-elle se faire selon vous ? On va voir débarquer un nouveau
?
Que MS commence par reprogramer entièrement ses softs en .NET (IE, Office,
les jeux videos, VStudio, ...) et après moi je veux bien abandonner win32.
Bah, on parle juste de quelques dizaines de millions de lignes de codes.
Pc Expert a dit que ce sera fait pour 2004, ça doit être vrai.
Histoire d'enrichir le débat, comment l'intégration de .NET au sein de
va-t-elle se faire selon vous ? On va voir débarquer un nouveau
?
Que MS commence par reprogramer entièrement ses softs en .NET (IE, Office,
les jeux videos, VStudio, ...) et après moi je veux bien abandonner win32.
Bah, on parle juste de quelques dizaines de millions de lignes de codes.
Pc Expert a dit que ce sera fait pour 2004, ça doit être vrai.
Histoire d'enrichir le débat, comment l'intégration de .NET au sein de
va-t-elle se faire selon vous ? On va voir débarquer un nouveau
?
Bon précisons donc d'abord que ".NET framework" est un environnement
de travail pour faire de l'appli réseau ou déployable réseau (et à
vocation multiplatform) et pas spécialement concu pour faire de
l'appli native 32.
Comme Direct-X est un environnement très utilisé pour développer des
jeux vidéo et MFC un autre environnement pour développer des merdes
etc...
La différence est qu'avec ".NET framework" Microsoft ne fournit pas
qu'un ensemble de class en librairie (comme MFC) mais une runtime
aussi.
comme Direct-X et sa couche HAL et ses drivers spéciaux !? non je
dirais plutot comme la machine virtuelle JAVA, mais optimisé... Je
suppose que "machine virtuelle" doit être déposé car Microsoft
n'utilise jamais ce terme :-)
et Pourtant on aura la possibilité de
coder soi pour cette runtime donc (managed code = code .NET) ou non
(unmanaged code = code WIN32)... mais l'ensemble reste assez floue
pour moi...
Donc cette runtime, qui littéralement fournit un environnement
d'execution de votre code qui utilise .NET (c'est pas la machine
virtuelle JAVA mais c'est pas loin quand même) exécute le code et
fournit des services systemes... et ce de manière ultra sécure
d'après Microsoft. Par exemple le goré de programmeur qui ne sait pas
gérer la destruction des ses handle et autre pointeurs, pourra, lui
aussi, programmer son appli ... c'est de la démocratisation en
quelques sortes :-)
Bref, Etant donnée les attributions de la runtime .NET on peut penser
ce qu'on veux parce que y'a le choix. Ou c'est une surcouche des API32
(comme un interpréteur Basic) ou c'est un système complémentaire
(comme certains des composant Direct-X) en somme un sur-systeme...
plus qu'un sous-systeme d'ailleurs.
Bon précisons donc d'abord que ".NET framework" est un environnement
de travail pour faire de l'appli réseau ou déployable réseau (et à
vocation multiplatform) et pas spécialement concu pour faire de
l'appli native 32.
Comme Direct-X est un environnement très utilisé pour développer des
jeux vidéo et MFC un autre environnement pour développer des merdes
etc...
La différence est qu'avec ".NET framework" Microsoft ne fournit pas
qu'un ensemble de class en librairie (comme MFC) mais une runtime
aussi.
comme Direct-X et sa couche HAL et ses drivers spéciaux !? non je
dirais plutot comme la machine virtuelle JAVA, mais optimisé... Je
suppose que "machine virtuelle" doit être déposé car Microsoft
n'utilise jamais ce terme :-)
et Pourtant on aura la possibilité de
coder soi pour cette runtime donc (managed code = code .NET) ou non
(unmanaged code = code WIN32)... mais l'ensemble reste assez floue
pour moi...
Donc cette runtime, qui littéralement fournit un environnement
d'execution de votre code qui utilise .NET (c'est pas la machine
virtuelle JAVA mais c'est pas loin quand même) exécute le code et
fournit des services systemes... et ce de manière ultra sécure
d'après Microsoft. Par exemple le goré de programmeur qui ne sait pas
gérer la destruction des ses handle et autre pointeurs, pourra, lui
aussi, programmer son appli ... c'est de la démocratisation en
quelques sortes :-)
Bref, Etant donnée les attributions de la runtime .NET on peut penser
ce qu'on veux parce que y'a le choix. Ou c'est une surcouche des API32
(comme un interpréteur Basic) ou c'est un système complémentaire
(comme certains des composant Direct-X) en somme un sur-systeme...
plus qu'un sous-systeme d'ailleurs.
Bon précisons donc d'abord que ".NET framework" est un environnement
de travail pour faire de l'appli réseau ou déployable réseau (et à
vocation multiplatform) et pas spécialement concu pour faire de
l'appli native 32.
Comme Direct-X est un environnement très utilisé pour développer des
jeux vidéo et MFC un autre environnement pour développer des merdes
etc...
La différence est qu'avec ".NET framework" Microsoft ne fournit pas
qu'un ensemble de class en librairie (comme MFC) mais une runtime
aussi.
comme Direct-X et sa couche HAL et ses drivers spéciaux !? non je
dirais plutot comme la machine virtuelle JAVA, mais optimisé... Je
suppose que "machine virtuelle" doit être déposé car Microsoft
n'utilise jamais ce terme :-)
et Pourtant on aura la possibilité de
coder soi pour cette runtime donc (managed code = code .NET) ou non
(unmanaged code = code WIN32)... mais l'ensemble reste assez floue
pour moi...
Donc cette runtime, qui littéralement fournit un environnement
d'execution de votre code qui utilise .NET (c'est pas la machine
virtuelle JAVA mais c'est pas loin quand même) exécute le code et
fournit des services systemes... et ce de manière ultra sécure
d'après Microsoft. Par exemple le goré de programmeur qui ne sait pas
gérer la destruction des ses handle et autre pointeurs, pourra, lui
aussi, programmer son appli ... c'est de la démocratisation en
quelques sortes :-)
Bref, Etant donnée les attributions de la runtime .NET on peut penser
ce qu'on veux parce que y'a le choix. Ou c'est une surcouche des API32
(comme un interpréteur Basic) ou c'est un système complémentaire
(comme certains des composant Direct-X) en somme un sur-systeme...
plus qu'un sous-systeme d'ailleurs.
wrote in message
news:
>
>
> Vincent Burel wrote:
> > Bon précisons donc d'abord que ".NET framework" est un
> > environnement de travail pour faire de l'appli réseau ou
> > déployable réseau (et à vocation multiplatform) et pas
> > spécialement concu pour faire de l'appli native 32.
>
> C'est quoi des appli native 32?...
Ben aujourd'hui c'est un peu dur à définir, mais disons que si l'appli
fait appel aux composant de base du systeme alors c'est du natif WIN32
:-))
Evidemment on peut se demander qu'est ce qui fait partie des
composant de base du system window... Mais bon, vous avez quand même
du comprendre ce que je voulais dire...
> Sérieusement, dans quel domaine l'api
> Win32 est plus adapté que .NET?
Dans le domaine de la productivité si l'on ne target pas une
application typiquement .NET. ben il me semble que changer de langage,
de concept, d'API , c'est pas super adapté... surtout qu'une bonne
partie de l'industrie de développement de soft sous Windows commence
à peine à maitriser la production de leur logiciel avec les outils
actuels ... alors changer d'environnement... ca doit pouvoir se
chiffrer... faut voir...
> > La différence est qu'avec ".NET framework" Microsoft ne fournit
> > pas qu'un ensemble de class en librairie (comme MFC) mais une
> > runtime aussi.
>
> Et de nouveau langages de programmation, et une approche différente
> (de ce qu'on connaissait en Win32) pour pas mal de trucs...
Et bien parlez en, au lieu de faire l'intéressant avec des phrases
génériques...
> > comme Direct-X et sa couche HAL et ses drivers spéciaux !? non je
> > dirais plutot comme la machine virtuelle JAVA, mais optimisé... Je
> > suppose que "machine virtuelle" doit être déposé car Microsoft
> > n'utilise jamais ce terme :-)
>
> Peut-être parce que ce n'est pas une machine virtuelle?... C'est là
> amha, la grosse différence entre java et .NET: .NET depuis le début
> ne se destine pas à être portable (en tous cas pas directement
> portable), il offre des possibilités d'utiliser du code natif, et
> ce assez simplement. Pas mal de parties du framework sont
> construites comme cela (dont winforms). Java lui a décider de
> trouver un plus petit dénominateur communs entre toutes les
> machines, et de faire un "runtime" qui tourne sur cette machine
> minimaliste... cette machine virtuelle si tu préfères.
Et bien je trouve que conceptuellement c'est assez proche.
Et si
Microsoft amène un peu de neuf avec son .NET, c'est certainement aussi
pour explorer d'autres marchés (peut être ceux de SUN et IBM...)
> > et Pourtant on aura la possibilité de
> > coder soi pour cette runtime donc (managed code = code .NET) ou
> > non (unmanaged code = code WIN32)... mais l'ensemble reste assez
> > floue pour moi...
>
> En effet c'est assez flou pour toi ;)
Au lieu de me paraphraser, Dites nous en nous plus mon cher.
Je ménage
des espaces dans mon topos lacunaire, pour que d'autres personnes
viennent donner des précisions (je ne suis pas du tout expert en .NET)
et vous n'en profitez pas. Avouez que vous êtes un peu cucu non !?
> Pour ma part, je pense que le débat est biaisé: certains affirment
> des trucs du genre "ouhé mais ms a déjà fait le coup une fois, avec
> COM on allait arrêté le C, je fais du COM en C, ils ont mentis,
> c'tait pour [n'importe quel argument visant à démontrer que ms
> cherche à gagner du fric"... ouais d'accord, on peut se faire ch...
> à faire du COM en C, c'est lourd, pénibe, pas fait pour... (tout
> comme on peut faire de l'assembleur, on pourrait même coder
> directement en binaire...). Le fait est que COM apportait la notion
> d'objet dans les API, et que donc un langage "objet" était (et est
> toujours) plus adapté.
ca tombe bien je suis fan de COM (en "C" :-)
>Pour .NET ce
> sera pareil: on peut appelé déjà appelé du code .NET depuis des
> applications natives: c'est pénible (aussi pénible, voir pire en
> fait, que du COM en C...
Bon ben c'est chouette ! comme ca on est fixé, le .NET peut aussi se
considérer comme un composant de plus dans le tas de merde.
Merci pour votre intervention.
<poubelle@alrj.org> wrote in message
news:254_2003_194529_1479579583_MYOE@news.free.fr...
>
>
> Vincent Burel wrote:
> > Bon précisons donc d'abord que ".NET framework" est un
> > environnement de travail pour faire de l'appli réseau ou
> > déployable réseau (et à vocation multiplatform) et pas
> > spécialement concu pour faire de l'appli native 32.
>
> C'est quoi des appli native 32?...
Ben aujourd'hui c'est un peu dur à définir, mais disons que si l'appli
fait appel aux composant de base du systeme alors c'est du natif WIN32
:-))
Evidemment on peut se demander qu'est ce qui fait partie des
composant de base du system window... Mais bon, vous avez quand même
du comprendre ce que je voulais dire...
> Sérieusement, dans quel domaine l'api
> Win32 est plus adapté que .NET?
Dans le domaine de la productivité si l'on ne target pas une
application typiquement .NET. ben il me semble que changer de langage,
de concept, d'API , c'est pas super adapté... surtout qu'une bonne
partie de l'industrie de développement de soft sous Windows commence
à peine à maitriser la production de leur logiciel avec les outils
actuels ... alors changer d'environnement... ca doit pouvoir se
chiffrer... faut voir...
> > La différence est qu'avec ".NET framework" Microsoft ne fournit
> > pas qu'un ensemble de class en librairie (comme MFC) mais une
> > runtime aussi.
>
> Et de nouveau langages de programmation, et une approche différente
> (de ce qu'on connaissait en Win32) pour pas mal de trucs...
Et bien parlez en, au lieu de faire l'intéressant avec des phrases
génériques...
> > comme Direct-X et sa couche HAL et ses drivers spéciaux !? non je
> > dirais plutot comme la machine virtuelle JAVA, mais optimisé... Je
> > suppose que "machine virtuelle" doit être déposé car Microsoft
> > n'utilise jamais ce terme :-)
>
> Peut-être parce que ce n'est pas une machine virtuelle?... C'est là
> amha, la grosse différence entre java et .NET: .NET depuis le début
> ne se destine pas à être portable (en tous cas pas directement
> portable), il offre des possibilités d'utiliser du code natif, et
> ce assez simplement. Pas mal de parties du framework sont
> construites comme cela (dont winforms). Java lui a décider de
> trouver un plus petit dénominateur communs entre toutes les
> machines, et de faire un "runtime" qui tourne sur cette machine
> minimaliste... cette machine virtuelle si tu préfères.
Et bien je trouve que conceptuellement c'est assez proche.
Et si
Microsoft amène un peu de neuf avec son .NET, c'est certainement aussi
pour explorer d'autres marchés (peut être ceux de SUN et IBM...)
> > et Pourtant on aura la possibilité de
> > coder soi pour cette runtime donc (managed code = code .NET) ou
> > non (unmanaged code = code WIN32)... mais l'ensemble reste assez
> > floue pour moi...
>
> En effet c'est assez flou pour toi ;)
Au lieu de me paraphraser, Dites nous en nous plus mon cher.
Je ménage
des espaces dans mon topos lacunaire, pour que d'autres personnes
viennent donner des précisions (je ne suis pas du tout expert en .NET)
et vous n'en profitez pas. Avouez que vous êtes un peu cucu non !?
> Pour ma part, je pense que le débat est biaisé: certains affirment
> des trucs du genre "ouhé mais ms a déjà fait le coup une fois, avec
> COM on allait arrêté le C, je fais du COM en C, ils ont mentis,
> c'tait pour [n'importe quel argument visant à démontrer que ms
> cherche à gagner du fric"... ouais d'accord, on peut se faire ch...
> à faire du COM en C, c'est lourd, pénibe, pas fait pour... (tout
> comme on peut faire de l'assembleur, on pourrait même coder
> directement en binaire...). Le fait est que COM apportait la notion
> d'objet dans les API, et que donc un langage "objet" était (et est
> toujours) plus adapté.
ca tombe bien je suis fan de COM (en "C" :-)
>Pour .NET ce
> sera pareil: on peut appelé déjà appelé du code .NET depuis des
> applications natives: c'est pénible (aussi pénible, voir pire en
> fait, que du COM en C...
Bon ben c'est chouette ! comme ca on est fixé, le .NET peut aussi se
considérer comme un composant de plus dans le tas de merde.
Merci pour votre intervention.
wrote in message
news:
>
>
> Vincent Burel wrote:
> > Bon précisons donc d'abord que ".NET framework" est un
> > environnement de travail pour faire de l'appli réseau ou
> > déployable réseau (et à vocation multiplatform) et pas
> > spécialement concu pour faire de l'appli native 32.
>
> C'est quoi des appli native 32?...
Ben aujourd'hui c'est un peu dur à définir, mais disons que si l'appli
fait appel aux composant de base du systeme alors c'est du natif WIN32
:-))
Evidemment on peut se demander qu'est ce qui fait partie des
composant de base du system window... Mais bon, vous avez quand même
du comprendre ce que je voulais dire...
> Sérieusement, dans quel domaine l'api
> Win32 est plus adapté que .NET?
Dans le domaine de la productivité si l'on ne target pas une
application typiquement .NET. ben il me semble que changer de langage,
de concept, d'API , c'est pas super adapté... surtout qu'une bonne
partie de l'industrie de développement de soft sous Windows commence
à peine à maitriser la production de leur logiciel avec les outils
actuels ... alors changer d'environnement... ca doit pouvoir se
chiffrer... faut voir...
> > La différence est qu'avec ".NET framework" Microsoft ne fournit
> > pas qu'un ensemble de class en librairie (comme MFC) mais une
> > runtime aussi.
>
> Et de nouveau langages de programmation, et une approche différente
> (de ce qu'on connaissait en Win32) pour pas mal de trucs...
Et bien parlez en, au lieu de faire l'intéressant avec des phrases
génériques...
> > comme Direct-X et sa couche HAL et ses drivers spéciaux !? non je
> > dirais plutot comme la machine virtuelle JAVA, mais optimisé... Je
> > suppose que "machine virtuelle" doit être déposé car Microsoft
> > n'utilise jamais ce terme :-)
>
> Peut-être parce que ce n'est pas une machine virtuelle?... C'est là
> amha, la grosse différence entre java et .NET: .NET depuis le début
> ne se destine pas à être portable (en tous cas pas directement
> portable), il offre des possibilités d'utiliser du code natif, et
> ce assez simplement. Pas mal de parties du framework sont
> construites comme cela (dont winforms). Java lui a décider de
> trouver un plus petit dénominateur communs entre toutes les
> machines, et de faire un "runtime" qui tourne sur cette machine
> minimaliste... cette machine virtuelle si tu préfères.
Et bien je trouve que conceptuellement c'est assez proche.
Et si
Microsoft amène un peu de neuf avec son .NET, c'est certainement aussi
pour explorer d'autres marchés (peut être ceux de SUN et IBM...)
> > et Pourtant on aura la possibilité de
> > coder soi pour cette runtime donc (managed code = code .NET) ou
> > non (unmanaged code = code WIN32)... mais l'ensemble reste assez
> > floue pour moi...
>
> En effet c'est assez flou pour toi ;)
Au lieu de me paraphraser, Dites nous en nous plus mon cher.
Je ménage
des espaces dans mon topos lacunaire, pour que d'autres personnes
viennent donner des précisions (je ne suis pas du tout expert en .NET)
et vous n'en profitez pas. Avouez que vous êtes un peu cucu non !?
> Pour ma part, je pense que le débat est biaisé: certains affirment
> des trucs du genre "ouhé mais ms a déjà fait le coup une fois, avec
> COM on allait arrêté le C, je fais du COM en C, ils ont mentis,
> c'tait pour [n'importe quel argument visant à démontrer que ms
> cherche à gagner du fric"... ouais d'accord, on peut se faire ch...
> à faire du COM en C, c'est lourd, pénibe, pas fait pour... (tout
> comme on peut faire de l'assembleur, on pourrait même coder
> directement en binaire...). Le fait est que COM apportait la notion
> d'objet dans les API, et que donc un langage "objet" était (et est
> toujours) plus adapté.
ca tombe bien je suis fan de COM (en "C" :-)
>Pour .NET ce
> sera pareil: on peut appelé déjà appelé du code .NET depuis des
> applications natives: c'est pénible (aussi pénible, voir pire en
> fait, que du COM en C...
Bon ben c'est chouette ! comme ca on est fixé, le .NET peut aussi se
considérer comme un composant de plus dans le tas de merde.
Merci pour votre intervention.
Bah c'est là que ça colle pas, .NET est au dessus de l'os (tout comme
l'api Win32 est une abstraction au dessus de l'os), que ce soit Win32 ou
.NET ils font tous les deux appels à l'os, et généralement de la même
façon. La séparation des deux est amha, à ce niveau là, inexistante...
Pour moi la grosse différence entre une appli native et managed sont:
- .NET implique un modèle objet (pas toujours bien pensé, mais objet).
- garbage collector
- MSIL (et donc introspection, meta-informations, JIt, etc...).
En fait, tu as l'air de considérer le framework (l'ensemble des classes)
comme une boite noires, on y touche pas, si tu veux faire un truc qui
n'est pas dedans, c'est impossible...
> > Sérieusement, dans quel domaine l'api
> > Win32 est plus adapté que .NET?
>
> Dans le domaine de la productivité si l'on ne target pas une
> application typiquement .NET. ben il me semble que changer de langage,
> de concept, d'API , c'est pas super adapté... surtout qu'une bonne
> partie de l'industrie de développement de soft sous Windows commence
> à peine à maitriser la production de leur logiciel avec les outils
> actuels ... alors changer d'environnement... ca doit pouvoir se
> chiffrer... faut voir...
Ca c'est l'aspect financier, qui est évidemment à prendre en compte,
mais perso, la première question que je me pose est technique: est-ce
que .NET peut le faire? si oui, je vais me demander si c'est
rentable... tu as l'air de considérer que .NET c'est pour "faire des
applis réseaux ou déployable en réseaux" ce qui est plutôt vague, et
donc ma question était là: as-tu l'expérience de domaine ou .NET n'est
pas techniquement adpaté, ou en admettant qu'on ai les connaissances
requises, ce sera quand même inadapté? C'est un partage d'expérience
que je demande là!
> > > La différence est qu'avec ".NET framework" Microsoft ne fournit
> > > pas qu'un ensemble de class en librairie (comme MFC) mais une
> > > runtime aussi.
> >
> > Et de nouveau langages de programmation, et une approche différente
> > (de ce qu'on connaissait en Win32) pour pas mal de trucs...
>
> Et bien parlez en, au lieu de faire l'intéressant avec des phrases
> génériques...
De quel aspect veux-tu entendre parler?
Si tu veux un exemple, parmis ce que je trouve le plus intéressant en
.NET: les attributes. Ca te permet de rajouter des informations à une
classe, un membre d'une classe, une application, etc... par exemple,
imagine une structure de donnée quelconque qui doit être sérializer sur
le disque, en natif, ce qu'on fait souvent, c'est une méthode
(Serialize par exemple) qui va s'occuper de cela... il est difficile de
faire beaucoup mieux, si tu ajoutes un membres, tu dois modifier ta
méthode... en .NET tu vas pouvoir énumérer les données membres de ta
classe et vérifier si elles ont un attribut (Serializable par exemple)
et de là agir... autrement dit: ta méthode Serialize sera générique. Ca
c'est l'exemple trivial, mais comme tu peux définir tes propres
attributes, y'a moyen de faire pas mal de choses avec...
> > Peut-être parce que ce n'est pas une machine virtuelle?...
> Et bien je trouve que conceptuellement c'est assez proche.
Il y'a en effet beaucoup de point commun, mais la façon de faire, le but
n'est pas vraiment le même! En java, quand tu appelles du code natif, ce
n'est plus vraiment du java, et tu perds son principal avantage (la
portabilité), en .NET c'est pas vraiment le même délire: c'est
encouragé, et comme son but n'est pas d'être portable, tu ne "perds"
rien par rapport à ce que tu avais...
> Au lieu de me paraphraser, Dites nous en nous plus mon cher.
Tiens pourtant j'avais mis le smilie... ;)
> >Pour .NET ce
> > sera pareil: on peut appelé déjà appelé du code .NET depuis des
> > applications natives: c'est pénible (aussi pénible, voir pire en
> > fait, que du COM en C...
>
> Bon ben c'est chouette ! comme ca on est fixé, le .NET peut aussi se
> considérer comme un composant de plus dans le tas de merde.
Libre à toi de le voir comme ça... tu limites ta vision de .NET à ce que
tu connais: c'est comme le java, c'est comme les "autres merdes", c'est
toujours comme qqch que tu connais, ou semble connaitre... Quand
j'essaie de t'expliquer mon point de vue, je suis soit "cucu" soit
c'est "conceptuellement assez proche", donc je crois pas qu'on puisse
aller plus loin... Cependant si tu veux le faire, je te conseille de
regarder le C# (principalement les delegates, attributes et
éventuellement les futurs generics), winforms, remoting .NET, ADO.NET
et aussi l'ASP.NET si tu as développé quelques applications Web...
peut-être tu comprendras pq certaines personnes trouvent de l'intérêt à
ce "composant de plus dans le tas de merde"...
Bah c'est là que ça colle pas, .NET est au dessus de l'os (tout comme
l'api Win32 est une abstraction au dessus de l'os), que ce soit Win32 ou
.NET ils font tous les deux appels à l'os, et généralement de la même
façon. La séparation des deux est amha, à ce niveau là, inexistante...
Pour moi la grosse différence entre une appli native et managed sont:
- .NET implique un modèle objet (pas toujours bien pensé, mais objet).
- garbage collector
- MSIL (et donc introspection, meta-informations, JIt, etc...).
En fait, tu as l'air de considérer le framework (l'ensemble des classes)
comme une boite noires, on y touche pas, si tu veux faire un truc qui
n'est pas dedans, c'est impossible...
> > Sérieusement, dans quel domaine l'api
> > Win32 est plus adapté que .NET?
>
> Dans le domaine de la productivité si l'on ne target pas une
> application typiquement .NET. ben il me semble que changer de langage,
> de concept, d'API , c'est pas super adapté... surtout qu'une bonne
> partie de l'industrie de développement de soft sous Windows commence
> à peine à maitriser la production de leur logiciel avec les outils
> actuels ... alors changer d'environnement... ca doit pouvoir se
> chiffrer... faut voir...
Ca c'est l'aspect financier, qui est évidemment à prendre en compte,
mais perso, la première question que je me pose est technique: est-ce
que .NET peut le faire? si oui, je vais me demander si c'est
rentable... tu as l'air de considérer que .NET c'est pour "faire des
applis réseaux ou déployable en réseaux" ce qui est plutôt vague, et
donc ma question était là: as-tu l'expérience de domaine ou .NET n'est
pas techniquement adpaté, ou en admettant qu'on ai les connaissances
requises, ce sera quand même inadapté? C'est un partage d'expérience
que je demande là!
> > > La différence est qu'avec ".NET framework" Microsoft ne fournit
> > > pas qu'un ensemble de class en librairie (comme MFC) mais une
> > > runtime aussi.
> >
> > Et de nouveau langages de programmation, et une approche différente
> > (de ce qu'on connaissait en Win32) pour pas mal de trucs...
>
> Et bien parlez en, au lieu de faire l'intéressant avec des phrases
> génériques...
De quel aspect veux-tu entendre parler?
Si tu veux un exemple, parmis ce que je trouve le plus intéressant en
.NET: les attributes. Ca te permet de rajouter des informations à une
classe, un membre d'une classe, une application, etc... par exemple,
imagine une structure de donnée quelconque qui doit être sérializer sur
le disque, en natif, ce qu'on fait souvent, c'est une méthode
(Serialize par exemple) qui va s'occuper de cela... il est difficile de
faire beaucoup mieux, si tu ajoutes un membres, tu dois modifier ta
méthode... en .NET tu vas pouvoir énumérer les données membres de ta
classe et vérifier si elles ont un attribut (Serializable par exemple)
et de là agir... autrement dit: ta méthode Serialize sera générique. Ca
c'est l'exemple trivial, mais comme tu peux définir tes propres
attributes, y'a moyen de faire pas mal de choses avec...
> > Peut-être parce que ce n'est pas une machine virtuelle?...
> Et bien je trouve que conceptuellement c'est assez proche.
Il y'a en effet beaucoup de point commun, mais la façon de faire, le but
n'est pas vraiment le même! En java, quand tu appelles du code natif, ce
n'est plus vraiment du java, et tu perds son principal avantage (la
portabilité), en .NET c'est pas vraiment le même délire: c'est
encouragé, et comme son but n'est pas d'être portable, tu ne "perds"
rien par rapport à ce que tu avais...
> Au lieu de me paraphraser, Dites nous en nous plus mon cher.
Tiens pourtant j'avais mis le smilie... ;)
> >Pour .NET ce
> > sera pareil: on peut appelé déjà appelé du code .NET depuis des
> > applications natives: c'est pénible (aussi pénible, voir pire en
> > fait, que du COM en C...
>
> Bon ben c'est chouette ! comme ca on est fixé, le .NET peut aussi se
> considérer comme un composant de plus dans le tas de merde.
Libre à toi de le voir comme ça... tu limites ta vision de .NET à ce que
tu connais: c'est comme le java, c'est comme les "autres merdes", c'est
toujours comme qqch que tu connais, ou semble connaitre... Quand
j'essaie de t'expliquer mon point de vue, je suis soit "cucu" soit
c'est "conceptuellement assez proche", donc je crois pas qu'on puisse
aller plus loin... Cependant si tu veux le faire, je te conseille de
regarder le C# (principalement les delegates, attributes et
éventuellement les futurs generics), winforms, remoting .NET, ADO.NET
et aussi l'ASP.NET si tu as développé quelques applications Web...
peut-être tu comprendras pq certaines personnes trouvent de l'intérêt à
ce "composant de plus dans le tas de merde"...
Bah c'est là que ça colle pas, .NET est au dessus de l'os (tout comme
l'api Win32 est une abstraction au dessus de l'os), que ce soit Win32 ou
.NET ils font tous les deux appels à l'os, et généralement de la même
façon. La séparation des deux est amha, à ce niveau là, inexistante...
Pour moi la grosse différence entre une appli native et managed sont:
- .NET implique un modèle objet (pas toujours bien pensé, mais objet).
- garbage collector
- MSIL (et donc introspection, meta-informations, JIt, etc...).
En fait, tu as l'air de considérer le framework (l'ensemble des classes)
comme une boite noires, on y touche pas, si tu veux faire un truc qui
n'est pas dedans, c'est impossible...
> > Sérieusement, dans quel domaine l'api
> > Win32 est plus adapté que .NET?
>
> Dans le domaine de la productivité si l'on ne target pas une
> application typiquement .NET. ben il me semble que changer de langage,
> de concept, d'API , c'est pas super adapté... surtout qu'une bonne
> partie de l'industrie de développement de soft sous Windows commence
> à peine à maitriser la production de leur logiciel avec les outils
> actuels ... alors changer d'environnement... ca doit pouvoir se
> chiffrer... faut voir...
Ca c'est l'aspect financier, qui est évidemment à prendre en compte,
mais perso, la première question que je me pose est technique: est-ce
que .NET peut le faire? si oui, je vais me demander si c'est
rentable... tu as l'air de considérer que .NET c'est pour "faire des
applis réseaux ou déployable en réseaux" ce qui est plutôt vague, et
donc ma question était là: as-tu l'expérience de domaine ou .NET n'est
pas techniquement adpaté, ou en admettant qu'on ai les connaissances
requises, ce sera quand même inadapté? C'est un partage d'expérience
que je demande là!
> > > La différence est qu'avec ".NET framework" Microsoft ne fournit
> > > pas qu'un ensemble de class en librairie (comme MFC) mais une
> > > runtime aussi.
> >
> > Et de nouveau langages de programmation, et une approche différente
> > (de ce qu'on connaissait en Win32) pour pas mal de trucs...
>
> Et bien parlez en, au lieu de faire l'intéressant avec des phrases
> génériques...
De quel aspect veux-tu entendre parler?
Si tu veux un exemple, parmis ce que je trouve le plus intéressant en
.NET: les attributes. Ca te permet de rajouter des informations à une
classe, un membre d'une classe, une application, etc... par exemple,
imagine une structure de donnée quelconque qui doit être sérializer sur
le disque, en natif, ce qu'on fait souvent, c'est une méthode
(Serialize par exemple) qui va s'occuper de cela... il est difficile de
faire beaucoup mieux, si tu ajoutes un membres, tu dois modifier ta
méthode... en .NET tu vas pouvoir énumérer les données membres de ta
classe et vérifier si elles ont un attribut (Serializable par exemple)
et de là agir... autrement dit: ta méthode Serialize sera générique. Ca
c'est l'exemple trivial, mais comme tu peux définir tes propres
attributes, y'a moyen de faire pas mal de choses avec...
> > Peut-être parce que ce n'est pas une machine virtuelle?...
> Et bien je trouve que conceptuellement c'est assez proche.
Il y'a en effet beaucoup de point commun, mais la façon de faire, le but
n'est pas vraiment le même! En java, quand tu appelles du code natif, ce
n'est plus vraiment du java, et tu perds son principal avantage (la
portabilité), en .NET c'est pas vraiment le même délire: c'est
encouragé, et comme son but n'est pas d'être portable, tu ne "perds"
rien par rapport à ce que tu avais...
> Au lieu de me paraphraser, Dites nous en nous plus mon cher.
Tiens pourtant j'avais mis le smilie... ;)
> >Pour .NET ce
> > sera pareil: on peut appelé déjà appelé du code .NET depuis des
> > applications natives: c'est pénible (aussi pénible, voir pire en
> > fait, que du COM en C...
>
> Bon ben c'est chouette ! comme ca on est fixé, le .NET peut aussi se
> considérer comme un composant de plus dans le tas de merde.
Libre à toi de le voir comme ça... tu limites ta vision de .NET à ce que
tu connais: c'est comme le java, c'est comme les "autres merdes", c'est
toujours comme qqch que tu connais, ou semble connaitre... Quand
j'essaie de t'expliquer mon point de vue, je suis soit "cucu" soit
c'est "conceptuellement assez proche", donc je crois pas qu'on puisse
aller plus loin... Cependant si tu veux le faire, je te conseille de
regarder le C# (principalement les delegates, attributes et
éventuellement les futurs generics), winforms, remoting .NET, ADO.NET
et aussi l'ASP.NET si tu as développé quelques applications Web...
peut-être tu comprendras pq certaines personnes trouvent de l'intérêt à
ce "composant de plus dans le tas de merde"...
> En fait, tu as l'air de considérer le framework (l'ensemble des
> classes) comme une boite noires, on y touche pas, si tu veux faire
> un truc qui n'est pas dedans, c'est impossible...
Ben dans la pratique , oui ! Parce que souvent on perd plus de temps à
essayer de comprendre le fonctionnement de tel ou tel composant, on
perd plus de temps à essayer de trouver des biais pour régler des
problèmes de compatibilité et de comportement, d'un windows à l'autre
ou d'une platforme à l'autre, qu'il vaut mieux ne pas s'en servir et
refaire carrément l'objet.
Et c'est finalement ce qui est le plus fiable et le plus serein. C'est
aussi ce qu'il y a de plus portable dans le sens ou c'est vous qui
maitriser le code source...
Je me rappelle y'a quelques années, fallait programme avec MFC ou en
delphi avec la bibliothèque Borland (s'était des surcouche objet des
API WIN32 en fait) c'était soi-disant plus productif, et puis c'était
la technologie du moment , fallait faire du ++ avec un environnement
objet bien compliqué sinon t'étais ringard et dépassé en gros. Bon
ben aujourd'hui on s'apperçoit que bon nombre de développement sur
MFC sont bancales et mal maitrisé par les équipes de développeurs
(qui parfois passe leur semaine pour trouver comment on change la
couleur d'un fond de fenêtre :-), que cela n'a pas pris moins de
temps et que cela n'a pas couter moins cher à faire...
en plus les MFC
ne sont plus maintenus et définitivement abandonné par Microsoft...
alors bon... Les aspect techniques, les possibilité, les concept, les
nouveaux avantages c'est bien... Mais faut pas me demander de miser
dessus.
Quand à savoir à quoi .NET est adapté, Microsoft dit "The .NET
Framework is a new computing platform designed to simplify application
development in the highly distributed environment of the Internet."
et si on se tape toute l'overview de .NET Framework on comprends que
c'est plutot dédié gestion d'entreprise et application partagé sur le
réseau. Donc ca ne peut pas intéresser tout le monde non plus.
> > > > La différence est qu'avec ".NET framework" Microsoft ne
> > > > fournit pas qu'un ensemble de class en librairie (comme MFC)
> > > > mais une runtime aussi.
> > >
> > > Et de nouveau langages de programmation, et une approche
> > > différente (de ce qu'on connaissait en Win32) pour pas mal de
> > > trucs...
> >
> > Et bien parlez en, au lieu de faire l'intéressant avec des phrases
> > génériques...
>
> De quel aspect veux-tu entendre parler?
en quoi l'approche est différente ? est-ce fondamentale ou est-ce
seulement formel !?
qu'est ce qui change fondamentalement et qu'est-ce
qui change seulement formellement ? Bref quoi de neuf quoi...
> Si tu veux un exemple, parmis ce que je trouve le plus intéressant
> en .NET: les attributes. Ca te permet de rajouter des informations à
> une classe, un membre d'une classe, une application, etc... par
> exemple, imagine une structure de donnée quelconque qui doit être
> sérializer sur le disque, en natif, ce qu'on fait souvent, c'est une
> méthode (Serialize par exemple) qui va s'occuper de cela... il est
> difficile de faire beaucoup mieux, si tu ajoutes un membres, tu
> dois modifier ta méthode... en .NET tu vas pouvoir énumérer les
> données membres de ta classe et vérifier si elles ont un attribut
> (Serializable par exemple) et de là agir... autrement dit: ta
> méthode Serialize sera générique. Ca c'est l'exemple trivial, mais
> comme tu peux définir tes propres attributes, y'a moyen de faire
> pas mal de choses avec...
Eh ben. Déjà que je trouvais le ++ chiant parce que y'a trop de
fonction déclarer et d'appel dans tous les sens. Maintenant on verra
carrément plus le code de ce qui se fait. Ca va pas plaire à beaucoup
de ma génération :-))
Bref , on se rapproche des langage descriptif ,
style HTML. C'est pas pour les programmeurs le .NET finalement si !?
:-)
Ha mais y'a rien de contradictoire. on peu trouver de l'intérêt dans
beaucoup de composant Windows et de truc Microsoft. L'ensemble reste
un tas de merde.
Et programmer sous Windows Aujourd'hui c'est comme se
faire une décharge pour bouffer, ca ne manque pas d'intérêt, c'est
juste un peu sale et dégradant :-)
> En fait, tu as l'air de considérer le framework (l'ensemble des
> classes) comme une boite noires, on y touche pas, si tu veux faire
> un truc qui n'est pas dedans, c'est impossible...
Ben dans la pratique , oui ! Parce que souvent on perd plus de temps à
essayer de comprendre le fonctionnement de tel ou tel composant, on
perd plus de temps à essayer de trouver des biais pour régler des
problèmes de compatibilité et de comportement, d'un windows à l'autre
ou d'une platforme à l'autre, qu'il vaut mieux ne pas s'en servir et
refaire carrément l'objet.
Et c'est finalement ce qui est le plus fiable et le plus serein. C'est
aussi ce qu'il y a de plus portable dans le sens ou c'est vous qui
maitriser le code source...
Je me rappelle y'a quelques années, fallait programme avec MFC ou en
delphi avec la bibliothèque Borland (s'était des surcouche objet des
API WIN32 en fait) c'était soi-disant plus productif, et puis c'était
la technologie du moment , fallait faire du ++ avec un environnement
objet bien compliqué sinon t'étais ringard et dépassé en gros. Bon
ben aujourd'hui on s'apperçoit que bon nombre de développement sur
MFC sont bancales et mal maitrisé par les équipes de développeurs
(qui parfois passe leur semaine pour trouver comment on change la
couleur d'un fond de fenêtre :-), que cela n'a pas pris moins de
temps et que cela n'a pas couter moins cher à faire...
en plus les MFC
ne sont plus maintenus et définitivement abandonné par Microsoft...
alors bon... Les aspect techniques, les possibilité, les concept, les
nouveaux avantages c'est bien... Mais faut pas me demander de miser
dessus.
Quand à savoir à quoi .NET est adapté, Microsoft dit "The .NET
Framework is a new computing platform designed to simplify application
development in the highly distributed environment of the Internet."
et si on se tape toute l'overview de .NET Framework on comprends que
c'est plutot dédié gestion d'entreprise et application partagé sur le
réseau. Donc ca ne peut pas intéresser tout le monde non plus.
> > > > La différence est qu'avec ".NET framework" Microsoft ne
> > > > fournit pas qu'un ensemble de class en librairie (comme MFC)
> > > > mais une runtime aussi.
> > >
> > > Et de nouveau langages de programmation, et une approche
> > > différente (de ce qu'on connaissait en Win32) pour pas mal de
> > > trucs...
> >
> > Et bien parlez en, au lieu de faire l'intéressant avec des phrases
> > génériques...
>
> De quel aspect veux-tu entendre parler?
en quoi l'approche est différente ? est-ce fondamentale ou est-ce
seulement formel !?
qu'est ce qui change fondamentalement et qu'est-ce
qui change seulement formellement ? Bref quoi de neuf quoi...
> Si tu veux un exemple, parmis ce que je trouve le plus intéressant
> en .NET: les attributes. Ca te permet de rajouter des informations à
> une classe, un membre d'une classe, une application, etc... par
> exemple, imagine une structure de donnée quelconque qui doit être
> sérializer sur le disque, en natif, ce qu'on fait souvent, c'est une
> méthode (Serialize par exemple) qui va s'occuper de cela... il est
> difficile de faire beaucoup mieux, si tu ajoutes un membres, tu
> dois modifier ta méthode... en .NET tu vas pouvoir énumérer les
> données membres de ta classe et vérifier si elles ont un attribut
> (Serializable par exemple) et de là agir... autrement dit: ta
> méthode Serialize sera générique. Ca c'est l'exemple trivial, mais
> comme tu peux définir tes propres attributes, y'a moyen de faire
> pas mal de choses avec...
Eh ben. Déjà que je trouvais le ++ chiant parce que y'a trop de
fonction déclarer et d'appel dans tous les sens. Maintenant on verra
carrément plus le code de ce qui se fait. Ca va pas plaire à beaucoup
de ma génération :-))
Bref , on se rapproche des langage descriptif ,
style HTML. C'est pas pour les programmeurs le .NET finalement si !?
:-)
Ha mais y'a rien de contradictoire. on peu trouver de l'intérêt dans
beaucoup de composant Windows et de truc Microsoft. L'ensemble reste
un tas de merde.
Et programmer sous Windows Aujourd'hui c'est comme se
faire une décharge pour bouffer, ca ne manque pas d'intérêt, c'est
juste un peu sale et dégradant :-)
> En fait, tu as l'air de considérer le framework (l'ensemble des
> classes) comme une boite noires, on y touche pas, si tu veux faire
> un truc qui n'est pas dedans, c'est impossible...
Ben dans la pratique , oui ! Parce que souvent on perd plus de temps à
essayer de comprendre le fonctionnement de tel ou tel composant, on
perd plus de temps à essayer de trouver des biais pour régler des
problèmes de compatibilité et de comportement, d'un windows à l'autre
ou d'une platforme à l'autre, qu'il vaut mieux ne pas s'en servir et
refaire carrément l'objet.
Et c'est finalement ce qui est le plus fiable et le plus serein. C'est
aussi ce qu'il y a de plus portable dans le sens ou c'est vous qui
maitriser le code source...
Je me rappelle y'a quelques années, fallait programme avec MFC ou en
delphi avec la bibliothèque Borland (s'était des surcouche objet des
API WIN32 en fait) c'était soi-disant plus productif, et puis c'était
la technologie du moment , fallait faire du ++ avec un environnement
objet bien compliqué sinon t'étais ringard et dépassé en gros. Bon
ben aujourd'hui on s'apperçoit que bon nombre de développement sur
MFC sont bancales et mal maitrisé par les équipes de développeurs
(qui parfois passe leur semaine pour trouver comment on change la
couleur d'un fond de fenêtre :-), que cela n'a pas pris moins de
temps et que cela n'a pas couter moins cher à faire...
en plus les MFC
ne sont plus maintenus et définitivement abandonné par Microsoft...
alors bon... Les aspect techniques, les possibilité, les concept, les
nouveaux avantages c'est bien... Mais faut pas me demander de miser
dessus.
Quand à savoir à quoi .NET est adapté, Microsoft dit "The .NET
Framework is a new computing platform designed to simplify application
development in the highly distributed environment of the Internet."
et si on se tape toute l'overview de .NET Framework on comprends que
c'est plutot dédié gestion d'entreprise et application partagé sur le
réseau. Donc ca ne peut pas intéresser tout le monde non plus.
> > > > La différence est qu'avec ".NET framework" Microsoft ne
> > > > fournit pas qu'un ensemble de class en librairie (comme MFC)
> > > > mais une runtime aussi.
> > >
> > > Et de nouveau langages de programmation, et une approche
> > > différente (de ce qu'on connaissait en Win32) pour pas mal de
> > > trucs...
> >
> > Et bien parlez en, au lieu de faire l'intéressant avec des phrases
> > génériques...
>
> De quel aspect veux-tu entendre parler?
en quoi l'approche est différente ? est-ce fondamentale ou est-ce
seulement formel !?
qu'est ce qui change fondamentalement et qu'est-ce
qui change seulement formellement ? Bref quoi de neuf quoi...
> Si tu veux un exemple, parmis ce que je trouve le plus intéressant
> en .NET: les attributes. Ca te permet de rajouter des informations à
> une classe, un membre d'une classe, une application, etc... par
> exemple, imagine une structure de donnée quelconque qui doit être
> sérializer sur le disque, en natif, ce qu'on fait souvent, c'est une
> méthode (Serialize par exemple) qui va s'occuper de cela... il est
> difficile de faire beaucoup mieux, si tu ajoutes un membres, tu
> dois modifier ta méthode... en .NET tu vas pouvoir énumérer les
> données membres de ta classe et vérifier si elles ont un attribut
> (Serializable par exemple) et de là agir... autrement dit: ta
> méthode Serialize sera générique. Ca c'est l'exemple trivial, mais
> comme tu peux définir tes propres attributes, y'a moyen de faire
> pas mal de choses avec...
Eh ben. Déjà que je trouvais le ++ chiant parce que y'a trop de
fonction déclarer et d'appel dans tous les sens. Maintenant on verra
carrément plus le code de ce qui se fait. Ca va pas plaire à beaucoup
de ma génération :-))
Bref , on se rapproche des langage descriptif ,
style HTML. C'est pas pour les programmeurs le .NET finalement si !?
:-)
Ha mais y'a rien de contradictoire. on peu trouver de l'intérêt dans
beaucoup de composant Windows et de truc Microsoft. L'ensemble reste
un tas de merde.
Et programmer sous Windows Aujourd'hui c'est comme se
faire une décharge pour bouffer, ca ne manque pas d'intérêt, c'est
juste un peu sale et dégradant :-)
Bon précisons donc d'abord que ".NET framework" est un environnement de
travail pour faire de l'appli réseau ou déployable réseau (et à vocation
multiplatform) et pas spécialement concu pour faire de l'appli native 32.
Bon précisons donc d'abord que ".NET framework" est un environnement de
travail pour faire de l'appli réseau ou déployable réseau (et à vocation
multiplatform) et pas spécialement concu pour faire de l'appli native 32.
Bon précisons donc d'abord que ".NET framework" est un environnement de
travail pour faire de l'appli réseau ou déployable réseau (et à vocation
multiplatform) et pas spécialement concu pour faire de l'appli native 32.
