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?
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?
Toutes les aides seront bienvenues.
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.
D'autres critères sont aussi à prendre en compte : - L'API à utiliser est fournie pour quel langage ? - Es-tu sur de ne pas avoir à porter ce logiciel ailleurs que sous windows dans un futur plus ou moins proche (auquel cas une structure type C++ / (wxWindows ou QT) serait peut-être un gain important) - Quels langages connais-tu, et les autres membres du projet ? - Si ton système a une problèmatique temps réel, tu va peut-être devoir prendre un OS adapté. Des choses existent avec windows (RTX de venturcom, par exemple), mais tu es limité dans ton choix de langages pour la partie temps réel.
-- Loïc
erwan wrote:
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?
Toutes les aides seront bienvenues.
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.
D'autres critères sont aussi à prendre en compte :
- L'API à utiliser est fournie pour quel langage ?
- Es-tu sur de ne pas avoir à porter ce logiciel ailleurs que sous
windows dans un futur plus ou moins proche (auquel cas une structure
type C++ / (wxWindows ou QT) serait peut-être un gain important)
- Quels langages connais-tu, et les autres membres du projet ?
- Si ton système a une problèmatique temps réel, tu va peut-être devoir
prendre un OS adapté. Des choses existent avec windows (RTX de
venturcom, par exemple), mais tu es limité dans ton choix de langages
pour la partie temps réel.
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?
Toutes les aides seront bienvenues.
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.
D'autres critères sont aussi à prendre en compte : - L'API à utiliser est fournie pour quel langage ? - Es-tu sur de ne pas avoir à porter ce logiciel ailleurs que sous windows dans un futur plus ou moins proche (auquel cas une structure type C++ / (wxWindows ou QT) serait peut-être un gain important) - Quels langages connais-tu, et les autres membres du projet ? - Si ton système a une problèmatique temps réel, tu va peut-être devoir prendre un OS adapté. Des choses existent avec windows (RTX de venturcom, par exemple), mais tu es limité dans ton choix de langages pour la partie temps réel.
-- Loïc
Fabien LE LEZ
On Thu, 15 Jan 2004 00:49:18 +0100, "erwan" wrote:
voici ma question : quel langage choisir entre c++ et c#?
Le C++, bien sûr ! On n'est pas sur fclc++ pour rien ;-)
Plus sérieusement, je vois deux critères pour ton choix : d'une part, comme l'a dit Loïc, il faut voir quel(s) langage(s) s'interfacent bien avec l'API fournie, mais aussi avec les bibliothèques mathématiques utilisées (à moins que tu ne cherches à tout recoder toi-même). D'autre part, et en supposant que tu ne connais aucun des deux langages (sinon tu ne poserais pas la question), sache qu'apprendre un langage comme C++ est un gros investissement (en temps). Aussi, il me paraît judicieux de faire le choix non seulement par rapport à ton projet, mais aussi par rapport aux projets futurs. Sans réellement connaître ce langage, je vois quelques inconvénients à C# : - c'est du pur Microsoft, donc si à un moment ou un autre la politique de M$ te paraît insupportable, ben c'est tant pis pour toi. - le langage C# est relativement jeune, et, connaissant Microsoft, j'ai des doutes sur sa pérennité à long terme, ainsi que sur la stabilité du langage (Mais ça vient sans doute de mes expériences malheureuses avec VB4 totalement incompatible avec VB3 et VB5). Mais encore une fois, ce n'est que le point de vue (peut-être partial) de quelqu'un qui ne programme pas en C#.
On Thu, 15 Jan 2004 00:49:18 +0100, "erwan" <erwanj@free.fr> wrote:
voici ma question : quel langage choisir entre c++ et c#?
Le C++, bien sûr ! On n'est pas sur fclc++ pour rien ;-)
Plus sérieusement, je vois deux critères pour ton choix : d'une part,
comme l'a dit Loïc, il faut voir quel(s) langage(s) s'interfacent bien
avec l'API fournie, mais aussi avec les bibliothèques mathématiques
utilisées (à moins que tu ne cherches à tout recoder toi-même).
D'autre part, et en supposant que tu ne connais aucun des deux
langages (sinon tu ne poserais pas la question), sache qu'apprendre un
langage comme C++ est un gros investissement (en temps). Aussi, il me
paraît judicieux de faire le choix non seulement par rapport à ton
projet, mais aussi par rapport aux projets futurs. Sans réellement
connaître ce langage, je vois quelques inconvénients à C# :
- c'est du pur Microsoft, donc si à un moment ou un autre la
politique de M$ te paraît insupportable, ben c'est tant pis pour toi.
- le langage C# est relativement jeune, et, connaissant
Microsoft, j'ai des doutes sur sa pérennité à long terme, ainsi que
sur la stabilité du langage (Mais ça vient sans doute de mes
expériences malheureuses avec VB4 totalement incompatible avec VB3 et
VB5).
Mais encore une fois, ce n'est que le point de vue (peut-être partial)
de quelqu'un qui ne programme pas en C#.
On Thu, 15 Jan 2004 00:49:18 +0100, "erwan" wrote:
voici ma question : quel langage choisir entre c++ et c#?
Le C++, bien sûr ! On n'est pas sur fclc++ pour rien ;-)
Plus sérieusement, je vois deux critères pour ton choix : d'une part, comme l'a dit Loïc, il faut voir quel(s) langage(s) s'interfacent bien avec l'API fournie, mais aussi avec les bibliothèques mathématiques utilisées (à moins que tu ne cherches à tout recoder toi-même). D'autre part, et en supposant que tu ne connais aucun des deux langages (sinon tu ne poserais pas la question), sache qu'apprendre un langage comme C++ est un gros investissement (en temps). Aussi, il me paraît judicieux de faire le choix non seulement par rapport à ton projet, mais aussi par rapport aux projets futurs. Sans réellement connaître ce langage, je vois quelques inconvénients à C# : - c'est du pur Microsoft, donc si à un moment ou un autre la politique de M$ te paraît insupportable, ben c'est tant pis pour toi. - le langage C# est relativement jeune, et, connaissant Microsoft, j'ai des doutes sur sa pérennité à long terme, ainsi que sur la stabilité du langage (Mais ça vient sans doute de mes expériences malheureuses avec VB4 totalement incompatible avec VB3 et VB5). Mais encore une fois, ce n'est que le point de vue (peut-être partial) de quelqu'un qui ne programme pas en C#.
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é. Tu auras d'ailleurs peut-être plus de pérénnité avec Java. Mais toujours pas de temps réel possible à moins d'avoir un C# ou un Java adapté au temps réel.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
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é. Tu
auras d'ailleurs peut-être plus de pérénnité avec Java. Mais toujours
pas de temps réel possible à moins d'avoir un C# ou un Java adapté au
temps réel.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
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é. Tu auras d'ailleurs peut-être plus de pérénnité avec Java. Mais toujours pas de temps réel possible à moins d'avoir un C# ou un Java adapté au temps réel.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
erwan
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.
Je suis a priori le seul pour programmer cette interface. Tout est à programmer, même les fonctions mathématiques. Je vais peut être prendre un stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger dans son code...
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.
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application mais à mon avis beaucoup plus lourd à programmer.
Merci de vos commentaires.
A+
"DINH Viêt Hoà" a écrit dans le message de news:
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é. Tu auras d'ailleurs peut-être plus de pérénnité avec Java. Mais toujours pas de temps réel possible à moins d'avoir un C# ou un Java adapté au temps réel.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
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.
Je suis a priori le seul pour programmer cette interface. Tout est à
programmer, même les fonctions mathématiques. Je vais peut être prendre un
stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger
dans son code...
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.
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application
mais à mon avis beaucoup plus lourd à programmer.
Merci de vos commentaires.
A+
"DINH Viêt Hoà" <dinh.viet.hoa@free.fr> a écrit dans le message de
news:etPan.40064e3e.20a4c31f.4b04@homer...
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é. Tu
auras d'ailleurs peut-être plus de pérénnité avec Java. Mais toujours
pas de temps réel possible à moins d'avoir un C# ou un Java adapté au
temps réel.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
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.
Je suis a priori le seul pour programmer cette interface. Tout est à programmer, même les fonctions mathématiques. Je vais peut être prendre un stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger dans son code...
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.
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application mais à mon avis beaucoup plus lourd à programmer.
Merci de vos commentaires.
A+
"DINH Viêt Hoà" a écrit dans le message de news:
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é. Tu auras d'ailleurs peut-être plus de pérénnité avec Java. Mais toujours pas de temps réel possible à moins d'avoir un C# ou un Java adapté au temps réel.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
DINH Viêt Hoà
Je suis a priori le seul pour programmer cette interface. Tout est à programmer, même les fonctions mathématiques. Je vais peut être prendre un stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger dans son code...
1er commandement : "Sur les doigts du stagiaire tu taperas afin qu'il respecte ton standard de coding"
2ème commandement : "Même si son standard est mieux que le tien, se référer au premier commandement"
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application mais à mon avis beaucoup plus lourd à programmer.
car, effectivement, pas de garbage collector en C++ (sauf éventuellement le garbage collector de Boehm).
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Je suis a priori le seul pour programmer cette interface. Tout est à
programmer, même les fonctions mathématiques. Je vais peut être prendre un
stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger
dans son code...
1er commandement :
"Sur les doigts du stagiaire tu taperas afin qu'il respecte ton standard
de coding"
2ème commandement :
"Même si son standard est mieux que le tien, se référer au premier
commandement"
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application
mais à mon avis beaucoup plus lourd à programmer.
car, effectivement, pas de garbage collector en C++ (sauf éventuellement
le garbage collector de Boehm).
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Je suis a priori le seul pour programmer cette interface. Tout est à programmer, même les fonctions mathématiques. Je vais peut être prendre un stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger dans son code...
1er commandement : "Sur les doigts du stagiaire tu taperas afin qu'il respecte ton standard de coding"
2ème commandement : "Même si son standard est mieux que le tien, se référer au premier commandement"
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application mais à mon avis beaucoup plus lourd à programmer.
car, effectivement, pas de garbage collector en C++ (sauf éventuellement le garbage collector de Boehm).
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Ignace
"DINH Viêt Hoà" a écrit dans le message de news:
Je suis a priori le seul pour programmer cette interface. Tout est à programmer, même les fonctions mathématiques. Je vais peut être prendre un
stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger
dans son code...
1er commandement : "Sur les doigts du stagiaire tu taperas afin qu'il respecte ton standard de coding"
2ème commandement : "Même si son standard est mieux que le tien, se référer au premier commandement"
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application
mais à mon avis beaucoup plus lourd à programmer.
car, effectivement, pas de garbage collector en C++ (sauf éventuellement le garbage collector de Boehm).
C'est pas un peu hâtif de parler de garbage collector à un débutant ? Je préférerai dire à Erwan qu'il devra gérer sa mémoire à l'octet prêt (ce qui peut être compliqué) en C++, alors qu'avec le C#, ce n'est pas nécessaire. Mais qu'en tant que "semi interprété", le C# risque d'être plus lent. Même s'il s'appuie sur des "composants" (portions de codes complexes) théoriquement optimisés.
Par contre, les 20uS me semblent utopiques, en C++ aussi, sur une machine standard. Il va peut être falloir paralléliser (threads ?), et c'est pas facile.
-- Ignace
"DINH Viêt Hoà" <dinh.viet.hoa@free.fr> a écrit dans le message de
news:etPan.40066347.4590f267.4b04@homer...
Je suis a priori le seul pour programmer cette interface. Tout est à
programmer, même les fonctions mathématiques. Je vais peut être prendre
un
stagiaire pour soutenir ce projet. Le problème ensuite c'est de se
replonger
dans son code...
1er commandement :
"Sur les doigts du stagiaire tu taperas afin qu'il respecte ton standard
de coding"
2ème commandement :
"Même si son standard est mieux que le tien, se référer au premier
commandement"
C'est vrai que le c++ a l'air de mieux convenir pour ce type
d'application
mais à mon avis beaucoup plus lourd à programmer.
car, effectivement, pas de garbage collector en C++ (sauf éventuellement
le garbage collector de Boehm).
C'est pas un peu hâtif de parler de garbage collector à un débutant ?
Je préférerai dire à Erwan qu'il devra gérer sa mémoire à l'octet prêt (ce
qui peut être compliqué) en C++,
alors qu'avec le C#, ce n'est pas nécessaire. Mais qu'en tant que "semi
interprété", le C# risque d'être plus lent.
Même s'il s'appuie sur des "composants" (portions de codes complexes)
théoriquement optimisés.
Par contre, les 20uS me semblent utopiques, en C++ aussi, sur une machine
standard.
Il va peut être falloir paralléliser (threads ?), et c'est pas facile.
Je suis a priori le seul pour programmer cette interface. Tout est à programmer, même les fonctions mathématiques. Je vais peut être prendre un
stagiaire pour soutenir ce projet. Le problème ensuite c'est de se replonger
dans son code...
1er commandement : "Sur les doigts du stagiaire tu taperas afin qu'il respecte ton standard de coding"
2ème commandement : "Même si son standard est mieux que le tien, se référer au premier commandement"
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application
mais à mon avis beaucoup plus lourd à programmer.
car, effectivement, pas de garbage collector en C++ (sauf éventuellement le garbage collector de Boehm).
C'est pas un peu hâtif de parler de garbage collector à un débutant ? Je préférerai dire à Erwan qu'il devra gérer sa mémoire à l'octet prêt (ce qui peut être compliqué) en C++, alors qu'avec le C#, ce n'est pas nécessaire. Mais qu'en tant que "semi interprété", le C# risque d'être plus lent. Même s'il s'appuie sur des "composants" (portions de codes complexes) théoriquement optimisés.
Par contre, les 20uS me semblent utopiques, en C++ aussi, sur une machine standard. Il va peut être falloir paralléliser (threads ?), et c'est pas facile.
-- Ignace
Fabien LE LEZ
On Thu, 15 Jan 2004 09:51:48 +0100, "erwan" wrote:
C'est vrai que le c++ a l'air de mieux convenir pour ce type d'application
mais à mon avis beaucoup plus lourd à programmer.
Mouais... C'est pas parce qu'un langage a moins de fonctionnalités qu'il est plus facile à utiliser.
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.
Comme tout langage interprété, non ?
Enfin ça dépend ce que tu appelles langage interprété. perl par exemple est appelé langage interprété mais le code est bien compilé à chaque exécution.
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.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
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.
Comme tout langage interprété, non ?
Enfin ça dépend ce que tu appelles langage interprété. perl par exemple
est appelé langage interprété mais le code est bien compilé à chaque
exécution.
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.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
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.
Comme tout langage interprété, non ?
Enfin ça dépend ce que tu appelles langage interprété. perl par exemple est appelé langage interprété mais le code est bien compilé à chaque exécution.
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.
-- DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Fabien LE LEZ
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 ?
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. 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é.
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é.
Mais je suis sûr qu'un plus spécialiste que moi saura prouver que mon message est un tissu d'âneries ;-)
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 ?
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.
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é.
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é.
Mais je suis sûr qu'un plus spécialiste que moi saura prouver que mon
message est un tissu d'âneries ;-)
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 ?
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. 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é.
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é.
Mais je suis sûr qu'un plus spécialiste que moi saura prouver que mon message est un tissu d'âneries ;-)
