Windiws Longhorn: le C n est t'il plus le langage de prédilection de programmation pour atteindre le systéme ?

David Scrève

15/09/2003 à 18:49

"Thierry" a écrit dans le message de news:

Bonjour,

David Scrève a écrit :

>> 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.
> Multi-platforme...hahaha, la bonne blague....Ca fait 2 ans que ca
> tourne...que sous Windows, et encore, pas
> complètement sous Win64 Itanium.

Y'a le projeyt Mono pour faire tourner ça sous Linux.

Autrement dit, environ le quart a été porté sous Linux....et même pas par Microsoft....Pas mal comme
effort d'ouverture, mais peut mieux faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas en natif...

David

15/09/2003 à 20:47

Ambassadeur Kosh wrote:

> "...expliquant comment .NET va remplacer Visual C++, et dans quelle
mesures

ben ça va se passer comme ça.

Démarrer / Paramètres / Panneaux de configuration / Ajouter Supprimer
/ MSDN Démarrer / Paramètres / Panneaux de configuration / Ajouter
Supprimer /
Visual Studio 6.0 / Supprimer
Installer Visual Studio .Net 2003
Installer MSDN .Net
Démarrer / Programmes / MVS .Net 2003 / Microsoft Visual Studio .Net
2003

dans quelles mesures : selon qu'il y aura assez de place sur le disque
ou que la machine trainera pas trop son boulet.

mdr! excellent, j'aime bcp ;)

--
Quentin Pouplard (Tene/MyOE)
http://www.myoe.org | http://graff.alrj.org

15/09/2003 à 20:50

Marre du spam wrote:

Autrement dit, environ le quart a été porté sous Linux...

Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un peu
d'optimisation, une bonne partie du framework (sans winforms), c'est
plutôt prometteur je trouve, maintenant c'est clair que le projet est
jeune, faut pas s'attendre à qqch capable de tourner en prod dans 6
mois.

.et même
pas par Microsoft....Pas mal comme effort d'ouverture, mais peut mieux
faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas
en natif...

Les windows form, bien que sympathique, sont très fort mappé sur
Windows, donc un portage revient à réécrire une bonne partie de windows
:-/

Pour les gui, il semble que le projet le plus prometteur soit #WT un
port de SWT. Ce n'est pas encore super utilisable, mais ça vient.

Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas cela
comme une solution faite pour être portable, mais plutôt comme une
plate-forme pouvant être portable si on fait attention. A l'image du
C/C++ portable si on utilise les libs qui vont bien... l'avantage
évidemment est que le framework .NET couvre bcp plus de domaines que la
libc ou la STL C++.

--
Quentin Pouplard (Tene/MyOE)
http://www.myoe.org | http://graff.alrj.org

David Scrève

15/09/2003 à 21:47

a écrit dans le message de news:

Marre du spam wrote:
> Autrement dit, environ le quart a été porté sous Linux...

Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un peu
d'optimisation, une bonne partie du framework (sans winforms), c'est
plutôt prometteur je trouve, maintenant c'est clair que le projet est
jeune, faut pas s'attendre à qqch capable de tourner en prod dans 6
mois.

Donc, d'un point de vue production, ce n'est pas portable....

> .et même
> pas par Microsoft....Pas mal comme effort d'ouverture, mais peut mieux
> faire. En plus, les Windows Forms tournent au dessus de Wine, meme pas
> en natif...

Les windows form, bien que sympathique, sont très fort mappé sur
Windows, donc un portage revient à réécrire une bonne partie de windows
:-/

Bref, on n'a pas avancé, mais on a rajouté une surcouche à un système existant....

Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas cela
comme une solution faite pour être portable, mais plutôt comme une
plate-forme pouvant être portable si on fait attention. A l'image du
C/C++ portable si on utilise les libs qui vont bien... l'avantage
évidemment est que le framework .NET couvre bcp plus de domaines que la
libc ou la STL C++.

La question est donc : Pourquoi ne pas avoir fait simplement une lib C++ de GUI qui soit portable
plutot que de faire une autre surcouche qui n'est pas vraiment portable et qui fait moins bien que Java et que
C++ dans chacun des domaines existants ?
J'ai un peu l'impression que le marketing a fait dépenser pas mal d'énergie n'importe comment au lieu de se baser
sur un existant parfaitement évolutif qui ne demandait qu'à évoluer...

David

Ambassadeur Kosh

16/09/2003 à 08:54

> mdr! excellent, j'aime bcp ;)

merci. j'espere que l'occasion de retourner le compliment se présentera :)

Thierry

16/09/2003 à 13:09

Bonjour,

David Scrève a écrit :

Sans vouloir troller, quand on pousse la réflexion un peu plus, on se
dit qu'il faudrait mieux changer d'OS.
Ce que je fais derechef, d'ailleurs (adieu monde cruel).

C'est clair qu'en matière de Framework, Cocoa et PowerPlant ont
l'air plutot excitants....

Je ne le trouve pas mal celui de .Net. J'y ai trouvé quelques resemblances
avec celui de BeOS (au niveau GUI).

--
"MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"

adebaene

16/09/2003 à 14:43

"David Scrève" <Marre du spam> wrote in message news:<3f66175d$0$20644$...

plutot que de faire une autre surcouche qui n'est pas vraiment portable et qui fait moins bien que Java et que
C++ dans chacun des domaines existants ?

Ca, ce serait le boulot du comité de normalisation du C++, pas de
Microsoft. Si tu tiens vraiement à poser la question sur c.l.c.++.m et
supporter le flamewar qui va suivre, libre à toi :-). Ceci dit, je ne
pense pas que ce soit le boulot ni du C++ ni de MS de fournir un GUI
portable.

J'ai un peu l'impression que le marketing a fait dépenser pas mal d'énergie n'importe comment au lieu de se baser
sur un existant parfaitement évolutif qui ne demandait qu'à évoluer...

Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans
l'absolu, ce ne sont pas de bonnes raison mais il faut rester
pragmatique :
- complexité du C++ : Il n'y a pas beaucoup de programmeurs C++
compétents.
- Poids de l'historique, qui fait que beaucoup de gens qui prétendent
faire du C++ font en fait du C.

Arnaud

Arnold McDonald $AMcD$

16/09/2003 à 15:49

Arnaud Debaene wrote:

Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans
l'absolu, ce ne sont pas de bonnes raison mais il faut rester
pragmatique :
- complexité du C++ : Il n'y a pas beaucoup de programmeurs C++
compétents.

Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ? Cela dit, c'est
vrai que le code C++ écrit par des gars qui veulement démontrer qu'ils ont
bien compris les templates, le multi-héritage, la surcharge et autres
joyeusetés est tout simplement illisible. Point trop n'en faut non plus.

- Poids de l'historique, qui fait que beaucoup de gens qui prétendent
faire du C++ font en fait du C.

Tout à fait. D'où l'expression si souvent décriée (à tort) C/C++.

Arnaud

--
AMcD - http://arnold.mcdonald.free.fr/

"Bon alors j'vous rappelle les règles : vous pouvez pas quitter la première
base avant d'avoir vidé une bière, chaque point marqué : une bière, vous
videz une bière à la fin des tours de frappe impairs et à la quatrième
manche, tournée générale"
- ça va, ça va, on sait comment jouer au softball ! (Les Simpson - Homer la
Foudre)

16/09/2003 à 18:25

Marre du spam wrote:

> Marre du spam wrote:
> > Autrement dit, environ le quart a été porté sous Linux...
>
> Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un
> peu d'optimisation, une bonne partie du framework (sans winforms),
> c'est plutôt prometteur je trouve, maintenant c'est clair que le
> projet est jeune, faut pas s'attendre à qqch capable de tourner en
> prod dans 6
> mois.
Donc, d'un point de vue production, ce n'est pas portable....

Bah, je suis plus patient que toi ;)

Mais non c'est clair, .NET sous linux n'est pas encore prêt, mais est-ce
que .NET pour windows est déjà prêt? perso, je me lancerais pas encore
les yeux fermé dans un projet .NET... c'est humain: si c'est
professionnel, je reste dans ce que je connais et crois maitriser un
peu ;)

> > .et même
> > pas par Microsoft....Pas mal comme effort d'ouverture, mais peut
> > mieux faire. En plus, les Windows Forms tournent au dessus de
> > Wine, meme pas en natif...
>
> Les windows form, bien que sympathique, sont très fort mappé sur
> Windows, donc un portage revient à réécrire une bonne partie de
> windows :-/
Bref, on n'a pas avancé, mais on a rajouté une surcouche à un
système existant....

Oui et non, si tu le prends comme ça, depuis qu'on sait faire un ou et
un not, l'informatique n'a pas avancé;)

Le fait est que .NET doit bien faire appel à windows, puisque c'est
windows qui fournit les interfaces graphiques (l'os est conçu comme
cela, est-ce bien ou mal, on peut en discuter, mais ce n'est pas
vraiment le sujet), sous linux ce n'est pas le cas, linux ne fournit
rien et X non plus, il faut donc faire quelques choses au dessus, soit
tu t'arranges pour que ce quelques choses ressemblent aux services
offert par windows, et ça s'appelle wine, soit tu vas devoir t'arranger
pour que le comportement de winforms restent cohérent au dessus d'une
couche ne fournissant pas le même genre de service, ou en tous cas pas
de la même façon. Cependant, mais on a encore que très peu d'info, il
semblerait que le futur windows change cela en fournissant un autre
service de gestion de GUI... ptêt l'occasion d'effacer quelques
conneries de winforms?

Cette approche a tout de même un avantage: tu as la rapidité du natif
(ce que java n'a pas, swing est une horreur!) et une abstractoin
beaucoup plus simple d'emploi (même si elle a ses défauts) que Win32.
Et c'est d'ailleurs ce que j'aime bien à winforms: tu fais rapidement
une "belle" IHM, et si tu dois quand même aller voir ta pompe à
message, c'est possible...

Maintenant, je me demandaisi, tu développes beaucoup de produit GUI
portable? dans quel langage? en dehors des IDE java et de quelques
outils souvent à usage interne, je n'en ai pas beaucoup vu, c'est le
cas pour toi?

> Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas
> cela comme une solution faite pour être portable, mais plutôt comme
> une plate-forme pouvant être portable si on fait attention. A
> l'image du C/C++ portable si on utilise les libs qui vont bien...
> l'avantage évidemment est que le framework .NET couvre bcp plus de
> domaines que la libc ou la STL C++.
La question est donc : Pourquoi ne pas avoir fait simplement une
lib C++ de GUI qui soit portable plutot que de faire une autre
surcouche qui n'est pas vraiment portable et qui fait moins bien que
Java et que C++ dans chacun des domaines existants ?

Tout d'abord C++ n'est qu'un langage, les lib qui viennent avec n'offre
que très peu de services, et vu le temps que ça met à évoluer, je peux
comprendre qu'une boite telle que ms, préfère faire son truc à elle...
(d'ailleurs qu'est ce qui existe comme framework C++ élégant, moderne,
portable???)

Concernant java, il faut à nouveau séparer le langage de la plate-forme,
concernant le langage, c'est plus une question de gout (je préfère le C#
de loin, mais je n'ai jamais lu d'argument absolu ni pour l'un ni pour
l'autre). Concernant la plate-forme, elles ont des approches souvent un
peu différentes, je préfère également travailllé avec .NET, et .NET
offre certains avantage (versionning, déploiement, gestion des
resources, etc...) comme il doit avoir également ses défauts...

J'ai un peu l'impression que le marketing a fait dépenser pas mal
d'énergie n'importe comment au lieu de se baser sur un existant
parfaitement évolutif qui ne demandait qu'à évoluer...

Tu crois réellement que ça ne demande qu'à évoluer? regarde le nombre de
développement encore fait en C (voir des trucs encore pire ;), regarde
le temps que met une norme pour évoluer, combien de siècle crois-tu
qu'il aura fallu pour faire bouffer l'équivalent de .NET à n'importe
quel "existant parfaitement évolutif" ? Même java est mou, c'est
d'ailleurs son gros défaut, et c'est là dessus qu'il pourrait perdre
par rapport à .NET... le C# existe depuis 2 ans et C# 2.0 est déjà en
train d'être normalisé... le java existe depuis beaucoup plus longtemps
et le langage n'a pas évolué, on en parle, pour le futur java 1.5,
mais... ça vient quand?

Il faut aussi tenir compte de la complexité du C++, comme le soulève
très justement Arnaud, il est plus simple de programmer (mal) en C#
qu'en C++... et je pense qu'il est plus simple de programmer
correctement en C# qu'en C++... en tous cas y'a déjà pas mal d'erreur
que tu ne pourras pas faire en C#...

--
Quentin Pouplard (Tene/MyOE)
http://www.myoe.org | http://graff.alrj.org

Marre du spam wrote:

> Marre du spam wrote:
> > Autrement dit, environ le quart a été porté sous Linux...
>
> Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un
> peu d'optimisation, une bonne partie du framework (sans winforms),
> c'est plutôt prometteur je trouve, maintenant c'est clair que le
> projet est jeune, faut pas s'attendre à qqch capable de tourner en
> prod dans 6
> mois.
Donc, d'un point de vue production, ce n'est pas portable....

Bah, je suis plus patient que toi ;)

Mais non c'est clair, .NET sous linux n'est pas encore prêt, mais est-ce
que .NET pour windows est déjà prêt? perso, je me lancerais pas encore
les yeux fermé dans un projet .NET... c'est humain: si c'est
professionnel, je reste dans ce que je connais et crois maitriser un
peu ;)

> > .et même
> > pas par Microsoft....Pas mal comme effort d'ouverture, mais peut
> > mieux faire. En plus, les Windows Forms tournent au dessus de
> > Wine, meme pas en natif...
>
> Les windows form, bien que sympathique, sont très fort mappé sur
> Windows, donc un portage revient à réécrire une bonne partie de
> windows :-/
Bref, on n'a pas avancé, mais on a rajouté une surcouche à un
système existant....

Oui et non, si tu le prends comme ça, depuis qu'on sait faire un ou et
un not, l'informatique n'a pas avancé;)

Le fait est que .NET doit bien faire appel à windows, puisque c'est
windows qui fournit les interfaces graphiques (l'os est conçu comme
cela, est-ce bien ou mal, on peut en discuter, mais ce n'est pas
vraiment le sujet), sous linux ce n'est pas le cas, linux ne fournit
rien et X non plus, il faut donc faire quelques choses au dessus, soit
tu t'arranges pour que ce quelques choses ressemblent aux services
offert par windows, et ça s'appelle wine, soit tu vas devoir t'arranger
pour que le comportement de winforms restent cohérent au dessus d'une
couche ne fournissant pas le même genre de service, ou en tous cas pas
de la même façon. Cependant, mais on a encore que très peu d'info, il
semblerait que le futur windows change cela en fournissant un autre
service de gestion de GUI... ptêt l'occasion d'effacer quelques
conneries de winforms?

Cette approche a tout de même un avantage: tu as la rapidité du natif
(ce que java n'a pas, swing est une horreur!) et une abstractoin
beaucoup plus simple d'emploi (même si elle a ses défauts) que Win32.
Et c'est d'ailleurs ce que j'aime bien à winforms: tu fais rapidement
une "belle" IHM, et si tu dois quand même aller voir ta pompe à
message, c'est possible...

Maintenant, je me demandaisi, tu développes beaucoup de produit GUI
portable? dans quel langage? en dehors des IDE java et de quelques
outils souvent à usage interne, je n'en ai pas beaucoup vu, c'est le
cas pour toi?

> Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas
> cela comme une solution faite pour être portable, mais plutôt comme
> une plate-forme pouvant être portable si on fait attention. A
> l'image du C/C++ portable si on utilise les libs qui vont bien...
> l'avantage évidemment est que le framework .NET couvre bcp plus de
> domaines que la libc ou la STL C++.
La question est donc : Pourquoi ne pas avoir fait simplement une
lib C++ de GUI qui soit portable plutot que de faire une autre
surcouche qui n'est pas vraiment portable et qui fait moins bien que
Java et que C++ dans chacun des domaines existants ?

Tout d'abord C++ n'est qu'un langage, les lib qui viennent avec n'offre
que très peu de services, et vu le temps que ça met à évoluer, je peux
comprendre qu'une boite telle que ms, préfère faire son truc à elle...
(d'ailleurs qu'est ce qui existe comme framework C++ élégant, moderne,
portable???)

Concernant java, il faut à nouveau séparer le langage de la plate-forme,
concernant le langage, c'est plus une question de gout (je préfère le C#
de loin, mais je n'ai jamais lu d'argument absolu ni pour l'un ni pour
l'autre). Concernant la plate-forme, elles ont des approches souvent un
peu différentes, je préfère également travailllé avec .NET, et .NET
offre certains avantage (versionning, déploiement, gestion des
resources, etc...) comme il doit avoir également ses défauts...

J'ai un peu l'impression que le marketing a fait dépenser pas mal
d'énergie n'importe comment au lieu de se baser sur un existant
parfaitement évolutif qui ne demandait qu'à évoluer...

Tu crois réellement que ça ne demande qu'à évoluer? regarde le nombre de
développement encore fait en C (voir des trucs encore pire ;), regarde
le temps que met une norme pour évoluer, combien de siècle crois-tu
qu'il aura fallu pour faire bouffer l'équivalent de .NET à n'importe
quel "existant parfaitement évolutif" ? Même java est mou, c'est
d'ailleurs son gros défaut, et c'est là dessus qu'il pourrait perdre
par rapport à .NET... le C# existe depuis 2 ans et C# 2.0 est déjà en
train d'être normalisé... le java existe depuis beaucoup plus longtemps
et le langage n'a pas évolué, on en parle, pour le futur java 1.5,
mais... ça vient quand?

Il faut aussi tenir compte de la complexité du C++, comme le soulève
très justement Arnaud, il est plus simple de programmer (mal) en C#
qu'en C++... et je pense qu'il est plus simple de programmer
correctement en C# qu'en C++... en tous cas y'a déjà pas mal d'erreur
que tu ne pourras pas faire en C#...

--
Quentin Pouplard (Tene/MyOE)
http://www.myoe.org | http://graff.alrj.org

Vous avez filtré cet utilisateur ! Consultez son message

Marre du spam wrote:

> Marre du spam wrote:
> > Autrement dit, environ le quart a été porté sous Linux...
>
> Le quart de quoi? y'a quand même déjà de quoi compiler, exécuter, un
> peu d'optimisation, une bonne partie du framework (sans winforms),
> c'est plutôt prometteur je trouve, maintenant c'est clair que le
> projet est jeune, faut pas s'attendre à qqch capable de tourner en
> prod dans 6
> mois.
Donc, d'un point de vue production, ce n'est pas portable....

Bah, je suis plus patient que toi ;)

Mais non c'est clair, .NET sous linux n'est pas encore prêt, mais est-ce
que .NET pour windows est déjà prêt? perso, je me lancerais pas encore
les yeux fermé dans un projet .NET... c'est humain: si c'est
professionnel, je reste dans ce que je connais et crois maitriser un
peu ;)

> > .et même
> > pas par Microsoft....Pas mal comme effort d'ouverture, mais peut
> > mieux faire. En plus, les Windows Forms tournent au dessus de
> > Wine, meme pas en natif...
>
> Les windows form, bien que sympathique, sont très fort mappé sur
> Windows, donc un portage revient à réécrire une bonne partie de
> windows :-/
Bref, on n'a pas avancé, mais on a rajouté une surcouche à un
système existant....

Oui et non, si tu le prends comme ça, depuis qu'on sait faire un ou et
un not, l'informatique n'a pas avancé;)

Le fait est que .NET doit bien faire appel à windows, puisque c'est
windows qui fournit les interfaces graphiques (l'os est conçu comme
cela, est-ce bien ou mal, on peut en discuter, mais ce n'est pas
vraiment le sujet), sous linux ce n'est pas le cas, linux ne fournit
rien et X non plus, il faut donc faire quelques choses au dessus, soit
tu t'arranges pour que ce quelques choses ressemblent aux services
offert par windows, et ça s'appelle wine, soit tu vas devoir t'arranger
pour que le comportement de winforms restent cohérent au dessus d'une
couche ne fournissant pas le même genre de service, ou en tous cas pas
de la même façon. Cependant, mais on a encore que très peu d'info, il
semblerait que le futur windows change cela en fournissant un autre
service de gestion de GUI... ptêt l'occasion d'effacer quelques
conneries de winforms?

Cette approche a tout de même un avantage: tu as la rapidité du natif
(ce que java n'a pas, swing est une horreur!) et une abstractoin
beaucoup plus simple d'emploi (même si elle a ses défauts) que Win32.
Et c'est d'ailleurs ce que j'aime bien à winforms: tu fais rapidement
une "belle" IHM, et si tu dois quand même aller voir ta pompe à
message, c'est possible...

Maintenant, je me demandaisi, tu développes beaucoup de produit GUI
portable? dans quel langage? en dehors des IDE java et de quelques
outils souvent à usage interne, je n'en ai pas beaucoup vu, c'est le
cas pour toi?

> Vu l'orientation de .NET (interrop, P/Invoke), perso, je vois pas
> cela comme une solution faite pour être portable, mais plutôt comme
> une plate-forme pouvant être portable si on fait attention. A
> l'image du C/C++ portable si on utilise les libs qui vont bien...
> l'avantage évidemment est que le framework .NET couvre bcp plus de
> domaines que la libc ou la STL C++.
La question est donc : Pourquoi ne pas avoir fait simplement une
lib C++ de GUI qui soit portable plutot que de faire une autre
surcouche qui n'est pas vraiment portable et qui fait moins bien que
Java et que C++ dans chacun des domaines existants ?

Tout d'abord C++ n'est qu'un langage, les lib qui viennent avec n'offre
que très peu de services, et vu le temps que ça met à évoluer, je peux
comprendre qu'une boite telle que ms, préfère faire son truc à elle...
(d'ailleurs qu'est ce qui existe comme framework C++ élégant, moderne,
portable???)

Concernant java, il faut à nouveau séparer le langage de la plate-forme,
concernant le langage, c'est plus une question de gout (je préfère le C#
de loin, mais je n'ai jamais lu d'argument absolu ni pour l'un ni pour
l'autre). Concernant la plate-forme, elles ont des approches souvent un
peu différentes, je préfère également travailllé avec .NET, et .NET
offre certains avantage (versionning, déploiement, gestion des
resources, etc...) comme il doit avoir également ses défauts...

J'ai un peu l'impression que le marketing a fait dépenser pas mal
d'énergie n'importe comment au lieu de se baser sur un existant
parfaitement évolutif qui ne demandait qu'à évoluer...

Tu crois réellement que ça ne demande qu'à évoluer? regarde le nombre de
développement encore fait en C (voir des trucs encore pire ;), regarde
le temps que met une norme pour évoluer, combien de siècle crois-tu
qu'il aura fallu pour faire bouffer l'équivalent de .NET à n'importe
quel "existant parfaitement évolutif" ? Même java est mou, c'est
d'ailleurs son gros défaut, et c'est là dessus qu'il pourrait perdre
par rapport à .NET... le C# existe depuis 2 ans et C# 2.0 est déjà en
train d'être normalisé... le java existe depuis beaucoup plus longtemps
et le langage n'a pas évolué, on en parle, pour le futur java 1.5,
mais... ça vient quand?

Il faut aussi tenir compte de la complexité du C++, comme le soulève
très justement Arnaud, il est plus simple de programmer (mal) en C#
qu'en C++... et je pense qu'il est plus simple de programmer
correctement en C# qu'en C++... en tous cas y'a déjà pas mal d'erreur
que tu ne pourras pas faire en C#...

--
Quentin Pouplard (Tene/MyOE)
http://www.myoe.org | http://graff.alrj.org

Arnaud Debaene

16/09/2003 à 19:59

Arnold McDonald (AMcD) wrote:

Arnaud Debaene wrote:

Il y a des raisons de s'éloigner du C++ pour certaines choses. Dans
l'absolu, ce ne sont pas de bonnes raison mais il faut rester
pragmatique :
- complexité du C++ : Il n'y a pas beaucoup de programmeurs C++
compétents.

Houla ! T'es cap' de poster celui-là sur fr.xxx.c++ :o) ?

Bah, je sais que ceux qui lisent là-bas et ici sont d'accord avec moi :-)

- Poids de l'historique, qui fait que beaucoup de gens qui prétendent
faire du C++ font en fait du C.

Tout à fait. D'où l'expression si souvent décriée (à tort) C/C++.

Yep.

Arnaud

Windiws Longhorn: le C n est t'il plus le langage de prédilection de programmation pour atteindre le systéme ?

10 réponses

Veuillez sélectionner un problème