- Bien moins important (sauf quand tu en as besoin) : C++ a du
surcharge des opérateurs, qui permet à émuler un type de base.
C'est un épée à double tranchant -- c'est incroyablement facile
à en abuser (et comme en Java, la bibliothèque standard n'est
pas toujours un bon modèle). Mais supposons que pour des raisons
juridiques, tu sois obligé à tenir des valeurs monétaires en
décimal (c'est généralement le cas), est-ce mieux d'avoir à
écrire :
total = prixHorsTax + prixHorsTax * tva ;
comme en C++, ou :
total = prixHorsTax.add( prixHorsTax.mult( tva ) ) ;
comme en Java.
Vite dit:
total = prixHorsTaxe.applyTaxe(tva);
Est tout à fait acceptable et applyTaxe n'est guère plus long à écrire
que la surcharge de l'opérateur. Même si l'opérateur peut être employé
ailleurs...
Alors, il faut que tu introduit une classe supplémentaire
Pour surcharger l'opérateur plus il te faut bien aussi une classe Prix
-- une valeur
décimale qui connaît la TVA française.
Dans l'exemple C++ comme Java la TVA est dans l'appel, mais ça n'est
Mais ce n'était qu'un exemple simple. Que faire dans les programmes du
marché, par exemple, où les formules qu'on manipule sont vraiment
compliqués, et qu'ils changent assez souvent.
Je ne vois pas l'avantage d'un opérateur par rapport à une fonction
Que faire dans les
programmes scientifiques et techniques, ou on doit manipuler des
Complex -- le calcul d'impédence ne doit pas être évident.
Le problème est simple : quand tu as besoin du surcharge, tu en as
besoin, et il n'y a rien qui ne le remplace. Si tu travailles dans un
domaine technique, il y a de fortes chances que tu en auras besoin, au
moins pour Complex. Si tu fais de la comptabilité juridiquement valable,
tu en auras besoin, parce que la législation exige des arrondis sur la
base d'un calcul décimal.
En revanche, il y a effectivement beaucoup de domaines où tu n'en auras
pas besoin.Comme tu le dis c'est à double tranchant, et ça n'est qu'une
fonctionnalité syntaxique qui en tout état de cause n'est pas souvent
vraiment utile.
Je n'ai pas dit que c'est souvent nécessaire. J'ai dit que quand c'est
nécessaire, les alternatifs sont vraiment moches.
En fait, dans ce cas-ci, Gosling est d'accord avec moi. Il veut ajouter
la surcharge d'opérateurs:-).
Ah mais je suis entièrement d'accord pour dire qu'il faut l'ajouter
- Java, au moins dans ces premières versions, n'avait pas de
génériques. Ce qui limiter des prédicats sur le type que pouvait
enforcer le compilateur : en C++, si tu déclare un std::vector,
tu dis au compilateur le type que tu veux y mettre, et le
compilateur l'enforce. En Java, tu écris un commentaire qui dit
le type qu'il doit contenir, et en cas d'erreur, tu as une
exception à l'execution.
Là encore c'est une commodité syntaxique (qui sera incluse dans la
1.5) rien n'empêche d'écrire une version de chaque conteneur par type,
c'est lourd mais ça se fait.
En fait, rien n'empêche l'utilisation d'un préprocesseur. G++ le faisait
avant qu'il y avait des templates en C++, et ça marchait. Et la
simplicité du grammaire de Java doit en facilité l'écriture du
préprocesseur.
Ça, c'est en théorie. Pour une raison ou une autre, ce n'est pas ce qui
se fait en pratique (sauf quand moi, je fais du Java:-)).
Certainement parce que le domaine ou s'utilise java ne nécessite pas
- Java pose des problèmes pour la programmation par contrat. En
C++, c'est plutôt l'exception d'avoir une fonction virtuelle
publique -- la plupart en sont privée. En Java, on ne peut pas
déclarer une fonction privée virtuelle.
Euh? Privée virtuelle = protected (sauf que protected est accessible
aussi depuis le package, mais en principe on n'authorise personne de
non fiable à écrire dans son package).
Comment est-ce qu'on l'empêche, vue que le package est ouvert ?
Oui enfin, en C++ on peut aussi dessassemblé le binaire pour brancher
(En fait, je crois que l'accessibilité « package », c'est la réponse de
Java au « friend » de C++. Ni l'un ni l'autre n'est totalement
satisfaisant.
Effectivement.
Mais pour que « package » soit une bonne réponse, il
faudra pouvoir fermer un package, et il faudrait supprimer l'accès
package aux classes dérivées en dehors du package. La possibilité de «
sceller » un fichier JAR s'adresse au premier problème, mais c'est un
hack, et pas du tout au bon endroit.)
Oui je trouve qu'il aurait pu faire mieux qu'un répertoire pour les
Du coup, c'est extrèmement difficile à forcer que tous les
appels de la fonction passent par une fonction non-virtuelle
(final, en Java) dans la classe de base ; fonction qui vérifie
que le contrat est maintenu.
public abstract class AbstractTest
{
public final void faire_truc()
{
pre_condition();
faire_vraiment_truc();
post_condition();
}
private void pre_condition();
private void post_condition();
protected abstract void faire_vraiment_truc();
}
C'est ce que j'ai fait dans la pratique, mais la perte de l'héritage
multiple était genant dans certains cas.- C++ permet la separation de l'implémentation et de l'interface.
En C++, c'est permis de définir des fonctions dans la définition
de la classe, comme on fait en Java, mais on constate très vite
que c'est une mauvaise idée. En Java, on n'a pas le choix. (Le
moyen qu'utilise C++ pour faire cette separation, l'inclusion
textuelle, est probablement le pire qu
En fait on peut très bien le faire en définissant une interface
pour chaque classe (ce qui n'est pas une mauvaise idée du reste),
c'est optionnel.
C'est optionnel en C++ aussi -- on *peut* écrire le C++ exactement comme
on écrit le Java. L'expérience a montré que c'est une très mauvaise
idée, et c'est interdit dans la plupart des régles de codage.
Quand a l'utilisation de l'interface, ça ne s'adresse que partiellement
au problème -- tu peux bien en déclarer des variables, mais tu ne peux
pas en créer des instances. Alors, du coup, il te faut une usine, et
beaucoup d'autres choses. C'est une solution assez lourde dans
l'ensemble.
Ce qu'il faudrait, idéalement, c'est des modules, comme en Ada. Mais une
fois de plus, la souplesse de C++ te permet à les simuler, plus ou
moins, et d'une façon vraiment pas très élégant, tandis qu'avec Java, tu
es coincé.- Java, au moins dans les implémentations que je connais, impose
un certain dynamisme, qui n'est pas toujours souhaitable. En
C++, si tu veux, tu peux découper ton programme en objets
dynamiques (DLL's sous Windows, objets partagés sous Unix, mais
dans les deux cas, ce qui fait la différence, c'est que
l'édition de liens se fait lors de l'execution.) Or,
globalement, un objet dynamique n'est qu'une chose de plus que
tu ne contrôles pas complètement lors de l'execution. On les
évite autant que possible, à cause des erreurs qui en
proviennent.
En faveur de Java, évidemment, ce sont des bibliothèques standard
pour à peu près tout, et dans certains cas, comme les JSP,
l'environement applicatif.
Une autre chose en faveur, que j'avais oublié, c'est la qualité de la
documentation en ligne. Il n'y a rien en C++ qui ne s'approche de ce que
tu as à partir de http://developer.java.sun.com/developer/infodocs/.
(C'est un très fort argument pour l'utilisation de Java dans
l'enseignement, par exemple.)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) ?
Ça dépend de ce que tu fais. Il y a aussi des benchmark qui tournent
plus vite en Java qu'en C++. Dans la plupart des applications, en
revanche, j'imagine que le fait que C++ ait des véritables valeurs,
qu'on peut allouer sur la pile, ou mettre directement dans une
collection, fait que le C++ serait plus rapide.
Effectivement, mais ce gain de performance dépend de la qualité du
programmeur et n'est pas toujours nécessaire...
C'est même très rarement nécessaire, je dirais. Bien que... Quand j'ai
écrit l'application Java pour la Dresdner Bank, pour qu'elle tourne
correctement, il a fallu remplacer les PC sur lesquels elle tournait
avec des PC plus puissant. Or, même aux prix d'aujourd'hui, remplacer
60000 PC, ce n'est pas donné. (Mais je crois que le problème était
Swing, et non Java en soi.)
ça ne m'étonnerait pas, maintenant Swing à fait des progrès et il y a
Plus important, pour des applications d'une certaine taille, je
trouve qu'on les développe plus rapidement en C++.
Je n'en suis pas convaincu, mais c'est normal ce genre de chose est
éminemment subjectif.
Ça se mésure. Je connais une ou deux boîtes qui l'ont mésuré. Le fait
est que pour un grand système :
- on dévelope plus rapidement en C++, et
- le résultat est nettement plus fiable en C++.
Pour des systèmes plus petits, c'est moins évident.
À la fin, tout dépend de l'application. Si je développais un site de
Web, je choisirais sûrement Java, à cause de tout l'environement autour.
Pour un logiciel client, j'aurais une tendance à préférer Java aussi, à
cause de Swing, et du modèle de deployement. Pour l'enseignement,
peut-être, à cause de la documentation et parce qu'il y a moins de
pièges bêtes (mais il y a tellement d'autres langages qui sont sans
doute supérieur aux deux). Pour d'autres choses, j'ai mes doutes.
- Bien moins important (sauf quand tu en as besoin) : C++ a du
surcharge des opérateurs, qui permet à émuler un type de base.
C'est un épée à double tranchant -- c'est incroyablement facile
à en abuser (et comme en Java, la bibliothèque standard n'est
pas toujours un bon modèle). Mais supposons que pour des raisons
juridiques, tu sois obligé à tenir des valeurs monétaires en
décimal (c'est généralement le cas), est-ce mieux d'avoir à
écrire :
total = prixHorsTax + prixHorsTax * tva ;
comme en C++, ou :
total = prixHorsTax.add( prixHorsTax.mult( tva ) ) ;
comme en Java.
Vite dit:
total = prixHorsTaxe.applyTaxe(tva);
Est tout à fait acceptable et applyTaxe n'est guère plus long à écrire
que la surcharge de l'opérateur. Même si l'opérateur peut être employé
ailleurs...
Alors, il faut que tu introduit une classe supplémentaire
Pour surcharger l'opérateur plus il te faut bien aussi une classe Prix
-- une valeur
décimale qui connaît la TVA française.
Dans l'exemple C++ comme Java la TVA est dans l'appel, mais ça n'est
Mais ce n'était qu'un exemple simple. Que faire dans les programmes du
marché, par exemple, où les formules qu'on manipule sont vraiment
compliqués, et qu'ils changent assez souvent.
Je ne vois pas l'avantage d'un opérateur par rapport à une fonction
Que faire dans les
programmes scientifiques et techniques, ou on doit manipuler des
Complex -- le calcul d'impédence ne doit pas être évident.
Le problème est simple : quand tu as besoin du surcharge, tu en as
besoin, et il n'y a rien qui ne le remplace. Si tu travailles dans un
domaine technique, il y a de fortes chances que tu en auras besoin, au
moins pour Complex. Si tu fais de la comptabilité juridiquement valable,
tu en auras besoin, parce que la législation exige des arrondis sur la
base d'un calcul décimal.
En revanche, il y a effectivement beaucoup de domaines où tu n'en auras
pas besoin.
Comme tu le dis c'est à double tranchant, et ça n'est qu'une
fonctionnalité syntaxique qui en tout état de cause n'est pas souvent
vraiment utile.
Je n'ai pas dit que c'est souvent nécessaire. J'ai dit que quand c'est
nécessaire, les alternatifs sont vraiment moches.
En fait, dans ce cas-ci, Gosling est d'accord avec moi. Il veut ajouter
la surcharge d'opérateurs:-).
Ah mais je suis entièrement d'accord pour dire qu'il faut l'ajouter
- Java, au moins dans ces premières versions, n'avait pas de
génériques. Ce qui limiter des prédicats sur le type que pouvait
enforcer le compilateur : en C++, si tu déclare un std::vector,
tu dis au compilateur le type que tu veux y mettre, et le
compilateur l'enforce. En Java, tu écris un commentaire qui dit
le type qu'il doit contenir, et en cas d'erreur, tu as une
exception à l'execution.
Là encore c'est une commodité syntaxique (qui sera incluse dans la
1.5) rien n'empêche d'écrire une version de chaque conteneur par type,
c'est lourd mais ça se fait.
En fait, rien n'empêche l'utilisation d'un préprocesseur. G++ le faisait
avant qu'il y avait des templates en C++, et ça marchait. Et la
simplicité du grammaire de Java doit en facilité l'écriture du
préprocesseur.
Ça, c'est en théorie. Pour une raison ou une autre, ce n'est pas ce qui
se fait en pratique (sauf quand moi, je fais du Java:-)).
Certainement parce que le domaine ou s'utilise java ne nécessite pas
- Java pose des problèmes pour la programmation par contrat. En
C++, c'est plutôt l'exception d'avoir une fonction virtuelle
publique -- la plupart en sont privée. En Java, on ne peut pas
déclarer une fonction privée virtuelle.
Euh? Privée virtuelle = protected (sauf que protected est accessible
aussi depuis le package, mais en principe on n'authorise personne de
non fiable à écrire dans son package).
Comment est-ce qu'on l'empêche, vue que le package est ouvert ?
Oui enfin, en C++ on peut aussi dessassemblé le binaire pour brancher
(En fait, je crois que l'accessibilité « package », c'est la réponse de
Java au « friend » de C++. Ni l'un ni l'autre n'est totalement
satisfaisant.
Effectivement.
Mais pour que « package » soit une bonne réponse, il
faudra pouvoir fermer un package, et il faudrait supprimer l'accès
package aux classes dérivées en dehors du package. La possibilité de «
sceller » un fichier JAR s'adresse au premier problème, mais c'est un
hack, et pas du tout au bon endroit.)
Oui je trouve qu'il aurait pu faire mieux qu'un répertoire pour les
Du coup, c'est extrèmement difficile à forcer que tous les
appels de la fonction passent par une fonction non-virtuelle
(final, en Java) dans la classe de base ; fonction qui vérifie
que le contrat est maintenu.
public abstract class AbstractTest
{
public final void faire_truc()
{
pre_condition();
faire_vraiment_truc();
post_condition();
}
private void pre_condition();
private void post_condition();
protected abstract void faire_vraiment_truc();
}
C'est ce que j'ai fait dans la pratique, mais la perte de l'héritage
multiple était genant dans certains cas.
- C++ permet la separation de l'implémentation et de l'interface.
En C++, c'est permis de définir des fonctions dans la définition
de la classe, comme on fait en Java, mais on constate très vite
que c'est une mauvaise idée. En Java, on n'a pas le choix. (Le
moyen qu'utilise C++ pour faire cette separation, l'inclusion
textuelle, est probablement le pire qu
En fait on peut très bien le faire en définissant une interface
pour chaque classe (ce qui n'est pas une mauvaise idée du reste),
c'est optionnel.
C'est optionnel en C++ aussi -- on *peut* écrire le C++ exactement comme
on écrit le Java. L'expérience a montré que c'est une très mauvaise
idée, et c'est interdit dans la plupart des régles de codage.
Quand a l'utilisation de l'interface, ça ne s'adresse que partiellement
au problème -- tu peux bien en déclarer des variables, mais tu ne peux
pas en créer des instances. Alors, du coup, il te faut une usine, et
beaucoup d'autres choses. C'est une solution assez lourde dans
l'ensemble.
Ce qu'il faudrait, idéalement, c'est des modules, comme en Ada. Mais une
fois de plus, la souplesse de C++ te permet à les simuler, plus ou
moins, et d'une façon vraiment pas très élégant, tandis qu'avec Java, tu
es coincé.
- Java, au moins dans les implémentations que je connais, impose
un certain dynamisme, qui n'est pas toujours souhaitable. En
C++, si tu veux, tu peux découper ton programme en objets
dynamiques (DLL's sous Windows, objets partagés sous Unix, mais
dans les deux cas, ce qui fait la différence, c'est que
l'édition de liens se fait lors de l'execution.) Or,
globalement, un objet dynamique n'est qu'une chose de plus que
tu ne contrôles pas complètement lors de l'execution. On les
évite autant que possible, à cause des erreurs qui en
proviennent.
En faveur de Java, évidemment, ce sont des bibliothèques standard
pour à peu près tout, et dans certains cas, comme les JSP,
l'environement applicatif.
Une autre chose en faveur, que j'avais oublié, c'est la qualité de la
documentation en ligne. Il n'y a rien en C++ qui ne s'approche de ce que
tu as à partir de http://developer.java.sun.com/developer/infodocs/.
(C'est un très fort argument pour l'utilisation de Java dans
l'enseignement, par exemple.)
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) ?
Ça dépend de ce que tu fais. Il y a aussi des benchmark qui tournent
plus vite en Java qu'en C++. Dans la plupart des applications, en
revanche, j'imagine que le fait que C++ ait des véritables valeurs,
qu'on peut allouer sur la pile, ou mettre directement dans une
collection, fait que le C++ serait plus rapide.
Effectivement, mais ce gain de performance dépend de la qualité du
programmeur et n'est pas toujours nécessaire...
C'est même très rarement nécessaire, je dirais. Bien que... Quand j'ai
écrit l'application Java pour la Dresdner Bank, pour qu'elle tourne
correctement, il a fallu remplacer les PC sur lesquels elle tournait
avec des PC plus puissant. Or, même aux prix d'aujourd'hui, remplacer
60000 PC, ce n'est pas donné. (Mais je crois que le problème était
Swing, et non Java en soi.)
ça ne m'étonnerait pas, maintenant Swing à fait des progrès et il y a
Plus important, pour des applications d'une certaine taille, je
trouve qu'on les développe plus rapidement en C++.
Je n'en suis pas convaincu, mais c'est normal ce genre de chose est
éminemment subjectif.
Ça se mésure. Je connais une ou deux boîtes qui l'ont mésuré. Le fait
est que pour un grand système :
- on dévelope plus rapidement en C++, et
- le résultat est nettement plus fiable en C++.
Pour des systèmes plus petits, c'est moins évident.
À la fin, tout dépend de l'application. Si je développais un site de
Web, je choisirais sûrement Java, à cause de tout l'environement autour.
Pour un logiciel client, j'aurais une tendance à préférer Java aussi, à
cause de Swing, et du modèle de deployement. Pour l'enseignement,
peut-être, à cause de la documentation et parce qu'il y a moins de
pièges bêtes (mais il y a tellement d'autres langages qui sont sans
doute supérieur aux deux). Pour d'autres choses, j'ai mes doutes.
- Bien moins important (sauf quand tu en as besoin) : C++ a du
surcharge des opérateurs, qui permet à émuler un type de base.
C'est un épée à double tranchant -- c'est incroyablement facile
à en abuser (et comme en Java, la bibliothèque standard n'est
pas toujours un bon modèle). Mais supposons que pour des raisons
juridiques, tu sois obligé à tenir des valeurs monétaires en
décimal (c'est généralement le cas), est-ce mieux d'avoir à
écrire :
total = prixHorsTax + prixHorsTax * tva ;
comme en C++, ou :
total = prixHorsTax.add( prixHorsTax.mult( tva ) ) ;
comme en Java.
Vite dit:
total = prixHorsTaxe.applyTaxe(tva);
Est tout à fait acceptable et applyTaxe n'est guère plus long à écrire
que la surcharge de l'opérateur. Même si l'opérateur peut être employé
ailleurs...
Alors, il faut que tu introduit une classe supplémentaire
Pour surcharger l'opérateur plus il te faut bien aussi une classe Prix
-- une valeur
décimale qui connaît la TVA française.
Dans l'exemple C++ comme Java la TVA est dans l'appel, mais ça n'est
Mais ce n'était qu'un exemple simple. Que faire dans les programmes du
marché, par exemple, où les formules qu'on manipule sont vraiment
compliqués, et qu'ils changent assez souvent.
Je ne vois pas l'avantage d'un opérateur par rapport à une fonction
Que faire dans les
programmes scientifiques et techniques, ou on doit manipuler des
Complex -- le calcul d'impédence ne doit pas être évident.
Le problème est simple : quand tu as besoin du surcharge, tu en as
besoin, et il n'y a rien qui ne le remplace. Si tu travailles dans un
domaine technique, il y a de fortes chances que tu en auras besoin, au
moins pour Complex. Si tu fais de la comptabilité juridiquement valable,
tu en auras besoin, parce que la législation exige des arrondis sur la
base d'un calcul décimal.
En revanche, il y a effectivement beaucoup de domaines où tu n'en auras
pas besoin.Comme tu le dis c'est à double tranchant, et ça n'est qu'une
fonctionnalité syntaxique qui en tout état de cause n'est pas souvent
vraiment utile.
Je n'ai pas dit que c'est souvent nécessaire. J'ai dit que quand c'est
nécessaire, les alternatifs sont vraiment moches.
En fait, dans ce cas-ci, Gosling est d'accord avec moi. Il veut ajouter
la surcharge d'opérateurs:-).
Ah mais je suis entièrement d'accord pour dire qu'il faut l'ajouter
- Java, au moins dans ces premières versions, n'avait pas de
génériques. Ce qui limiter des prédicats sur le type que pouvait
enforcer le compilateur : en C++, si tu déclare un std::vector,
tu dis au compilateur le type que tu veux y mettre, et le
compilateur l'enforce. En Java, tu écris un commentaire qui dit
le type qu'il doit contenir, et en cas d'erreur, tu as une
exception à l'execution.
Là encore c'est une commodité syntaxique (qui sera incluse dans la
1.5) rien n'empêche d'écrire une version de chaque conteneur par type,
c'est lourd mais ça se fait.
En fait, rien n'empêche l'utilisation d'un préprocesseur. G++ le faisait
avant qu'il y avait des templates en C++, et ça marchait. Et la
simplicité du grammaire de Java doit en facilité l'écriture du
préprocesseur.
Ça, c'est en théorie. Pour une raison ou une autre, ce n'est pas ce qui
se fait en pratique (sauf quand moi, je fais du Java:-)).
Certainement parce que le domaine ou s'utilise java ne nécessite pas
- Java pose des problèmes pour la programmation par contrat. En
C++, c'est plutôt l'exception d'avoir une fonction virtuelle
publique -- la plupart en sont privée. En Java, on ne peut pas
déclarer une fonction privée virtuelle.
Euh? Privée virtuelle = protected (sauf que protected est accessible
aussi depuis le package, mais en principe on n'authorise personne de
non fiable à écrire dans son package).
Comment est-ce qu'on l'empêche, vue que le package est ouvert ?
Oui enfin, en C++ on peut aussi dessassemblé le binaire pour brancher
(En fait, je crois que l'accessibilité « package », c'est la réponse de
Java au « friend » de C++. Ni l'un ni l'autre n'est totalement
satisfaisant.
Effectivement.
Mais pour que « package » soit une bonne réponse, il
faudra pouvoir fermer un package, et il faudrait supprimer l'accès
package aux classes dérivées en dehors du package. La possibilité de «
sceller » un fichier JAR s'adresse au premier problème, mais c'est un
hack, et pas du tout au bon endroit.)
Oui je trouve qu'il aurait pu faire mieux qu'un répertoire pour les
Du coup, c'est extrèmement difficile à forcer que tous les
appels de la fonction passent par une fonction non-virtuelle
(final, en Java) dans la classe de base ; fonction qui vérifie
que le contrat est maintenu.
public abstract class AbstractTest
{
public final void faire_truc()
{
pre_condition();
faire_vraiment_truc();
post_condition();
}
private void pre_condition();
private void post_condition();
protected abstract void faire_vraiment_truc();
}
C'est ce que j'ai fait dans la pratique, mais la perte de l'héritage
multiple était genant dans certains cas.- C++ permet la separation de l'implémentation et de l'interface.
En C++, c'est permis de définir des fonctions dans la définition
de la classe, comme on fait en Java, mais on constate très vite
que c'est une mauvaise idée. En Java, on n'a pas le choix. (Le
moyen qu'utilise C++ pour faire cette separation, l'inclusion
textuelle, est probablement le pire qu
En fait on peut très bien le faire en définissant une interface
pour chaque classe (ce qui n'est pas une mauvaise idée du reste),
c'est optionnel.
C'est optionnel en C++ aussi -- on *peut* écrire le C++ exactement comme
on écrit le Java. L'expérience a montré que c'est une très mauvaise
idée, et c'est interdit dans la plupart des régles de codage.
Quand a l'utilisation de l'interface, ça ne s'adresse que partiellement
au problème -- tu peux bien en déclarer des variables, mais tu ne peux
pas en créer des instances. Alors, du coup, il te faut une usine, et
beaucoup d'autres choses. C'est une solution assez lourde dans
l'ensemble.
Ce qu'il faudrait, idéalement, c'est des modules, comme en Ada. Mais une
fois de plus, la souplesse de C++ te permet à les simuler, plus ou
moins, et d'une façon vraiment pas très élégant, tandis qu'avec Java, tu
es coincé.- Java, au moins dans les implémentations que je connais, impose
un certain dynamisme, qui n'est pas toujours souhaitable. En
C++, si tu veux, tu peux découper ton programme en objets
dynamiques (DLL's sous Windows, objets partagés sous Unix, mais
dans les deux cas, ce qui fait la différence, c'est que
l'édition de liens se fait lors de l'execution.) Or,
globalement, un objet dynamique n'est qu'une chose de plus que
tu ne contrôles pas complètement lors de l'execution. On les
évite autant que possible, à cause des erreurs qui en
proviennent.
En faveur de Java, évidemment, ce sont des bibliothèques standard
pour à peu près tout, et dans certains cas, comme les JSP,
l'environement applicatif.
Une autre chose en faveur, que j'avais oublié, c'est la qualité de la
documentation en ligne. Il n'y a rien en C++ qui ne s'approche de ce que
tu as à partir de http://developer.java.sun.com/developer/infodocs/.
(C'est un très fort argument pour l'utilisation de Java dans
l'enseignement, par exemple.)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) ?
Ça dépend de ce que tu fais. Il y a aussi des benchmark qui tournent
plus vite en Java qu'en C++. Dans la plupart des applications, en
revanche, j'imagine que le fait que C++ ait des véritables valeurs,
qu'on peut allouer sur la pile, ou mettre directement dans une
collection, fait que le C++ serait plus rapide.
Effectivement, mais ce gain de performance dépend de la qualité du
programmeur et n'est pas toujours nécessaire...
C'est même très rarement nécessaire, je dirais. Bien que... Quand j'ai
écrit l'application Java pour la Dresdner Bank, pour qu'elle tourne
correctement, il a fallu remplacer les PC sur lesquels elle tournait
avec des PC plus puissant. Or, même aux prix d'aujourd'hui, remplacer
60000 PC, ce n'est pas donné. (Mais je crois que le problème était
Swing, et non Java en soi.)
ça ne m'étonnerait pas, maintenant Swing à fait des progrès et il y a
Plus important, pour des applications d'une certaine taille, je
trouve qu'on les développe plus rapidement en C++.
Je n'en suis pas convaincu, mais c'est normal ce genre de chose est
éminemment subjectif.
Ça se mésure. Je connais une ou deux boîtes qui l'ont mésuré. Le fait
est que pour un grand système :
- on dévelope plus rapidement en C++, et
- le résultat est nettement plus fiable en C++.
Pour des systèmes plus petits, c'est moins évident.
À la fin, tout dépend de l'application. Si je développais un site de
Web, je choisirais sûrement Java, à cause de tout l'environement autour.
Pour un logiciel client, j'aurais une tendance à préférer Java aussi, à
cause de Swing, et du modèle de deployement. Pour l'enseignement,
peut-être, à cause de la documentation et parce qu'il y a moins de
pièges bêtes (mais il y a tellement d'autres langages qui sont sans
doute supérieur aux deux). Pour d'autres choses, j'ai mes doutes.
"Fabien LE LEZ" a écrit dans le message news:On 28 Jul 2003 08:19:12 -0700, (Vincent) wrote:mais honnêtement peu d'entreprises peuvent se permettre de
maintenir une bibliothèque que leurs auteurs aurait abandonné...
Certes, mais une bibliothèque abandonnée mais en open source a plus
de chances d'être reprise par quelqu'un d'autre...
Peut être qu'il y a moins de formalités pour le reprendre. Mais un bon
produit commercial, avec une base de clients, c'est bien rare qu'il ne
soit pas repris.
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message news:
hdvcivc98dps6kc82bq5jah8tq6ng60dd3@4ax.com...
On 28 Jul 2003 08:19:12 -0700, vclassine@elan.fr (Vincent) wrote:
mais honnêtement peu d'entreprises peuvent se permettre de
maintenir une bibliothèque que leurs auteurs aurait abandonné...
Certes, mais une bibliothèque abandonnée mais en open source a plus
de chances d'être reprise par quelqu'un d'autre...
Peut être qu'il y a moins de formalités pour le reprendre. Mais un bon
produit commercial, avec une base de clients, c'est bien rare qu'il ne
soit pas repris.
"Fabien LE LEZ" a écrit dans le message news:On 28 Jul 2003 08:19:12 -0700, (Vincent) wrote:mais honnêtement peu d'entreprises peuvent se permettre de
maintenir une bibliothèque que leurs auteurs aurait abandonné...
Certes, mais une bibliothèque abandonnée mais en open source a plus
de chances d'être reprise par quelqu'un d'autre...
Peut être qu'il y a moins de formalités pour le reprendre. Mais un bon
produit commercial, avec une base de clients, c'est bien rare qu'il ne
soit pas repris.
James Kanze wrote in
news: soft.fr:Je te conseille de lire Andrei. (Gabi pourrait donner des références
exactes. J'ai un mal fou déjà avec son nom de famille.)
Alexandrescu ? Il a ecrit "Modern C++ Design" chez Addison Wesley et
quantités d'articles intéressants. D'ailleurs, c'est qui le 2eme nom
qui a participé au bouquin sur les templates avec Jossutis ? Ce n'est
pas lui d'ailleurs ?
James Kanze <kanze@gabi-soft.fr> wrote in
news:86n0exyoz3.fsf@alex.gabi- soft.fr:
Je te conseille de lire Andrei. (Gabi pourrait donner des références
exactes. J'ai un mal fou déjà avec son nom de famille.)
Alexandrescu ? Il a ecrit "Modern C++ Design" chez Addison Wesley et
quantités d'articles intéressants. D'ailleurs, c'est qui le 2eme nom
qui a participé au bouquin sur les templates avec Jossutis ? Ce n'est
pas lui d'ailleurs ?
James Kanze wrote in
news: soft.fr:Je te conseille de lire Andrei. (Gabi pourrait donner des références
exactes. J'ai un mal fou déjà avec son nom de famille.)
Alexandrescu ? Il a ecrit "Modern C++ Design" chez Addison Wesley et
quantités d'articles intéressants. D'ailleurs, c'est qui le 2eme nom
qui a participé au bouquin sur les templates avec Jossutis ? Ce n'est
pas lui d'ailleurs ?
wrote in message
news:...(Vincent) wrote in message
news:...(Endymion) wrote in message
news:...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) ?
C'est l'arbre qui cache la forêt, ces différences syntaxiques sont
la conséquence de différences de fond.Est-ce que l'héritage multiple change vraiment quelque chose ?
D'abord en java tu peux faire de l'héritage multiple d'interfaces
(une interface peut hériter de plusieurs autres, et une classe
peut implémenter plus d'interfaces).
Une interface logique définit un contrat. Avec des invariants, des
préconditions et des postconditions. Qu'on ne peut pas vérifier dans
une interface Java.Ce que tu ne peut pas faire c'est de l'héritage multiple de
comportement (une classe hérite de plusieurs).
A partir de là le fait que l'héritage multiple de classe soit
interdit rend pénible l'écriture de certains code, mais a aussi
des avantages de sécurité (d'ailleurs on pourrait dire qu'il en va
de même pour l'héritage simple de comportement).
Quel est l'avantage de sécurité ? Où plutôt, où sont les risques
associées à l'héritage multiple.
Les mêmes que ceux de l'héritage simple, mais multipliés.
Risque de fonctionnement incorrect si on ne documente pas la manière
d'hériter.
Risque d'impossibilité partielle de changer l'implémentation si on
documente en vue d'un héritage...
Mais ça ne concerne que les programmeurs objet avancés, les autres
font plus souvent des trucs dangereux avec... Si ça t'intéresse tu
peux jeter un coup d'oeil au fil "Pour ou contre un code 100%
objet" sur fr.comp.objet, il y a une discussion autour de ce
sujet...(j'ai lu un article disant que C/C++ était plus rapide que Java
Dans l'absolu, c'est vrai.
Pour beaucoup d'applications. Pas forcement pour toutes. Mais comme
tu dis, il y a bien peu d'applications où ça ferait une différence.
Au moins sous Windows, et à une moindre dégrée sous Solaris sur
Sparc ; beaucoup dépend de la qualité de la VM sur la plateforme, et
sur la plupart des plateformes, ce n'est pas terrible.
Et je ne parle pas des systèmes comme les Unisys 2200, où le
hardware ne supporte pas du tout le modèle imposé par Java.
D'ailleurs, si tu vas faire du virgule flottant, Java va ramer même
sur un IBM 390 (qui ne supporte pas IEEE très bien).
Là on change de domaine d'application, et pour ces OS là c'est vrai
qu'il faut encore y aller à l'ancienne, point de salut du côté de
wxWindows nonplus et encore moins de Kylix...
Si tu as besoin d'une vrai portabilité, il faut C++. Ou mieux, un
langage comme Ada, qui a une norme que les implémenteurs respectent,
mais qui peut s'implémenter sur n'importe quelle plateforme. (Mais
dans la pratique, c'est rare d'avoir besoin d'une telle
portabilité.)
La vitesse qui compte la plus, en général, c'est la vitesse de
développement.
Une fois qu'on a atteint la vitesse d'éxécution nécessaire, qui est
une contrainte du cahier des charges comme les autres...
Et là, beaucoup dépend de l'environement. Si tu développes, par
exemple, un site Web, l'infrastructure et les bibliothèques Java
vont faire que tu as déjà 90% de fait ; C++ n'a pas de chance. Si tu
développes un gros serveur, en revanche, le modèle de compilation de
Java va te coûter environ 20% par rapport à celui de C++ (qui n'est
déjà pas fameux). Si en plus, il faut que ce soit fiable, que quand
tu acquittes une requête, les données soient garanties sur disque,
alors, c'est infaisable en Java -- tu es obligé à passer par JNI, ce
qui, d'après le peu que j'ai vu, adopte les pires aspects des deux
côtés -- la légérté et l'élégance de l'écriture C++ avec la
souplesse et la vitesse de Java.
Ou si c'est un programme très court, qui s'execute et puis s'arrête.
Les temps de démarrage de la machine virtuelle sont loins d'être
négligeable.
Tout dépends ce que tu attend du programme...
Java demande un peu plus d'écriture à cause des try catch
fréquents, mais je dirais qu'un bon programmeur C++ les écrira (ou
les "if...else" qui les remplacent) partout où c'est obligatoire
en Java, donc match nul.
En général, en C++, on régle le problème avec les destructeurs. Ce
qui fait qu'il pourrait y avoir moins de code dans la plupart des
cas. Dans d'autres cas -- quand tu as des composants génériques (des
collections, etc.), en Java ou bien tu rénonces au typage statique
(et donc prend une risque supplémentaire des erreurs lors de
l'execution), ou bien, tu as des copies supplémentaire du code, qui
ne varie que par le type. Mais dans l'ensemble, je m'attendrais à un
peu plus de lignes en C++. Parce que tu fais plus -- tu vérifies les
précondtions et les postconditions (que tu ne peux pas faire en
java), par exemple. Le resultat, c'est un code plus robuste en C++.
pour info:
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
si ce dont tu parles ne se trouve pas dans cette page tu peux me
donner un exemple en C++, stp.
kanze@gabi-soft.fr wrote in message
news:<d6652001.0307290232.155b5e42@posting.google.com>...
vclassine@elan.fr (Vincent) wrote in message
news:<9e49e584.0307280504.515584ab@posting.google.com>...
pr.nm@laposte.net (Endymion) wrote in message
news:<4219ae8a.0307242127.6e18880c@posting.google.com>...
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) ?
C'est l'arbre qui cache la forêt, ces différences syntaxiques sont
la conséquence de différences de fond.
Est-ce que l'héritage multiple change vraiment quelque chose ?
D'abord en java tu peux faire de l'héritage multiple d'interfaces
(une interface peut hériter de plusieurs autres, et une classe
peut implémenter plus d'interfaces).
Une interface logique définit un contrat. Avec des invariants, des
préconditions et des postconditions. Qu'on ne peut pas vérifier dans
une interface Java.
Ce que tu ne peut pas faire c'est de l'héritage multiple de
comportement (une classe hérite de plusieurs).
A partir de là le fait que l'héritage multiple de classe soit
interdit rend pénible l'écriture de certains code, mais a aussi
des avantages de sécurité (d'ailleurs on pourrait dire qu'il en va
de même pour l'héritage simple de comportement).
Quel est l'avantage de sécurité ? Où plutôt, où sont les risques
associées à l'héritage multiple.
Les mêmes que ceux de l'héritage simple, mais multipliés.
Risque de fonctionnement incorrect si on ne documente pas la manière
d'hériter.
Risque d'impossibilité partielle de changer l'implémentation si on
documente en vue d'un héritage...
Mais ça ne concerne que les programmeurs objet avancés, les autres
font plus souvent des trucs dangereux avec... Si ça t'intéresse tu
peux jeter un coup d'oeil au fil "Pour ou contre un code 100%
objet" sur fr.comp.objet, il y a une discussion autour de ce
sujet...
(j'ai lu un article disant que C/C++ était plus rapide que Java
Dans l'absolu, c'est vrai.
Pour beaucoup d'applications. Pas forcement pour toutes. Mais comme
tu dis, il y a bien peu d'applications où ça ferait une différence.
Au moins sous Windows, et à une moindre dégrée sous Solaris sur
Sparc ; beaucoup dépend de la qualité de la VM sur la plateforme, et
sur la plupart des plateformes, ce n'est pas terrible.
Et je ne parle pas des systèmes comme les Unisys 2200, où le
hardware ne supporte pas du tout le modèle imposé par Java.
D'ailleurs, si tu vas faire du virgule flottant, Java va ramer même
sur un IBM 390 (qui ne supporte pas IEEE très bien).
Là on change de domaine d'application, et pour ces OS là c'est vrai
qu'il faut encore y aller à l'ancienne, point de salut du côté de
wxWindows nonplus et encore moins de Kylix...
Si tu as besoin d'une vrai portabilité, il faut C++. Ou mieux, un
langage comme Ada, qui a une norme que les implémenteurs respectent,
mais qui peut s'implémenter sur n'importe quelle plateforme. (Mais
dans la pratique, c'est rare d'avoir besoin d'une telle
portabilité.)
La vitesse qui compte la plus, en général, c'est la vitesse de
développement.
Une fois qu'on a atteint la vitesse d'éxécution nécessaire, qui est
une contrainte du cahier des charges comme les autres...
Et là, beaucoup dépend de l'environement. Si tu développes, par
exemple, un site Web, l'infrastructure et les bibliothèques Java
vont faire que tu as déjà 90% de fait ; C++ n'a pas de chance. Si tu
développes un gros serveur, en revanche, le modèle de compilation de
Java va te coûter environ 20% par rapport à celui de C++ (qui n'est
déjà pas fameux). Si en plus, il faut que ce soit fiable, que quand
tu acquittes une requête, les données soient garanties sur disque,
alors, c'est infaisable en Java -- tu es obligé à passer par JNI, ce
qui, d'après le peu que j'ai vu, adopte les pires aspects des deux
côtés -- la légérté et l'élégance de l'écriture C++ avec la
souplesse et la vitesse de Java.
Ou si c'est un programme très court, qui s'execute et puis s'arrête.
Les temps de démarrage de la machine virtuelle sont loins d'être
négligeable.
Tout dépends ce que tu attend du programme...
Java demande un peu plus d'écriture à cause des try catch
fréquents, mais je dirais qu'un bon programmeur C++ les écrira (ou
les "if...else" qui les remplacent) partout où c'est obligatoire
en Java, donc match nul.
En général, en C++, on régle le problème avec les destructeurs. Ce
qui fait qu'il pourrait y avoir moins de code dans la plupart des
cas. Dans d'autres cas -- quand tu as des composants génériques (des
collections, etc.), en Java ou bien tu rénonces au typage statique
(et donc prend une risque supplémentaire des erreurs lors de
l'execution), ou bien, tu as des copies supplémentaire du code, qui
ne varie que par le type. Mais dans l'ensemble, je m'attendrais à un
peu plus de lignes en C++. Parce que tu fais plus -- tu vérifies les
précondtions et les postconditions (que tu ne peux pas faire en
java), par exemple. Le resultat, c'est un code plus robuste en C++.
pour info:
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
si ce dont tu parles ne se trouve pas dans cette page tu peux me
donner un exemple en C++, stp.
wrote in message
news:...(Vincent) wrote in message
news:...(Endymion) wrote in message
news:...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) ?
C'est l'arbre qui cache la forêt, ces différences syntaxiques sont
la conséquence de différences de fond.Est-ce que l'héritage multiple change vraiment quelque chose ?
D'abord en java tu peux faire de l'héritage multiple d'interfaces
(une interface peut hériter de plusieurs autres, et une classe
peut implémenter plus d'interfaces).
Une interface logique définit un contrat. Avec des invariants, des
préconditions et des postconditions. Qu'on ne peut pas vérifier dans
une interface Java.Ce que tu ne peut pas faire c'est de l'héritage multiple de
comportement (une classe hérite de plusieurs).
A partir de là le fait que l'héritage multiple de classe soit
interdit rend pénible l'écriture de certains code, mais a aussi
des avantages de sécurité (d'ailleurs on pourrait dire qu'il en va
de même pour l'héritage simple de comportement).
Quel est l'avantage de sécurité ? Où plutôt, où sont les risques
associées à l'héritage multiple.
Les mêmes que ceux de l'héritage simple, mais multipliés.
Risque de fonctionnement incorrect si on ne documente pas la manière
d'hériter.
Risque d'impossibilité partielle de changer l'implémentation si on
documente en vue d'un héritage...
Mais ça ne concerne que les programmeurs objet avancés, les autres
font plus souvent des trucs dangereux avec... Si ça t'intéresse tu
peux jeter un coup d'oeil au fil "Pour ou contre un code 100%
objet" sur fr.comp.objet, il y a une discussion autour de ce
sujet...(j'ai lu un article disant que C/C++ était plus rapide que Java
Dans l'absolu, c'est vrai.
Pour beaucoup d'applications. Pas forcement pour toutes. Mais comme
tu dis, il y a bien peu d'applications où ça ferait une différence.
Au moins sous Windows, et à une moindre dégrée sous Solaris sur
Sparc ; beaucoup dépend de la qualité de la VM sur la plateforme, et
sur la plupart des plateformes, ce n'est pas terrible.
Et je ne parle pas des systèmes comme les Unisys 2200, où le
hardware ne supporte pas du tout le modèle imposé par Java.
D'ailleurs, si tu vas faire du virgule flottant, Java va ramer même
sur un IBM 390 (qui ne supporte pas IEEE très bien).
Là on change de domaine d'application, et pour ces OS là c'est vrai
qu'il faut encore y aller à l'ancienne, point de salut du côté de
wxWindows nonplus et encore moins de Kylix...
Si tu as besoin d'une vrai portabilité, il faut C++. Ou mieux, un
langage comme Ada, qui a une norme que les implémenteurs respectent,
mais qui peut s'implémenter sur n'importe quelle plateforme. (Mais
dans la pratique, c'est rare d'avoir besoin d'une telle
portabilité.)
La vitesse qui compte la plus, en général, c'est la vitesse de
développement.
Une fois qu'on a atteint la vitesse d'éxécution nécessaire, qui est
une contrainte du cahier des charges comme les autres...
Et là, beaucoup dépend de l'environement. Si tu développes, par
exemple, un site Web, l'infrastructure et les bibliothèques Java
vont faire que tu as déjà 90% de fait ; C++ n'a pas de chance. Si tu
développes un gros serveur, en revanche, le modèle de compilation de
Java va te coûter environ 20% par rapport à celui de C++ (qui n'est
déjà pas fameux). Si en plus, il faut que ce soit fiable, que quand
tu acquittes une requête, les données soient garanties sur disque,
alors, c'est infaisable en Java -- tu es obligé à passer par JNI, ce
qui, d'après le peu que j'ai vu, adopte les pires aspects des deux
côtés -- la légérté et l'élégance de l'écriture C++ avec la
souplesse et la vitesse de Java.
Ou si c'est un programme très court, qui s'execute et puis s'arrête.
Les temps de démarrage de la machine virtuelle sont loins d'être
négligeable.
Tout dépends ce que tu attend du programme...
Java demande un peu plus d'écriture à cause des try catch
fréquents, mais je dirais qu'un bon programmeur C++ les écrira (ou
les "if...else" qui les remplacent) partout où c'est obligatoire
en Java, donc match nul.
En général, en C++, on régle le problème avec les destructeurs. Ce
qui fait qu'il pourrait y avoir moins de code dans la plupart des
cas. Dans d'autres cas -- quand tu as des composants génériques (des
collections, etc.), en Java ou bien tu rénonces au typage statique
(et donc prend une risque supplémentaire des erreurs lors de
l'execution), ou bien, tu as des copies supplémentaire du code, qui
ne varie que par le type. Mais dans l'ensemble, je m'attendrais à un
peu plus de lignes en C++. Parce que tu fais plus -- tu vérifies les
précondtions et les postconditions (que tu ne peux pas faire en
java), par exemple. Le resultat, c'est un code plus robuste en C++.
pour info:
http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html
si ce dont tu parles ne se trouve pas dans cette page tu peux me
donner un exemple en C++, stp.
Non. C'est David Vandervoorde. (Dans les groupes anglophones, il écrit
son nom Daveed, pour qu'on le prononce correctement. Il est belge, et
malgré son nom de famille, belge francophone.)
Non. C'est David Vandervoorde. (Dans les groupes anglophones, il écrit
son nom Daveed, pour qu'on le prononce correctement. Il est belge, et
malgré son nom de famille, belge francophone.)
Non. C'est David Vandervoorde. (Dans les groupes anglophones, il écrit
son nom Daveed, pour qu'on le prononce correctement. Il est belge, et
malgré son nom de famille, belge francophone.)
Luc Hermitte wrote:James Kanze wrote in news:
soft.fr:Je te conseille de lire Andrei. (Gabi pourrait donner des
références exactes. J'ai un mal fou déjà avec son nom de
famille.)
Alexandrescu ? Il a ecrit "Modern C++ Design" chez Addison Wesley et
quantités d'articles intéressants.
100% d'accord.D'ailleurs, c'est qui le 2eme nom qui
a participé au bouquin sur les templates avec Jossutis ? Ce n'est pas lui
d'ailleurs ?
Non, ce n'est pas lui. Le compère de Jossutis est David Vandevoorde.
Luc Hermitte wrote:
James Kanze <kanze@gabi-soft.fr> wrote in news:86n0exyoz3.fsf@alex.gabi-
soft.fr:
Je te conseille de lire Andrei. (Gabi pourrait donner des
références exactes. J'ai un mal fou déjà avec son nom de
famille.)
Alexandrescu ? Il a ecrit "Modern C++ Design" chez Addison Wesley et
quantités d'articles intéressants.
100% d'accord.
D'ailleurs, c'est qui le 2eme nom qui
a participé au bouquin sur les templates avec Jossutis ? Ce n'est pas lui
d'ailleurs ?
Non, ce n'est pas lui. Le compère de Jossutis est David Vandevoorde.
Luc Hermitte wrote:James Kanze wrote in news:
soft.fr:Je te conseille de lire Andrei. (Gabi pourrait donner des
références exactes. J'ai un mal fou déjà avec son nom de
famille.)
Alexandrescu ? Il a ecrit "Modern C++ Design" chez Addison Wesley et
quantités d'articles intéressants.
100% d'accord.D'ailleurs, c'est qui le 2eme nom qui
a participé au bouquin sur les templates avec Jossutis ? Ce n'est pas lui
d'ailleurs ?
Non, ce n'est pas lui. Le compère de Jossutis est David Vandevoorde.
(Vincent) writes:
[...]
Les templates, tels que certains les utilisent, sont
révolutionnaire. Je ne sais si les bureaux d'études sont près
pour cette révolution-là -- je crois plutôt que non, mais
c'est bien autre chose qu'une commodité syntactique. C'est
peut-être même plus que l'introduction des fonctions, pour dire
à quel point c'est autre chose. (C'est pour ça, d'ailleurs,
qu'il faut du temps avant qu'il devient une technologie courante.)
|> mais ça reste une "commodité syntaxique"... J'entends par
|> là que ça n'apporte pas de nouvelle possibilités.
Je te conseille de lire Andrei. (Gabi pourrait donner des
références exactes. J'ai un mal fou déjà avec son nom de
famille.) Qu'on soit d'accord avec ce qu'il fait ou non (et j'ai mes
doutes sur l'applicabilité dans l'industrie), ça dépasse de
loins ce que j'appellerai une commodité syntactique.
vclassine@elan.fr (Vincent) writes:
[...]
Les templates, tels que certains les utilisent, sont
révolutionnaire. Je ne sais si les bureaux d'études sont près
pour cette révolution-là -- je crois plutôt que non, mais
c'est bien autre chose qu'une commodité syntactique. C'est
peut-être même plus que l'introduction des fonctions, pour dire
à quel point c'est autre chose. (C'est pour ça, d'ailleurs,
qu'il faut du temps avant qu'il devient une technologie courante.)
|> mais ça reste une "commodité syntaxique"... J'entends par
|> là que ça n'apporte pas de nouvelle possibilités.
Je te conseille de lire Andrei. (Gabi pourrait donner des
références exactes. J'ai un mal fou déjà avec son nom de
famille.) Qu'on soit d'accord avec ce qu'il fait ou non (et j'ai mes
doutes sur l'applicabilité dans l'industrie), ça dépasse de
loins ce que j'appellerai une commodité syntactique.
(Vincent) writes:
[...]
Les templates, tels que certains les utilisent, sont
révolutionnaire. Je ne sais si les bureaux d'études sont près
pour cette révolution-là -- je crois plutôt que non, mais
c'est bien autre chose qu'une commodité syntactique. C'est
peut-être même plus que l'introduction des fonctions, pour dire
à quel point c'est autre chose. (C'est pour ça, d'ailleurs,
qu'il faut du temps avant qu'il devient une technologie courante.)
|> mais ça reste une "commodité syntaxique"... J'entends par
|> là que ça n'apporte pas de nouvelle possibilités.
Je te conseille de lire Andrei. (Gabi pourrait donner des
références exactes. J'ai un mal fou déjà avec son nom de
famille.) Qu'on soit d'accord avec ce qu'il fait ou non (et j'ai mes
doutes sur l'applicabilité dans l'industrie), ça dépasse de
loins ce que j'appellerai une commodité syntactique.
