Vu d'un néophyte (pas débutant, mais pas très bon), quelles
différences y a-t-il entre Java et C++, mis à part quelques petites
particularités syntaxiques (syntaxe de création d'un tableau,
l'utilisation de destructeur d'objet, l'initialisation par défaut des
champs) ? Est-ce que l'héritage multiple change vraiment quelque chose
?
Où puis-je trouver un document clair (français ou anglais) qui me
permette de faire la transition (j'ai lu un article disant que C/C++
était plus rapide que Java et nécessitait moins de lignes) ?
Merci d'avance.
| Le résultat, c'est que le langage des templates C++ est Turing | complete. On peut en principe l'utilisable pour tout problème que peut | résoudre un ordinateur.
oui mais on peut faire le calcul aussi à la main ? :-)
-- Gaby
kanze@gabi-soft.fr writes:
| Le résultat, c'est que le langage des templates C++ est Turing
| complete. On peut en principe l'utilisable pour tout problème que peut
| résoudre un ordinateur.
oui mais on peut faire le calcul aussi à la main ? :-)
| Le résultat, c'est que le langage des templates C++ est Turing | complete. On peut en principe l'utilisable pour tout problème que peut | résoudre un ordinateur.
oui mais on peut faire le calcul aussi à la main ? :-)
-- Gaby
vclassine
Martinez Jerome wrote in message news:<bg5nbe$...
wrote:
La vitesse qui compte la plus, en général, c'est la vitesse de développement.
Je suis du coté client. Et ce qui m'interesse dans les contrats sont : - les perfs : donc la vitesse d'execution : je t'embauche pour dire a mes utilisateurs pour leur dire que si ils perdent la moité de leur données temps réel a cause des perfs d'un appli, c'est pas grave... Ce qui suppose que ton soft dépasse la capacité de la machine de
beaucoup. il est claire que si il faut 30 secondes pour faire une opération, 30% de perf en moins c'est préjudiciable. Mais quand il faut moins d'une seconde ça ne change rien...
J'ai du mal a imaginer qu'un code précompilé soit plus rapide qu'un code compilé, plus proche de la machine donc. A optimisation egale (a la limite sans utiliser vector<>), le C++ serait vraiment moins rapide que Java??? as-tu des exemples? (j'avoue, c'est le principe meme de code non completement compilé plus rapide que du code compilé qui me "choque". Mais bon, avec l'informatique plus rien doit choquer... :) ) Au delà des optimisation possible uniquement avec un compilateur JIT
il faut considèrer l'impact de la vélocité des API...
Martinez Jerome <jerome.martinez@aenlever-orangefrance.com> wrote in message news:<bg5nbe$87n1@news.rd.francetelecom.fr>...
kanze@gabi-soft.fr wrote:
La vitesse qui compte la plus, en général, c'est la vitesse de
développement.
Je suis du coté client.
Et ce qui m'interesse dans les contrats sont :
- les perfs : donc la vitesse d'execution : je t'embauche pour dire a
mes utilisateurs pour leur dire que si ils perdent la moité de leur
données temps réel a cause des perfs d'un appli, c'est pas grave...
Ce qui suppose que ton soft dépasse la capacité de la machine de
beaucoup. il est claire que si il faut 30 secondes pour faire une
opération, 30% de perf en moins c'est préjudiciable. Mais quand il
faut moins d'une seconde ça ne change rien...
J'ai du mal a imaginer qu'un code précompilé soit plus rapide qu'un code
compilé, plus proche de la machine donc.
A optimisation egale (a la limite sans utiliser vector<>), le C++ serait
vraiment moins rapide que Java???
as-tu des exemples?
(j'avoue, c'est le principe meme de code non completement compilé plus
rapide que du code compilé qui me "choque". Mais bon, avec
l'informatique plus rien doit choquer... :) )
Au delà des optimisation possible uniquement avec un compilateur JIT
il faut considèrer l'impact de la vélocité des API...
La vitesse qui compte la plus, en général, c'est la vitesse de développement.
Je suis du coté client. Et ce qui m'interesse dans les contrats sont : - les perfs : donc la vitesse d'execution : je t'embauche pour dire a mes utilisateurs pour leur dire que si ils perdent la moité de leur données temps réel a cause des perfs d'un appli, c'est pas grave... Ce qui suppose que ton soft dépasse la capacité de la machine de
beaucoup. il est claire que si il faut 30 secondes pour faire une opération, 30% de perf en moins c'est préjudiciable. Mais quand il faut moins d'une seconde ça ne change rien...
J'ai du mal a imaginer qu'un code précompilé soit plus rapide qu'un code compilé, plus proche de la machine donc. A optimisation egale (a la limite sans utiliser vector<>), le C++ serait vraiment moins rapide que Java??? as-tu des exemples? (j'avoue, c'est le principe meme de code non completement compilé plus rapide que du code compilé qui me "choque". Mais bon, avec l'informatique plus rien doit choquer... :) ) Au delà des optimisation possible uniquement avec un compilateur JIT
il faut considèrer l'impact de la vélocité des API...
vclassine
Loïc Joly wrote in message news:<bg5u7d$jgm$...
Par vraiment, non... Déjà, on peut faire des templates avec autre-chose qu'un type... Ensuite, plutôt que modern C++ design, qui est assez ardu, je te conseille de lire C++ template, the complete guide, et en particulier les chapitres meta-programming et expression template.
Pour moi un template c'est un peu comme une expréssion régulière, non? ça n'apporte pas de fonctionnalité que tu ne puisse pas écrire directement (même si c'est lourd), non?
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message news:<bg5u7d$jgm$1@news-reader3.wanadoo.fr>...
Par vraiment, non...
Déjà, on peut faire des templates avec autre-chose qu'un type...
Ensuite, plutôt que modern C++ design, qui est assez ardu, je te
conseille de lire C++ template, the complete guide, et en particulier
les chapitres meta-programming et expression template.
Pour moi un template c'est un peu comme une expréssion régulière, non?
ça n'apporte pas de fonctionnalité que tu ne puisse pas écrire
directement (même si c'est lourd), non?
Par vraiment, non... Déjà, on peut faire des templates avec autre-chose qu'un type... Ensuite, plutôt que modern C++ design, qui est assez ardu, je te conseille de lire C++ template, the complete guide, et en particulier les chapitres meta-programming et expression template.
Pour moi un template c'est un peu comme une expréssion régulière, non? ça n'apporte pas de fonctionnalité que tu ne puisse pas écrire directement (même si c'est lourd), non?
Arnaud Debaene
Vincent wrote:
Oui, mais avec toutes ces solutions alternatives, rien n'empêche l'utilisateur de ta bibliothèque d'implémenter directement les 2 interfaces sans passer par ta/tes classe(s) qui "enforcent" le contrat (c'est même la façon naturelle de faire en Java).
Si la réponse à ta remarque n'est pas le mot clé "final" qui rend les méthode "non-virtuelles", tu peux me donner un exemple concret en C++...
Soient 2 interfaces (au sens programmation par contrat du terme) I1 et I2, définies dans la bibliothèque que tu es en train d'écrire. Comment faire pour que l'utilisateur de ta bibliothèque (tu ne le connais pas, c'est une bibliothèque commerciale) puisse hériter de tes 2 interfaces (càd les implémenter) tout en garantissant que les pré-conditions et post-conditions seront obligatoirement appliquées (l'utilisateur ne peut pas "court-circuiter" test tests)?
Réponse en C++ : class I1 { public: float f1(int param) { //préconditions float resultat=do_f1(param); //postconditions return resultat; } protected: virtual float do_f1(int param) =0; };
class I2 { public: int f2(char param) { //préconditions int resultat=do_f2(param); //postconditions return resultat; } protected: virtual int do_f2(char param) =0; };
Pour implémneter les 2 interfaces, l'utiliateur de ta bibliothèque n'a qu'à faire : class MaClasseUtilisateur : public I1, public I2 { protected: virtual float do_f1(int param) { // implémentation }; virtual int do_f2(char param) { // implémentation }; };
Comment fais-tu la même chose en Java?
Arnaud
Vincent wrote:
Oui, mais avec toutes ces solutions alternatives, rien n'empêche
l'utilisateur de ta bibliothèque d'implémenter directement les 2
interfaces sans passer par ta/tes classe(s) qui "enforcent" le
contrat (c'est même la façon naturelle de faire en Java).
Si la réponse à ta remarque n'est pas le mot clé "final" qui rend les
méthode "non-virtuelles", tu peux me donner un exemple concret en
C++...
Soient 2 interfaces (au sens programmation par contrat du terme) I1 et I2,
définies dans la bibliothèque que tu es en train d'écrire. Comment faire
pour que l'utilisateur de ta bibliothèque (tu ne le connais pas, c'est une
bibliothèque commerciale) puisse hériter de tes 2 interfaces (càd les
implémenter) tout en garantissant que les pré-conditions et post-conditions
seront obligatoirement appliquées (l'utilisateur ne peut pas
"court-circuiter" test tests)?
Réponse en C++ :
class I1
{
public:
float f1(int param)
{
//préconditions
float resultat=do_f1(param);
//postconditions
return resultat;
}
protected:
virtual float do_f1(int param) =0;
};
class I2
{
public:
int f2(char param)
{
//préconditions
int resultat=do_f2(param);
//postconditions
return resultat;
}
protected:
virtual int do_f2(char param) =0;
};
Pour implémneter les 2 interfaces, l'utiliateur de ta bibliothèque n'a qu'à
faire :
class MaClasseUtilisateur : public I1, public I2
{
protected:
virtual float do_f1(int param) { // implémentation };
virtual int do_f2(char param) { // implémentation };
};
Oui, mais avec toutes ces solutions alternatives, rien n'empêche l'utilisateur de ta bibliothèque d'implémenter directement les 2 interfaces sans passer par ta/tes classe(s) qui "enforcent" le contrat (c'est même la façon naturelle de faire en Java).
Si la réponse à ta remarque n'est pas le mot clé "final" qui rend les méthode "non-virtuelles", tu peux me donner un exemple concret en C++...
Soient 2 interfaces (au sens programmation par contrat du terme) I1 et I2, définies dans la bibliothèque que tu es en train d'écrire. Comment faire pour que l'utilisateur de ta bibliothèque (tu ne le connais pas, c'est une bibliothèque commerciale) puisse hériter de tes 2 interfaces (càd les implémenter) tout en garantissant que les pré-conditions et post-conditions seront obligatoirement appliquées (l'utilisateur ne peut pas "court-circuiter" test tests)?
Réponse en C++ : class I1 { public: float f1(int param) { //préconditions float resultat=do_f1(param); //postconditions return resultat; } protected: virtual float do_f1(int param) =0; };
class I2 { public: int f2(char param) { //préconditions int resultat=do_f2(param); //postconditions return resultat; } protected: virtual int do_f2(char param) =0; };
Pour implémneter les 2 interfaces, l'utiliateur de ta bibliothèque n'a qu'à faire : class MaClasseUtilisateur : public I1, public I2 { protected: virtual float do_f1(int param) { // implémentation }; virtual int do_f2(char param) { // implémentation }; };
Comment fais-tu la même chose en Java?
Arnaud
Gabriel Dos Reis
(Vincent) writes:
[...]
| > C'est la dernière mode en programmation. Ça s'appelle la programmation | > copier/coller. | | Je ne l'ai pas dis dans cet esprit c'est certe très utile (même si il | ne fauit pas exagèrer on n'écrit pas tant de templates que ça...), | mais ça reste une "commodité syntaxique"... J'entends par là que ça | n'apporte pas de nouvelle possibilités.
Pas de nouvelles possibilités en quel sens ?
Clairement, les templates ont changé la manière de programmation, vue de C++.
-- Gaby
vclassine@elan.fr (Vincent) writes:
[...]
| > C'est la dernière mode en programmation. Ça s'appelle la programmation
| > copier/coller.
|
| Je ne l'ai pas dis dans cet esprit c'est certe très utile (même si il
| ne fauit pas exagèrer on n'écrit pas tant de templates que ça...),
| mais ça reste une "commodité syntaxique"... J'entends par là que ça
| n'apporte pas de nouvelle possibilités.
Pas de nouvelles possibilités en quel sens ?
Clairement, les templates ont changé la manière de programmation, vue
de C++.
| > C'est la dernière mode en programmation. Ça s'appelle la programmation | > copier/coller. | | Je ne l'ai pas dis dans cet esprit c'est certe très utile (même si il | ne fauit pas exagèrer on n'écrit pas tant de templates que ça...), | mais ça reste une "commodité syntaxique"... J'entends par là que ça | n'apporte pas de nouvelle possibilités.
Pas de nouvelles possibilités en quel sens ?
Clairement, les templates ont changé la manière de programmation, vue de C++.
-- Gaby
Christophe Lephay
"Vincent" a écrit dans le message de news:
Arf! Si tu considères que les templates sont une "commodité syntaxique", Expression un peu mal choisie je te l'accorde, ça ne rend pas bien
compte de l'utilité de la chose... Mais je continue de penser que ça n'est pas indispensable.
C'est juste un paradigme supplémentaire (programmation générique, inspiré de la programmation fonctionnelle). Dans le même ordre d'idée, on pourrait dire que le paradigme OO n'est pas indispensable quoique utile.
Chris
"Vincent" <vclassine@elan.fr> a écrit dans le message de
news:9e49e584.0307282316.71796030@posting.google.com...
Arf! Si tu considères que les templates sont une "commodité syntaxique",
Expression un peu mal choisie je te l'accorde, ça ne rend pas bien
compte de l'utilité de la chose... Mais je continue de penser que ça
n'est pas indispensable.
C'est juste un paradigme supplémentaire (programmation générique, inspiré de
la programmation fonctionnelle). Dans le même ordre d'idée, on pourrait dire
que le paradigme OO n'est pas indispensable quoique utile.
Arf! Si tu considères que les templates sont une "commodité syntaxique", Expression un peu mal choisie je te l'accorde, ça ne rend pas bien
compte de l'utilité de la chose... Mais je continue de penser que ça n'est pas indispensable.
C'est juste un paradigme supplémentaire (programmation générique, inspiré de la programmation fonctionnelle). Dans le même ordre d'idée, on pourrait dire que le paradigme OO n'est pas indispensable quoique utile.
Chris
Christophe Lephay
"Gabriel Dos Reis" a écrit dans le message de news:
"Christophe Lephay" writes: | Mais la SL me parait bien moins dépendant de l'environnement qu'une | interface graphique...
C'est ce qu'on a essayé de faire croire. D'après toi quelle est la définition de fichier ?
Je ne sais pas quelle est la définition de fichier. En revenche, je sais qu'un système de fichier est plus simple qu'une interface graphique...
Chris
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
news:m37k61vahu.fsf@uniton.integrable-solutions.net...
"Christophe Lephay" <christophe-lephay@wanadoo.fr> writes:
| Mais la SL me parait bien moins dépendant de l'environnement qu'une
| interface graphique...
C'est ce qu'on a essayé de faire croire. D'après toi quelle est la
définition de fichier ?
Je ne sais pas quelle est la définition de fichier. En revenche, je sais
qu'un système de fichier est plus simple qu'une interface graphique...
"Gabriel Dos Reis" a écrit dans le message de news:
"Christophe Lephay" writes: | Mais la SL me parait bien moins dépendant de l'environnement qu'une | interface graphique...
C'est ce qu'on a essayé de faire croire. D'après toi quelle est la définition de fichier ?
Je ne sais pas quelle est la définition de fichier. En revenche, je sais qu'un système de fichier est plus simple qu'une interface graphique...
Chris
Alain Naigeon
"Vincent" a écrit dans le message news:
Martinez Jerome wrote in message news:<bg5nbe$...
wrote:
La vitesse qui compte la plus, en général, c'est la vitesse de développement.
Je suis du coté client. Et ce qui m'interesse dans les contrats sont : - les perfs : donc la vitesse d'execution : je t'embauche pour dire a mes utilisateurs pour leur dire que si ils perdent la moité de leur données temps réel a cause des perfs d'un appli, c'est pas grave... Ce qui suppose que ton soft dépasse la capacité de la machine de
beaucoup. il est claire que si il faut 30 secondes pour faire une opération, 30% de perf en moins c'est préjudiciable. Mais quand il faut moins d'une seconde ça ne change rien...
Eh oui ! Sans compter que l'optimisation de la façon de faire (choix d'un algorithme) peut améliorer beaucoup plus que le codage proprement dit.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Vincent" <vclassine@elan.fr> a écrit dans le message news:
9e49e584.0307290855.70be69c0@posting.google.com...
Martinez Jerome <jerome.martinez@aenlever-orangefrance.com> wrote in
message news:<bg5nbe$87n1@news.rd.francetelecom.fr>...
kanze@gabi-soft.fr wrote:
La vitesse qui compte la plus, en général, c'est la vitesse de
développement.
Je suis du coté client.
Et ce qui m'interesse dans les contrats sont :
- les perfs : donc la vitesse d'execution : je t'embauche pour dire a
mes utilisateurs pour leur dire que si ils perdent la moité de leur
données temps réel a cause des perfs d'un appli, c'est pas grave...
Ce qui suppose que ton soft dépasse la capacité de la machine de
beaucoup. il est claire que si il faut 30 secondes pour faire une
opération, 30% de perf en moins c'est préjudiciable. Mais quand il
faut moins d'une seconde ça ne change rien...
Eh oui ! Sans compter que l'optimisation de la façon de faire
(choix d'un algorithme) peut améliorer beaucoup plus que
le codage proprement dit.
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
La vitesse qui compte la plus, en général, c'est la vitesse de développement.
Je suis du coté client. Et ce qui m'interesse dans les contrats sont : - les perfs : donc la vitesse d'execution : je t'embauche pour dire a mes utilisateurs pour leur dire que si ils perdent la moité de leur données temps réel a cause des perfs d'un appli, c'est pas grave... Ce qui suppose que ton soft dépasse la capacité de la machine de
beaucoup. il est claire que si il faut 30 secondes pour faire une opération, 30% de perf en moins c'est préjudiciable. Mais quand il faut moins d'une seconde ça ne change rien...
Eh oui ! Sans compter que l'optimisation de la façon de faire (choix d'un algorithme) peut améliorer beaucoup plus que le codage proprement dit.
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Gabriel Dos Reis
"Christophe Lephay" writes:
| "Gabriel Dos Reis" a écrit dans le message de | news: | > "Christophe Lephay" writes: | > | Mais la SL me parait bien moins dépendant de l'environnement qu'une | > | interface graphique... | > | > C'est ce qu'on a essayé de faire croire. D'après toi quelle est la | > définition de fichier ? | | Je ne sais pas quelle est la définition de fichier.
Ah, je vois :-)
| En revenche, je sais | qu'un système de fichier est plus simple qu'une interface graphique...
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
| news:m37k61vahu.fsf@uniton.integrable-solutions.net...
| > "Christophe Lephay" <christophe-lephay@wanadoo.fr> writes:
| > | Mais la SL me parait bien moins dépendant de l'environnement qu'une
| > | interface graphique...
| >
| > C'est ce qu'on a essayé de faire croire. D'après toi quelle est la
| > définition de fichier ?
|
| Je ne sais pas quelle est la définition de fichier.
Ah, je vois :-)
| En revenche, je sais
| qu'un système de fichier est plus simple qu'une interface graphique...
| "Gabriel Dos Reis" a écrit dans le message de | news: | > "Christophe Lephay" writes: | > | Mais la SL me parait bien moins dépendant de l'environnement qu'une | > | interface graphique... | > | > C'est ce qu'on a essayé de faire croire. D'après toi quelle est la | > définition de fichier ? | | Je ne sais pas quelle est la définition de fichier.
Ah, je vois :-)
| En revenche, je sais | qu'un système de fichier est plus simple qu'une interface graphique...
-- Gaby
Alain Naigeon
[je ne retrouve plus l'auteur]
Pendant qu'on y est, on pourrait éliminer les fonctions aussi, parce qu'elles non plus elles ne sont qu'une commodité syntaxique ; on n'a qu'écrire le vrai code à leur place.
C'est la dernière mode en programmation. Ça s'appelle la programmation copier/coller.
Erreur ! C'est presque démodé, et ça s'appelait "inline" :-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
[je ne retrouve plus l'auteur]
Pendant qu'on y est, on pourrait éliminer les fonctions aussi, parce
qu'elles non plus elles ne sont qu'une commodité syntaxique ; on n'a
qu'écrire le vrai code à leur place.
C'est la dernière mode en programmation. Ça s'appelle la programmation
copier/coller.
Erreur ! C'est presque démodé, et ça s'appelait "inline" :-)
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
Pendant qu'on y est, on pourrait éliminer les fonctions aussi, parce qu'elles non plus elles ne sont qu'une commodité syntaxique ; on n'a qu'écrire le vrai code à leur place.
C'est la dernière mode en programmation. Ça s'appelle la programmation copier/coller.
Erreur ! C'est presque démodé, et ça s'appelait "inline" :-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
