Bonjour à tous,
voici ma question : quel langage choisir entre c++ et c#?
je vous expose mon projet :
Je dois développer une application windows qui est un logiciel de pilotage
d'une machine se composant d'un bloc moteur et d'un module d'électronique
(émission et réception de signaux). Je dois réaliser une interface graphique
conviale pour afficher ces données. Le gros problème est la vitesse
d'exécution. Le bloc moteur et l'électronique me seront livrés avec une API.
Typiquement, je dois déclenché un signal d'excitation sur un capteur,
attendre sa réponse ( de l'ordre de 20µs), enregistrer ce signal, le
convertir en signal video (une transformée de Hilbert, qui doit prendre plus
ou moins le même temps que de faire une FFT), déplacer le capteur avec le
bloc moteur de qques pas, et recommencer ainsi de suite pour former une
image enregistrable.Actuellement, j'aimerai faire entre 30 images par
secondes composées de 400 lignes, soit environ 1200 lignes traitées par
seconde. L'affichage devra être en temps réel.
Il est peut être nécessaire de coder la transformation de Hilbert en langage
très bas niveau pour que cela soit traité en temps réel.
C# est-il plus lent que c++?
Je pense que la réalisation de ce projet est plus simple en c# mais peut
être pas assez rapide.
Avez vous des idées ou des commentaires?
On Thu, 15 Jan 2004 19:38:21 +0100, "erwan" wrote:
Admettons que je programme mon application en c++, est ce je peux ou ne dois pas utiliser le framework.net?
C'est plutôt une question pour fr.comp.os.ms-windows.programmation. Mais bon, ce framework est un outil, commence par décider si tu en as besoin ou pas.
On Thu, 15 Jan 2004 19:38:21 +0100, "erwan" <erwanj@free.fr> wrote:
Admettons que je programme mon application en c++, est ce je peux ou ne dois
pas utiliser le framework.net?
C'est plutôt une question pour fr.comp.os.ms-windows.programmation.
Mais bon, ce framework est un outil, commence par décider si tu en as
besoin ou pas.
On Thu, 15 Jan 2004 19:38:21 +0100, "erwan" wrote:
Admettons que je programme mon application en c++, est ce je peux ou ne dois pas utiliser le framework.net?
C'est plutôt une question pour fr.comp.os.ms-windows.programmation. Mais bon, ce framework est un outil, commence par décider si tu en as besoin ou pas.
On Thu, 15 Jan 2004 23:07:54 +0100, Loïc Joly wrote:
Effectivement, mon niveau de programmation est en c++ ou c# est proche du niveau zero.
C'est dur de se lancer directement dans un tel programme sans bagages ni personne de plus expérimenté pour remettre sur les rails de temps en temps. Je ne connais pas vraiment ton contexte, mais je me poserai la question de faire ce produit avec une boîte de prestation. Ca a certe un coût, mais ne pas le faire a aussi un coût.
La question est de savoir ce qu'il compte faire après. S'il s'agit de passer quelques mois à apprendre un langage juste pour ce projet, effectivement la sous-traitance risque d'être plus économique. Si l'OP compte continuer à faire de la programmation son activité principal, l'apprentissage sera un bon investissement.
On Thu, 15 Jan 2004 23:07:54 +0100, Loïc Joly
<loic.actarus.joly@wanadoo.fr> wrote:
Effectivement, mon niveau de programmation est en c++ ou c# est proche du
niveau zero.
C'est dur de se lancer directement dans un tel programme sans bagages ni
personne de plus expérimenté pour remettre sur les rails de temps en
temps. Je ne connais pas vraiment ton contexte, mais je me poserai la
question de faire ce produit avec une boîte de prestation. Ca a certe un
coût, mais ne pas le faire a aussi un coût.
La question est de savoir ce qu'il compte faire après.
S'il s'agit de passer quelques mois à apprendre un langage juste pour
ce projet, effectivement la sous-traitance risque d'être plus
économique.
Si l'OP compte continuer à faire de la programmation son activité
principal, l'apprentissage sera un bon investissement.
On Thu, 15 Jan 2004 23:07:54 +0100, Loïc Joly wrote:
Effectivement, mon niveau de programmation est en c++ ou c# est proche du niveau zero.
C'est dur de se lancer directement dans un tel programme sans bagages ni personne de plus expérimenté pour remettre sur les rails de temps en temps. Je ne connais pas vraiment ton contexte, mais je me poserai la question de faire ce produit avec une boîte de prestation. Ca a certe un coût, mais ne pas le faire a aussi un coût.
La question est de savoir ce qu'il compte faire après. S'il s'agit de passer quelques mois à apprendre un langage juste pour ce projet, effectivement la sous-traitance risque d'être plus économique. Si l'OP compte continuer à faire de la programmation son activité principal, l'apprentissage sera un bon investissement.
Admettons que je programme mon application en c++, est ce je peux ou ne dois pas utiliser le framework.net?
Je ne connais assez bien no le framework .net, ni ton application ni le contexte dans lequel tu la developpes pour te repondre.
Si j'ai bien compris, comme en Java, cela nécessite une machine virtuelle (CLR)
Si j'ai bien compris, CLR est plutot destine a etre compile avant l'execution plutot qu'interprete ou utilise avec un compilateur JIT qui detecte ce qu'il pense etre utile d'optimise (ce qui est le cas de Java).
qui ralentit l'exécution.
Quel sont tes criteres de performances?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"erwan" <erwanj@free.fr> writes:
Admettons que je programme mon application en c++, est ce je peux ou
ne dois pas utiliser le framework.net?
Je ne connais assez bien no le framework .net, ni ton application ni
le contexte dans lequel tu la developpes pour te repondre.
Si j'ai bien compris, comme en Java, cela nécessite une machine virtuelle
(CLR)
Si j'ai bien compris, CLR est plutot destine a etre compile avant
l'execution plutot qu'interprete ou utilise avec un compilateur JIT
qui detecte ce qu'il pense etre utile d'optimise (ce qui est le cas de
Java).
qui ralentit l'exécution.
Quel sont tes criteres de performances?
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Admettons que je programme mon application en c++, est ce je peux ou ne dois pas utiliser le framework.net?
Je ne connais assez bien no le framework .net, ni ton application ni le contexte dans lequel tu la developpes pour te repondre.
Si j'ai bien compris, comme en Java, cela nécessite une machine virtuelle (CLR)
Si j'ai bien compris, CLR est plutot destine a etre compile avant l'execution plutot qu'interprete ou utilise avec un compilateur JIT qui detecte ce qu'il pense etre utile d'optimise (ce qui est le cas de Java).
qui ralentit l'exécution.
Quel sont tes criteres de performances?
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ
On Thu, 15 Jan 2004 00:49:18 +0100, "erwan" wrote:
j'aimerai faire entre 30 images par secondes composées de 400 lignes, soit environ 1200 lignes traitées par seconde
On Thu, 15 Jan 2004 09:24:30 +0100, DINH Viêt Hoà wrote:
L'autre inconvénient est que, tout comme Java, il est interprété.
Si je ne m'abuse, Java n'est pas interprété. Un programme Java est compilé à chaque exécution.
Ça dépend du VM. C'est le cas avec le VM Sun sous Windows, et je crois aussi sous Solaris, mais je ne crois pas que ce soit le cas pour toutes les plateformes.
Mais enfin, puisqu'il parle de travaille sous Windows...
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<sn7d00hoho8f70g7nu0oiaon0k1qo7i17u@4ax.com>...
On Thu, 15 Jan 2004 09:24:30 +0100, DINH Viêt Hoà
<dinh.viet.hoa@free.fr> wrote:
L'autre inconvénient est que, tout comme Java, il est interprété.
Si je ne m'abuse, Java n'est pas interprété. Un programme Java est
compilé à chaque exécution.
Ça dépend du VM. C'est le cas avec le VM Sun sous Windows, et je crois
aussi sous Solaris, mais je ne crois pas que ce soit le cas pour toutes
les plateformes.
Mais enfin, puisqu'il parle de travaille sous Windows...
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
On Thu, 15 Jan 2004 09:24:30 +0100, DINH Viêt Hoà wrote:
L'autre inconvénient est que, tout comme Java, il est interprété.
Si je ne m'abuse, Java n'est pas interprété. Un programme Java est compilé à chaque exécution.
Ça dépend du VM. C'est le cas avec le VM Sun sous Windows, et je crois aussi sous Solaris, mais je ne crois pas que ce soit le cas pour toutes les plateformes.
Mais enfin, puisqu'il parle de travaille sous Windows...
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Fabien LE LEZ
On 16 Jan 2004 00:40:38 -0800, wrote:
Mais enfin, puisqu'il parle de travaille sous Windows...
Et qu'il n'envisage pas de programmer pour Java de toutes façons... ;-)
On Thu, 15 Jan 2004 16:59:04 +0100, DINH Viêt Hoà wrote:
Si je ne m'abuse, Java n'est pas interprété. Un programme Java est compilé à chaque exécution.
Comme tout langage interprété, non ?
Oui et non. À la fin, quelque soit la technique utilisée, il faut bien executer des instructions machine de la machine en question. N'empêche que quand on parle d'un langage interprété, c'est assez rare que les instructions du programme soient traduit en code machine.
Non. PHP, par exemple, lit une instruction, l'évalue, et fait les actions que l'instruction lui demande. Du moins, c'est ce que j'ai cru comprendre.
C'est le cas le plus courant. Pour une définition adéquate de «@instruction ».
La première question, précisement, c'est ce qu'on entend par « instruction ». Est-ce une ligne de source, une instruction d'une machine virtuelle, voire une instruction machine d'une autre architecture. J'ai déjà vu les interpréteurs de Basic qui stockait le programme en texte pûr, et réparsait la ligne chaque fois qu'il l'executait. Même les commentaires avaient un temps d'execution non nul.
La plupart des interpréteurs aujourd'hui travaille avec une machine virtuelle, en compilant le programme au préalable en machine virtuelle. La compilation peut être explicite et externe (c'est le cas de Java), ou implicite, chaque fois que le programme s'exécute (c'est le cas de Perl, je crois.)
Java, au contraire, et si mes souvenirs sont bons, compile le programme (pré-digéré) au début, ce qui en fait un exécutable (en mémoire), qui est lancé.
Tout dépend de l'implémentation. Les premiers Java se contentaient simplement d'interpréter (au sens classique) le code VM. Ensuite, il y a eu des compilateurs JIT -- une fonction était compilée la première fois qu'elle était appelée (et les sites d'appel dans le code déjà généré était patché pour appeler le code généré, plutôt que le compilateur interne). Les dernières versions que j'ai utilisée (qui sont pas si récentes non plus) utilisaient une technique qu'ils appelaient Hot-Spot@: en gros, l'interpréteur faisait du profiling en parallel, et quand il trouvait un chemin critique, il le compilait, en l'optimisant pour les données qu'ils avaient déjà vue, et en le préfixant des vérifications que ses suppositions étaient vraies.
Enfin ça dépend de la définition de langage interprété. Je crois qu'aujourd'hui, la frontière entre les langages compilés et ceux qui sont interprétés est un peu floue.
J'ai l'impression que la frontière n'est pas si floue que ça : Il y a les langages interprétés, où l'interpréteur lit chaque instruction, tente de la comprendre, et fait ce qu'elle demande (l'exemple le plus flagrant étant le langage de script de Windows (.BAT), où on peut modifier le code pendant l'exécution, en modifiant le fichier .BAT). Et il y a les langages compilés, où le code est transformé en exécutable (que ce soit chez le développeur ou chez le client), puis cet exécutable est lancé.
Je crois que c'est bien flou. Quand tu executes un programme Java sous Windows, avec les JDK récents au moins, il y aura des gros blocs complétement compilés qui s'exécute en langage machine pûre, et d'autres parties qui restent entièrement en code VM interprété.
Et en ce qui concerne la modification du code pendant l'exécution, Sun Workshop le supporte en C++. Bien compilé. Tandis que des interpréteurs Java, y compris les premiers, bien classique, non, parce que la traduction en code VM était externe de l'interpréteur.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Fabien LE LEZ <gramster@gramster.com> wrote in message
news:<m3gd0095pn49n59c19hi79bafairm7oqn6@4ax.com>...
On Thu, 15 Jan 2004 16:59:04 +0100, DINH Viêt Hoà
<dinh.viet.hoa@free.fr> wrote:
Si je ne m'abuse, Java n'est pas interprété. Un programme Java est
compilé à chaque exécution.
Comme tout langage interprété, non ?
Oui et non. À la fin, quelque soit la technique utilisée, il faut bien
executer des instructions machine de la machine en question. N'empêche
que quand on parle d'un langage interprété, c'est assez rare que les
instructions du programme soient traduit en code machine.
Non. PHP, par exemple, lit une instruction, l'évalue, et fait les
actions que l'instruction lui demande. Du moins, c'est ce que j'ai cru
comprendre.
C'est le cas le plus courant. Pour une définition adéquate de
«@instruction ».
La première question, précisement, c'est ce qu'on entend par
« instruction ». Est-ce une ligne de source, une instruction d'une
machine virtuelle, voire une instruction machine d'une autre
architecture. J'ai déjà vu les interpréteurs de Basic qui stockait le
programme en texte pûr, et réparsait la ligne chaque fois qu'il
l'executait. Même les commentaires avaient un temps d'execution non nul.
La plupart des interpréteurs aujourd'hui travaille avec une machine
virtuelle, en compilant le programme au préalable en machine virtuelle.
La compilation peut être explicite et externe (c'est le cas de Java), ou
implicite, chaque fois que le programme s'exécute (c'est le cas de Perl,
je crois.)
Java, au contraire, et si mes souvenirs sont bons, compile le
programme (pré-digéré) au début, ce qui en fait un exécutable (en
mémoire), qui est lancé.
Tout dépend de l'implémentation. Les premiers Java se contentaient
simplement d'interpréter (au sens classique) le code VM. Ensuite, il y a
eu des compilateurs JIT -- une fonction était compilée la première fois
qu'elle était appelée (et les sites d'appel dans le code déjà généré
était patché pour appeler le code généré, plutôt que le compilateur
interne). Les dernières versions que j'ai utilisée (qui sont pas si
récentes non plus) utilisaient une technique qu'ils appelaient
Hot-Spot@: en gros, l'interpréteur faisait du profiling en parallel, et
quand il trouvait un chemin critique, il le compilait, en l'optimisant
pour les données qu'ils avaient déjà vue, et en le préfixant des
vérifications que ses suppositions étaient vraies.
Enfin ça dépend de la définition de langage interprété. Je crois
qu'aujourd'hui, la frontière entre les langages compilés et ceux qui
sont interprétés est un peu floue.
J'ai l'impression que la frontière n'est pas si floue que ça : Il y a
les langages interprétés, où l'interpréteur lit chaque instruction,
tente de la comprendre, et fait ce qu'elle demande (l'exemple le plus
flagrant étant le langage de script de Windows (.BAT), où on peut
modifier le code pendant l'exécution, en modifiant le fichier .BAT).
Et il y a les langages compilés, où le code est transformé en
exécutable (que ce soit chez le développeur ou chez le client), puis
cet exécutable est lancé.
Je crois que c'est bien flou. Quand tu executes un programme Java sous
Windows, avec les JDK récents au moins, il y aura des gros blocs
complétement compilés qui s'exécute en langage machine pûre, et d'autres
parties qui restent entièrement en code VM interprété.
Et en ce qui concerne la modification du code pendant l'exécution, Sun
Workshop le supporte en C++. Bien compilé. Tandis que des interpréteurs
Java, y compris les premiers, bien classique, non, parce que la
traduction en code VM était externe de l'interpréteur.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
On Thu, 15 Jan 2004 16:59:04 +0100, DINH Viêt Hoà wrote:
Si je ne m'abuse, Java n'est pas interprété. Un programme Java est compilé à chaque exécution.
Comme tout langage interprété, non ?
Oui et non. À la fin, quelque soit la technique utilisée, il faut bien executer des instructions machine de la machine en question. N'empêche que quand on parle d'un langage interprété, c'est assez rare que les instructions du programme soient traduit en code machine.
Non. PHP, par exemple, lit une instruction, l'évalue, et fait les actions que l'instruction lui demande. Du moins, c'est ce que j'ai cru comprendre.
C'est le cas le plus courant. Pour une définition adéquate de «@instruction ».
La première question, précisement, c'est ce qu'on entend par « instruction ». Est-ce une ligne de source, une instruction d'une machine virtuelle, voire une instruction machine d'une autre architecture. J'ai déjà vu les interpréteurs de Basic qui stockait le programme en texte pûr, et réparsait la ligne chaque fois qu'il l'executait. Même les commentaires avaient un temps d'execution non nul.
La plupart des interpréteurs aujourd'hui travaille avec une machine virtuelle, en compilant le programme au préalable en machine virtuelle. La compilation peut être explicite et externe (c'est le cas de Java), ou implicite, chaque fois que le programme s'exécute (c'est le cas de Perl, je crois.)
Java, au contraire, et si mes souvenirs sont bons, compile le programme (pré-digéré) au début, ce qui en fait un exécutable (en mémoire), qui est lancé.
Tout dépend de l'implémentation. Les premiers Java se contentaient simplement d'interpréter (au sens classique) le code VM. Ensuite, il y a eu des compilateurs JIT -- une fonction était compilée la première fois qu'elle était appelée (et les sites d'appel dans le code déjà généré était patché pour appeler le code généré, plutôt que le compilateur interne). Les dernières versions que j'ai utilisée (qui sont pas si récentes non plus) utilisaient une technique qu'ils appelaient Hot-Spot@: en gros, l'interpréteur faisait du profiling en parallel, et quand il trouvait un chemin critique, il le compilait, en l'optimisant pour les données qu'ils avaient déjà vue, et en le préfixant des vérifications que ses suppositions étaient vraies.
Enfin ça dépend de la définition de langage interprété. Je crois qu'aujourd'hui, la frontière entre les langages compilés et ceux qui sont interprétés est un peu floue.
J'ai l'impression que la frontière n'est pas si floue que ça : Il y a les langages interprétés, où l'interpréteur lit chaque instruction, tente de la comprendre, et fait ce qu'elle demande (l'exemple le plus flagrant étant le langage de script de Windows (.BAT), où on peut modifier le code pendant l'exécution, en modifiant le fichier .BAT). Et il y a les langages compilés, où le code est transformé en exécutable (que ce soit chez le développeur ou chez le client), puis cet exécutable est lancé.
Je crois que c'est bien flou. Quand tu executes un programme Java sous Windows, avec les JDK récents au moins, il y aura des gros blocs complétement compilés qui s'exécute en langage machine pûre, et d'autres parties qui restent entièrement en code VM interprété.
Et en ce qui concerne la modification du code pendant l'exécution, Sun Workshop le supporte en C++. Bien compilé. Tandis que des interpréteurs Java, y compris les premiers, bien classique, non, parce que la traduction en code VM était externe de l'interpréteur.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Fabien LE LEZ
On 16 Jan 2004 01:18:36 -0800, wrote:
Et en ce qui concerne la modification du code pendant l'exécution, Sun Workshop le supporte en C++. Bien compilé.
Tiens ? Comment ça marche ? Il recompile le programme tout en sauvegardant le contexte ?
-- ;-)
On 16 Jan 2004 01:18:36 -0800, kanze@gabi-soft.fr wrote:
Et en ce qui concerne la modification du code pendant l'exécution, Sun
Workshop le supporte en C++. Bien compilé.
Tiens ? Comment ça marche ? Il recompile le programme tout en
sauvegardant le contexte ?
Et en ce qui concerne la modification du code pendant l'exécution, Sun Workshop le supporte en C++. Bien compilé.
Tiens ? Comment ça marche ? Il recompile le programme tout en sauvegardant le contexte ?
-- ;-)
Michel Michaud
Dans news:bu71vj$adl$, Loïc
Michel Michaud wrote:
Par ailleurs, tu peux expliquer en quoi C# est « plus souple » que C++ ?
Difficilement, d'où mes '"' autour du mot souple. Je reprennais toujours cette impression plutôt que d'exprimer mon opinion dans cette partie du message. Si je devais trouver des avantages de souplesse de c# par rapport à du C++ managé, je dirais du peux que j'en connais : - Faire du c++ managé, c'est comme développer en C++ en fermant les yeux et en utilisant les orteils plutôt que les doigts, juste pour le plaisir de souffrir. Alors qu'utiliser un
Tu parles de la syntaxe qui est plus lourde ? C'est qu'on a encore les autres possibilités. Qui dit plus de possibilités, dit syntaxe plus complexe :-) Mais vraiment, ce n'est pas si complexe que ça (et ce sera vraiment plus « beau » avec le nouveau C++ pour .NET qui est annoncé pour 2004).
autre langage a tendance à moins faire regretter en permanence ce qu'il n'est pas possible de faire. - L'éditeur est plus abouti en c# qu'en c++ (je pense que .NET 2003 a un peu réduit l'écart par rapport à .NET 2002) (souligner les erreurs de syntaxe au fur et à mesure de la frappe...), probablement suite à une plus grande simplicité à parser un langage moins riche.
Je crois que tu confonds VB avec C#. Je ne vois pas la différence entre C# et VB au niveau de l'éditeur et des outils (je parle de .NET 2003... mais il n'y a pas moins pour C# dans 2003, juste plus pour C++ au niveau développement visuel). Et moi, en VB, j'ai de la difficulté à accepter qu'un éditeur me dise comment je dois écrire le code !
Encore une fois, mon impression est que, oui, C++ est peut-être un peu complexe pour certains types de développement, mais VB est alors un meilleur choix que C#. Mais je ne suis pas un très bon juge, j'aime le choix des possibilités de C++ et je ne vois aucun intérêt à VB non plus :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:bu71vj$adl$1@news-reader1.wanadoo.fr, Loïc
Michel Michaud wrote:
Par ailleurs, tu peux expliquer en quoi C# est « plus souple »
que C++ ?
Difficilement, d'où mes '"' autour du mot souple. Je reprennais
toujours cette impression plutôt que d'exprimer mon opinion dans
cette partie du message. Si je devais trouver des avantages de
souplesse de c# par rapport à du C++ managé, je dirais du peux que
j'en connais : - Faire du c++ managé, c'est comme développer en C++
en fermant les yeux et en utilisant les orteils plutôt que les
doigts, juste pour le plaisir de souffrir. Alors qu'utiliser un
Tu parles de la syntaxe qui est plus lourde ? C'est qu'on a encore
les autres possibilités. Qui dit plus de possibilités, dit syntaxe
plus complexe :-) Mais vraiment, ce n'est pas si complexe que ça
(et ce sera vraiment plus « beau » avec le nouveau C++ pour .NET
qui est annoncé pour 2004).
autre langage a tendance à moins faire regretter en permanence ce
qu'il n'est pas possible de faire. - L'éditeur est plus abouti en
c# qu'en c++ (je pense que .NET 2003 a un peu réduit l'écart par
rapport à .NET 2002) (souligner les erreurs de syntaxe au fur et à
mesure de la frappe...), probablement suite à une plus grande
simplicité à parser un langage moins riche.
Je crois que tu confonds VB avec C#. Je ne vois pas la différence
entre C# et VB au niveau de l'éditeur et des outils (je parle de
.NET 2003... mais il n'y a pas moins pour C# dans 2003, juste
plus pour C++ au niveau développement visuel). Et moi, en VB,
j'ai de la difficulté à accepter qu'un éditeur me dise comment
je dois écrire le code !
Encore une fois, mon impression est que, oui, C++ est peut-être
un peu complexe pour certains types de développement, mais VB
est alors un meilleur choix que C#. Mais je ne suis pas un très
bon juge, j'aime le choix des possibilités de C++ et je ne vois
aucun intérêt à VB non plus :-)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Par ailleurs, tu peux expliquer en quoi C# est « plus souple » que C++ ?
Difficilement, d'où mes '"' autour du mot souple. Je reprennais toujours cette impression plutôt que d'exprimer mon opinion dans cette partie du message. Si je devais trouver des avantages de souplesse de c# par rapport à du C++ managé, je dirais du peux que j'en connais : - Faire du c++ managé, c'est comme développer en C++ en fermant les yeux et en utilisant les orteils plutôt que les doigts, juste pour le plaisir de souffrir. Alors qu'utiliser un
Tu parles de la syntaxe qui est plus lourde ? C'est qu'on a encore les autres possibilités. Qui dit plus de possibilités, dit syntaxe plus complexe :-) Mais vraiment, ce n'est pas si complexe que ça (et ce sera vraiment plus « beau » avec le nouveau C++ pour .NET qui est annoncé pour 2004).
autre langage a tendance à moins faire regretter en permanence ce qu'il n'est pas possible de faire. - L'éditeur est plus abouti en c# qu'en c++ (je pense que .NET 2003 a un peu réduit l'écart par rapport à .NET 2002) (souligner les erreurs de syntaxe au fur et à mesure de la frappe...), probablement suite à une plus grande simplicité à parser un langage moins riche.
Je crois que tu confonds VB avec C#. Je ne vois pas la différence entre C# et VB au niveau de l'éditeur et des outils (je parle de .NET 2003... mais il n'y a pas moins pour C# dans 2003, juste plus pour C++ au niveau développement visuel). Et moi, en VB, j'ai de la difficulté à accepter qu'un éditeur me dise comment je dois écrire le code !
Encore une fois, mon impression est que, oui, C++ est peut-être un peu complexe pour certains types de développement, mais VB est alors un meilleur choix que C#. Mais je ne suis pas un très bon juge, j'aime le choix des possibilités de C++ et je ne vois aucun intérêt à VB non plus :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
