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?
Je crois qu'aujourd'hui, la frontière entre les langages compilés et ceux qui sont interprétés est un peu floue.
La frontiere entre langages compiles et interpretes a toujours ete floue. Meme celle entre implementation par un compilateur et un interpreteur l'est depuis longtemps, en particulier pour les systemes lisp...
A un extreme on a l'interpreteur pur et dur repartant de la representation textuelle a chaque fois qu'il execute une instruction et a l'autre le compilateur optimiseur generant de l'assembleur.
Rendant la situation plus ou moins floue, on trouve l'utilisation de representations intermediaires allant d'une tokenization legere (simplement les mots cles) ou complete au byte code qui sont interpretes mais ayant beaucoup ou peu de rapport avec le langage en passant par le threaded code (la representation classique des forths). L'utilisation d'interpreteur de byte code faisant de la compilation JIT. L'utilisation de compilation incrementale. L'optimisation des bytes codes. La compilation/optimisation au link (voir HP) ou au chargement (voir certaines implementations d'Oberon, et celle de reference de C# aussi si j'ai bien compris). L'emulation de processeurs (voir les implementations actuelles des architectures 36 bits d'Unisys et de Dec).
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
DINH Viêt Hoà <dinh.viet.hoa@free.fr> writes:
Je crois qu'aujourd'hui, la frontière entre les langages compilés et
ceux qui sont interprétés est un peu floue.
La frontiere entre langages compiles et interpretes a toujours ete
floue. Meme celle entre implementation par un compilateur et un
interpreteur l'est depuis longtemps, en particulier pour les systemes
lisp...
A un extreme on a l'interpreteur pur et dur repartant de la
representation textuelle a chaque fois qu'il execute une instruction
et a l'autre le compilateur optimiseur generant de l'assembleur.
Rendant la situation plus ou moins floue, on trouve l'utilisation de
representations intermediaires allant d'une tokenization legere
(simplement les mots cles) ou complete au byte code qui sont
interpretes mais ayant beaucoup ou peu de rapport avec le langage en
passant par le threaded code (la representation classique des forths).
L'utilisation d'interpreteur de byte code faisant de la compilation
JIT. L'utilisation de compilation incrementale. L'optimisation des
bytes codes. La compilation/optimisation au link (voir HP) ou au
chargement (voir certaines implementations d'Oberon, et celle de
reference de C# aussi si j'ai bien compris). L'emulation de
processeurs (voir les implementations actuelles des architectures 36
bits d'Unisys et de Dec).
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
Je crois qu'aujourd'hui, la frontière entre les langages compilés et ceux qui sont interprétés est un peu floue.
La frontiere entre langages compiles et interpretes a toujours ete floue. Meme celle entre implementation par un compilateur et un interpreteur l'est depuis longtemps, en particulier pour les systemes lisp...
A un extreme on a l'interpreteur pur et dur repartant de la representation textuelle a chaque fois qu'il execute une instruction et a l'autre le compilateur optimiseur generant de l'assembleur.
Rendant la situation plus ou moins floue, on trouve l'utilisation de representations intermediaires allant d'une tokenization legere (simplement les mots cles) ou complete au byte code qui sont interpretes mais ayant beaucoup ou peu de rapport avec le langage en passant par le threaded code (la representation classique des forths). L'utilisation d'interpreteur de byte code faisant de la compilation JIT. L'utilisation de compilation incrementale. L'optimisation des bytes codes. La compilation/optimisation au link (voir HP) ou au chargement (voir certaines implementations d'Oberon, et celle de reference de C# aussi si j'ai bien compris). L'emulation de processeurs (voir les implementations actuelles des architectures 36 bits d'Unisys et de Dec).
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
Michel Michaud
Dans news:bu4p8u$q7q$, Loïc
Je n'ai pas beaucoup d'expérience de c#, mais le mode de fonctionnmeent préconisé par µsoft c'est un coeur d'application réalisé en langage performant (c++, avec peut-être même des bouts en assembleur), et l'interface avec un langage plus "souple" (par exemple c#) et entre les deux du c++ managé pour jouer le rôle de liant.
Tu peux me dire où tu as vu que c'est ce que préconise MS ?
D'après ce que je lis un peu partout et aussi en considérant les efforts autour du nouveau C++ pour .NET, je crois avoir compris que C# n'a pas eu l'impact attendu. Que pour un langage simple, il y a toujours VB, tout aussi capable que C#.
Par ailleurs, tu peux expliquer en quoi C# est « plus souple » que C++ ? Je ne comprends pas ce que ça veut dire. À force de faire du C++ standard, je trouve un peu désagréable de voir tous ces nouveaux mots clefs commençant par des __ afin de faire du .NET. Mais je n'ai pas encore vu d'endroit où C++ manquait de souplesse. Au contraire, il me semble que C++ peut faire plus de choses que C# : ça c'est la souplesse !
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:bu4p8u$q7q$1@news-reader2.wanadoo.fr, Loïc
Je n'ai pas beaucoup d'expérience de c#, mais le mode de
fonctionnmeent préconisé par µsoft c'est un coeur d'application
réalisé en langage performant (c++, avec peut-être même des bouts
en assembleur), et l'interface avec un langage plus "souple" (par
exemple c#) et entre les deux du c++ managé pour jouer le rôle de
liant.
Tu peux me dire où tu as vu que c'est ce que préconise MS ?
D'après ce que je lis un peu partout et aussi en considérant les
efforts autour du nouveau C++ pour .NET, je crois avoir compris
que C# n'a pas eu l'impact attendu. Que pour un langage simple,
il y a toujours VB, tout aussi capable que C#.
Par ailleurs, tu peux expliquer en quoi C# est « plus souple »
que C++ ? Je ne comprends pas ce que ça veut dire. À force de
faire du C++ standard, je trouve un peu désagréable de voir
tous ces nouveaux mots clefs commençant par des __ afin de
faire du .NET. Mais je n'ai pas encore vu d'endroit où C++
manquait de souplesse. Au contraire, il me semble que C++ peut
faire plus de choses que C# : ça c'est la souplesse !
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Je n'ai pas beaucoup d'expérience de c#, mais le mode de fonctionnmeent préconisé par µsoft c'est un coeur d'application réalisé en langage performant (c++, avec peut-être même des bouts en assembleur), et l'interface avec un langage plus "souple" (par exemple c#) et entre les deux du c++ managé pour jouer le rôle de liant.
Tu peux me dire où tu as vu que c'est ce que préconise MS ?
D'après ce que je lis un peu partout et aussi en considérant les efforts autour du nouveau C++ pour .NET, je crois avoir compris que C# n'a pas eu l'impact attendu. Que pour un langage simple, il y a toujours VB, tout aussi capable que C#.
Par ailleurs, tu peux expliquer en quoi C# est « plus souple » que C++ ? Je ne comprends pas ce que ça veut dire. À force de faire du C++ standard, je trouve un peu désagréable de voir tous ces nouveaux mots clefs commençant par des __ afin de faire du .NET. Mais je n'ai pas encore vu d'endroit où C++ manquait de souplesse. Au contraire, il me semble que C++ peut faire plus de choses que C# : ça c'est la souplesse !
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Adrien Treccani
Hello,
Sans réellement connaître ce langage, je vois quelques inconvénients à C# :
- le langage C# est relativement jeune
L'autre inconvénient est que, tout comme Java, il est interprété.
Le C# (ainsi que tout langage .NET) est un langage compilé. Cela se passe en deux étapes : la compilation en code intermédiaire (MSIL), puis la compilation finale lors de la première exécution sur le poste client. Le code résultant est donc natif et optimisé en fonction de la machine sur lequel il est exécuté. Il existe d'ailleurs des outils pour compiler directement en binaire un "exécutable" .NET.
Bonne soirée
Hello,
Sans réellement connaître ce langage, je vois quelques inconvénients à
C# :
- le langage C# est relativement jeune
L'autre inconvénient est que, tout comme Java, il est interprété.
Le C# (ainsi que tout langage .NET) est un langage compilé. Cela se passe en
deux étapes : la compilation en code intermédiaire (MSIL), puis la
compilation finale lors de la première exécution sur le poste client. Le
code résultant est donc natif et optimisé en fonction de la machine sur
lequel il est exécuté. Il existe d'ailleurs des outils pour compiler
directement en binaire un "exécutable" .NET.
Sans réellement connaître ce langage, je vois quelques inconvénients à C# :
- le langage C# est relativement jeune
L'autre inconvénient est que, tout comme Java, il est interprété.
Le C# (ainsi que tout langage .NET) est un langage compilé. Cela se passe en deux étapes : la compilation en code intermédiaire (MSIL), puis la compilation finale lors de la première exécution sur le poste client. Le code résultant est donc natif et optimisé en fonction de la machine sur lequel il est exécuté. Il existe d'ailleurs des outils pour compiler directement en binaire un "exécutable" .NET.
Bonne soirée
erwan
Admettons que je programme mon application en c++, est ce je peux ou ne dois pas utiliser le framework.net? Si j'ai bien compris, comme en Java, cela nécessite une machine virtuelle (CLR) qui ralentit l'exécution. Je ne pourrai donc pas utiliser les classes qui y sont développés.
Vrai ou faux?
"Jean-Marc Bourguet" a écrit dans le message de news:
DINH Viêt Hoà writes:
Je crois qu'aujourd'hui, la frontière entre les langages compilés et ceux qui sont interprétés est un peu floue.
La frontiere entre langages compiles et interpretes a toujours ete floue. Meme celle entre implementation par un compilateur et un interpreteur l'est depuis longtemps, en particulier pour les systemes lisp...
A un extreme on a l'interpreteur pur et dur repartant de la representation textuelle a chaque fois qu'il execute une instruction et a l'autre le compilateur optimiseur generant de l'assembleur.
Rendant la situation plus ou moins floue, on trouve l'utilisation de representations intermediaires allant d'une tokenization legere (simplement les mots cles) ou complete au byte code qui sont interpretes mais ayant beaucoup ou peu de rapport avec le langage en passant par le threaded code (la representation classique des forths). L'utilisation d'interpreteur de byte code faisant de la compilation JIT. L'utilisation de compilation incrementale. L'optimisation des bytes codes. La compilation/optimisation au link (voir HP) ou au chargement (voir certaines implementations d'Oberon, et celle de reference de C# aussi si j'ai bien compris). L'emulation de processeurs (voir les implementations actuelles des architectures 36 bits d'Unisys et de Dec).
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?
Si j'ai bien compris, comme en Java, cela nécessite une machine virtuelle
(CLR) qui ralentit l'exécution. Je ne pourrai donc pas utiliser les classes
qui y sont développés.
Vrai ou faux?
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message de
news:pxb8yk9m97i.fsf@news.bourguet.org...
DINH Viêt Hoà <dinh.viet.hoa@free.fr> writes:
Je crois qu'aujourd'hui, la frontière entre les langages compilés et
ceux qui sont interprétés est un peu floue.
La frontiere entre langages compiles et interpretes a toujours ete
floue. Meme celle entre implementation par un compilateur et un
interpreteur l'est depuis longtemps, en particulier pour les systemes
lisp...
A un extreme on a l'interpreteur pur et dur repartant de la
representation textuelle a chaque fois qu'il execute une instruction
et a l'autre le compilateur optimiseur generant de l'assembleur.
Rendant la situation plus ou moins floue, on trouve l'utilisation de
representations intermediaires allant d'une tokenization legere
(simplement les mots cles) ou complete au byte code qui sont
interpretes mais ayant beaucoup ou peu de rapport avec le langage en
passant par le threaded code (la representation classique des forths).
L'utilisation d'interpreteur de byte code faisant de la compilation
JIT. L'utilisation de compilation incrementale. L'optimisation des
bytes codes. La compilation/optimisation au link (voir HP) ou au
chargement (voir certaines implementations d'Oberon, et celle de
reference de C# aussi si j'ai bien compris). L'emulation de
processeurs (voir les implementations actuelles des architectures 36
bits d'Unisys et de Dec).
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? Si j'ai bien compris, comme en Java, cela nécessite une machine virtuelle (CLR) qui ralentit l'exécution. Je ne pourrai donc pas utiliser les classes qui y sont développés.
Vrai ou faux?
"Jean-Marc Bourguet" a écrit dans le message de news:
DINH Viêt Hoà writes:
Je crois qu'aujourd'hui, la frontière entre les langages compilés et ceux qui sont interprétés est un peu floue.
La frontiere entre langages compiles et interpretes a toujours ete floue. Meme celle entre implementation par un compilateur et un interpreteur l'est depuis longtemps, en particulier pour les systemes lisp...
A un extreme on a l'interpreteur pur et dur repartant de la representation textuelle a chaque fois qu'il execute une instruction et a l'autre le compilateur optimiseur generant de l'assembleur.
Rendant la situation plus ou moins floue, on trouve l'utilisation de representations intermediaires allant d'une tokenization legere (simplement les mots cles) ou complete au byte code qui sont interpretes mais ayant beaucoup ou peu de rapport avec le langage en passant par le threaded code (la representation classique des forths). L'utilisation d'interpreteur de byte code faisant de la compilation JIT. L'utilisation de compilation incrementale. L'optimisation des bytes codes. La compilation/optimisation au link (voir HP) ou au chargement (voir certaines implementations d'Oberon, et celle de reference de C# aussi si j'ai bien compris). L'emulation de processeurs (voir les implementations actuelles des architectures 36 bits d'Unisys et de Dec).
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
Alexandre
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é.
Oui, mais compilé en pseudo-code (pas en code natif 386) pour une machine virtuelle. Ce pseudo-code est ensuite interprété. En .net ce n'est pas exactement la même chose : il y a un pseudo-code, mais compilé en code natif à la 1ere execution (compilo JIT, just in time), donc executé en natif, donc rapide.
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é.
Et entre les deux, le pseudo-compilé.
Mais je suis sûr qu'un plus spécialiste que moi saura prouver que mon message est un tissu d'âneries ;-)
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é.
Oui, mais compilé en pseudo-code (pas en code natif 386) pour une machine
virtuelle.
Ce pseudo-code est ensuite interprété.
En .net ce n'est pas exactement la même chose : il y a un pseudo-code, mais
compilé en code natif à la 1ere execution (compilo JIT, just in time), donc
executé en natif, donc rapide.
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é.
Et entre les deux, le pseudo-compilé.
Mais je suis sûr qu'un plus spécialiste que moi saura prouver que mon
message est un tissu d'âneries ;-)
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é.
Oui, mais compilé en pseudo-code (pas en code natif 386) pour une machine virtuelle. Ce pseudo-code est ensuite interprété. En .net ce n'est pas exactement la même chose : il y a un pseudo-code, mais compilé en code natif à la 1ere execution (compilo JIT, just in time), donc executé en natif, donc rapide.
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é.
Et entre les deux, le pseudo-compilé.
Mais je suis sûr qu'un plus spécialiste que moi saura prouver que mon message est un tissu d'âneries ;-)
"erwan" a écrit dans le message de news:4006deef$0$24036$
Admettons que je programme mon application en c++, est ce je peux ou ne dois
pas utiliser le framework.net? Si j'ai bien compris, comme en Java, cela nécessite une machine virtuelle (CLR) qui ralentit l'exécution. Je ne pourrai donc pas utiliser les classes
qui y sont développés.
Vrai ou faux?
pas vrai. Tu peux faire du C++ .net, enfin il me semble.
"erwan" <erwanj@free.fr> a écrit dans le message de
news:4006deef$0$24036$626a54ce@news.free.fr...
Admettons que je programme mon application en c++, est ce je peux ou ne
dois
pas utiliser le framework.net?
Si j'ai bien compris, comme en Java, cela nécessite une machine virtuelle
(CLR) qui ralentit l'exécution. Je ne pourrai donc pas utiliser les
classes
qui y sont développés.
Vrai ou faux?
pas vrai. Tu peux faire du C++ .net, enfin il me semble.
"erwan" a écrit dans le message de news:4006deef$0$24036$
Admettons que je programme mon application en c++, est ce je peux ou ne dois
pas utiliser le framework.net? Si j'ai bien compris, comme en Java, cela nécessite une machine virtuelle (CLR) qui ralentit l'exécution. Je ne pourrai donc pas utiliser les classes
qui y sont développés.
Vrai ou faux?
pas vrai. Tu peux faire du C++ .net, enfin il me semble.
DINH Viêt Hoà
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é.
Oui, mais compilé en pseudo-code (pas en code natif 386) pour une machine virtuelle. Ce pseudo-code est ensuite interprété. En .net ce n'est pas exactement la même chose : il y a un pseudo-code, mais compilé en code natif à la 1ere execution (compilo JIT, just in time), donc executé en natif, donc rapide.
les implémentations Java performantes font exactement la même chose.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
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é.
Oui, mais compilé en pseudo-code (pas en code natif 386) pour une machine
virtuelle.
Ce pseudo-code est ensuite interprété.
En .net ce n'est pas exactement la même chose : il y a un pseudo-code, mais
compilé en code natif à la 1ere execution (compilo JIT, just in time), donc
executé en natif, donc rapide.
les implémentations Java performantes font exactement la même chose.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
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é.
Oui, mais compilé en pseudo-code (pas en code natif 386) pour une machine virtuelle. Ce pseudo-code est ensuite interprété. En .net ce n'est pas exactement la même chose : il y a un pseudo-code, mais compilé en code natif à la 1ere execution (compilo JIT, just in time), donc executé en natif, donc rapide.
les implémentations Java performantes font exactement la même chose.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Loïc Joly
Michel Michaud wrote:
Dans news:bu4p8u$q7q$, Loïc
Je n'ai pas beaucoup d'expérience de c#, mais le mode de fonctionnmeent préconisé par µsoft c'est un coeur d'application réalisé en langage performant (c++, avec peut-être même des bouts en assembleur), et l'interface avec un langage plus "souple" (par exemple c#) et entre les deux du c++ managé pour jouer le rôle de liant.
Tu peux me dire où tu as vu que c'est ce que préconise MS ?
C'est ce que j'ai percu à la sortie du truc, que ce soit sur le net ou dans l'aide en ligne (qui par exemple ne documente presqu'aucune fonction en C++ managée). Je n'ai pas de référence possible, et il est possible que µsoft soit revenu en arrière.
D'après ce que je lis un peu partout et aussi en considérant les efforts autour du nouveau C++ pour .NET, je crois avoir compris que C# n'a pas eu l'impact attendu. Que pour un langage simple, il y a toujours VB, tout aussi capable que C#.
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 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 ne comprends pas ce que ça veut dire. À force de faire du C++ standard, je trouve un peu désagréable de voir tous ces nouveaux mots clefs commençant par des __ afin de faire du .NET. Mais je n'ai pas encore vu d'endroit où C++ manquait de souplesse. Au contraire, il me semble que C++ peut faire plus de choses que C# : ça c'est la souplesse !
J'aurais peut-être du dire plus simple, mais j'ai mis le mot "souple" qui me semblait volontairement plus vague.
-- Loïc
Michel Michaud wrote:
Dans news:bu4p8u$q7q$1@news-reader2.wanadoo.fr, Loïc
Je n'ai pas beaucoup d'expérience de c#, mais le mode de
fonctionnmeent préconisé par µsoft c'est un coeur d'application
réalisé en langage performant (c++, avec peut-être même des bouts
en assembleur), et l'interface avec un langage plus "souple" (par
exemple c#) et entre les deux du c++ managé pour jouer le rôle de
liant.
Tu peux me dire où tu as vu que c'est ce que préconise MS ?
C'est ce que j'ai percu à la sortie du truc, que ce soit sur le net ou
dans l'aide en ligne (qui par exemple ne documente presqu'aucune
fonction en C++ managée). Je n'ai pas de référence possible, et il est
possible que µsoft soit revenu en arrière.
D'après ce que je lis un peu partout et aussi en considérant les
efforts autour du nouveau C++ pour .NET, je crois avoir compris
que C# n'a pas eu l'impact attendu. Que pour un langage simple,
il y a toujours VB, tout aussi capable que C#.
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 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 ne comprends pas ce que ça veut dire. À force de
faire du C++ standard, je trouve un peu désagréable de voir
tous ces nouveaux mots clefs commençant par des __ afin de
faire du .NET. Mais je n'ai pas encore vu d'endroit où C++
manquait de souplesse. Au contraire, il me semble que C++ peut
faire plus de choses que C# : ça c'est la souplesse !
J'aurais peut-être du dire plus simple, mais j'ai mis le mot "souple"
qui me semblait volontairement plus vague.
Je n'ai pas beaucoup d'expérience de c#, mais le mode de fonctionnmeent préconisé par µsoft c'est un coeur d'application réalisé en langage performant (c++, avec peut-être même des bouts en assembleur), et l'interface avec un langage plus "souple" (par exemple c#) et entre les deux du c++ managé pour jouer le rôle de liant.
Tu peux me dire où tu as vu que c'est ce que préconise MS ?
C'est ce que j'ai percu à la sortie du truc, que ce soit sur le net ou dans l'aide en ligne (qui par exemple ne documente presqu'aucune fonction en C++ managée). Je n'ai pas de référence possible, et il est possible que µsoft soit revenu en arrière.
D'après ce que je lis un peu partout et aussi en considérant les efforts autour du nouveau C++ pour .NET, je crois avoir compris que C# n'a pas eu l'impact attendu. Que pour un langage simple, il y a toujours VB, tout aussi capable que C#.
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 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 ne comprends pas ce que ça veut dire. À force de faire du C++ standard, je trouve un peu désagréable de voir tous ces nouveaux mots clefs commençant par des __ afin de faire du .NET. Mais je n'ai pas encore vu d'endroit où C++ manquait de souplesse. Au contraire, il me semble que C++ peut faire plus de choses que C# : ça c'est la souplesse !
J'aurais peut-être du dire plus simple, mais j'ai mis le mot "souple" qui me semblait volontairement plus vague.
-- Loïc
Loïc Joly
Ignace wrote:
Par contre, les 20uS me semblent utopiques, en C++ aussi, sur une machine standard. Je crois que c'est tout à fait l'ordre de grandeur de ce qu'on arrive à
faire avec une sous-couche temps réel (comme RTX sous windows, RTLinux ou autres sous Linux).
Il va peut être falloir paralléliser (threads ?), et c'est pas facile.
K'ai du mal à voir en quoi le parallèlisme pourrait améliorer la
performance dans ce genre de cas (au contraire) sauf dans le cas d'une machine multi-processeur.
-- Loïc
Ignace wrote:
Par contre, les 20uS me semblent utopiques, en C++ aussi, sur une machine
standard.
Je crois que c'est tout à fait l'ordre de grandeur de ce qu'on arrive à
faire avec une sous-couche temps réel (comme RTX sous windows, RTLinux
ou autres sous Linux).
Il va peut être falloir paralléliser (threads ?), et c'est pas facile.
K'ai du mal à voir en quoi le parallèlisme pourrait améliorer la
performance dans ce genre de cas (au contraire) sauf dans le cas d'une
machine multi-processeur.
Par contre, les 20uS me semblent utopiques, en C++ aussi, sur une machine standard. Je crois que c'est tout à fait l'ordre de grandeur de ce qu'on arrive à
faire avec une sous-couche temps réel (comme RTX sous windows, RTLinux ou autres sous Linux).
Il va peut être falloir paralléliser (threads ?), et c'est pas facile.
K'ai du mal à voir en quoi le parallèlisme pourrait améliorer la
performance dans ce genre de cas (au contraire) sauf dans le cas d'une machine multi-processeur.
-- Loïc
Loïc Joly
erwan wrote:
Informations complémentaires :
L'API fournit est écrite en C++. Les personnes me les fournissant ne connaissent pas le c#.
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.
Je suis a priori le seul pour programmer cette interface. Tout est à programmer, même les fonctions mathématiques.
N'hésite pas à passer du temps au début de projet pour voir s'il n'existe vraiment rien qui puisse t'aider. Même si une implémentation ne convient pas, je trouve qu'elle peut aider à trouver les bonnes questions à se poser pour faire sa propre implémentation.
Je vais peut être prendre un stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger dans son code...
Le problème est surtout à mon avis qu'il risque de ne pas être plus expérimenté que toi, ou pire encore expérimenté à faire des programmes write only, et que du coup, ni toi ni lui n'apprendront beaucoup. Pour faire un stage réussi, il faut AMA un environnement adéquat.
A priori, l'interface doit tourner sur un pc, peu importe l'os, mais un logiciel équivalent que j'utilise tourne bien sous win98 (je pense qu'il a été développé avec du c++). Si le projet se développe correctement, il est possible qu'on monte plusieurs machines de ce type. Je pense donc essayer de rester si cela est possible sous windows.
Si tu contrôle la diffusion, pourquoi pas, sinon, il peut être intéressant d'utiliser une bibliothèque qui te permette facilement d'éventuellement changer d'OS (en plus, en général, ces bibliothèques ne sont pas les plus mal écrites).
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application mais à mon avis beaucoup plus lourd à programmer.
Plus lourd de maitriser correctement le langage, probablement. Mais probablement aussi moins lourd à utiliser ce même langage. C'est à mon avis avant tout une histoire d'investissement.
-- Loïc
erwan wrote:
Informations complémentaires :
L'API fournit est écrite en C++. Les personnes me les fournissant ne
connaissent pas le c#.
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.
Je suis a priori le seul pour programmer cette interface. Tout est à
programmer, même les fonctions mathématiques.
N'hésite pas à passer du temps au début de projet pour voir s'il
n'existe vraiment rien qui puisse t'aider. Même si une implémentation ne
convient pas, je trouve qu'elle peut aider à trouver les bonnes
questions à se poser pour faire sa propre implémentation.
Je vais peut être prendre un
stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger
dans son code...
Le problème est surtout à mon avis qu'il risque de ne pas être plus
expérimenté que toi, ou pire encore expérimenté à faire des programmes
write only, et que du coup, ni toi ni lui n'apprendront beaucoup. Pour
faire un stage réussi, il faut AMA un environnement adéquat.
A priori, l'interface doit tourner sur un pc, peu importe l'os, mais un
logiciel équivalent que j'utilise tourne bien sous win98 (je pense qu'il a
été développé avec du c++). Si le projet se développe correctement, il est
possible qu'on monte plusieurs machines de ce type. Je pense donc essayer de
rester si cela est possible sous windows.
Si tu contrôle la diffusion, pourquoi pas, sinon, il peut être
intéressant d'utiliser une bibliothèque qui te permette facilement
d'éventuellement changer d'OS (en plus, en général, ces bibliothèques ne
sont pas les plus mal écrites).
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application
mais à mon avis beaucoup plus lourd à programmer.
Plus lourd de maitriser correctement le langage, probablement. Mais
probablement aussi moins lourd à utiliser ce même langage. C'est à mon
avis avant tout une histoire d'investissement.
L'API fournit est écrite en C++. Les personnes me les fournissant ne connaissent pas le c#.
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.
Je suis a priori le seul pour programmer cette interface. Tout est à programmer, même les fonctions mathématiques.
N'hésite pas à passer du temps au début de projet pour voir s'il n'existe vraiment rien qui puisse t'aider. Même si une implémentation ne convient pas, je trouve qu'elle peut aider à trouver les bonnes questions à se poser pour faire sa propre implémentation.
Je vais peut être prendre un stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger dans son code...
Le problème est surtout à mon avis qu'il risque de ne pas être plus expérimenté que toi, ou pire encore expérimenté à faire des programmes write only, et que du coup, ni toi ni lui n'apprendront beaucoup. Pour faire un stage réussi, il faut AMA un environnement adéquat.
A priori, l'interface doit tourner sur un pc, peu importe l'os, mais un logiciel équivalent que j'utilise tourne bien sous win98 (je pense qu'il a été développé avec du c++). Si le projet se développe correctement, il est possible qu'on monte plusieurs machines de ce type. Je pense donc essayer de rester si cela est possible sous windows.
Si tu contrôle la diffusion, pourquoi pas, sinon, il peut être intéressant d'utiliser une bibliothèque qui te permette facilement d'éventuellement changer d'OS (en plus, en général, ces bibliothèques ne sont pas les plus mal écrites).
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application mais à mon avis beaucoup plus lourd à programmer.
Plus lourd de maitriser correctement le langage, probablement. Mais probablement aussi moins lourd à utiliser ce même langage. C'est à mon avis avant tout une histoire d'investissement.
