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.
"Christophe Lephay" a écrit dans le message news: bg48p5$hbd$
Je crois que ce n'est pas demain la veille que C++ intègrera une GUI. C'est
lié, de mon point de vue, au positionnement de C++ en ce qui concerne l'efficacité : standardiser quelque chose qui dépend autant de l'environnement ne peut se faire que par un nivellement par le bas (tant sur
le plan des performances que du nombre de fonctionnalités).
Je ne suis pas d'accord, c'est ce que j'appelle (de leur part) une position de Ponce-Pilate : puisque les experts, avec les contraintes réelles que tu cites, ne peuvent faire quelque chose d'idéal, laissons donc les autres faire ce qu'ils veulent chacun dans leur coin, ce qui laisse les mains libres par la suite pour critiquer leur façon de faire, et leur balancer, en plus, avec la plus parfaite mauvaise foi, l'argument de non portabilité. Belle mentalité ! ;-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
news: bg48p5$hbd$1@news-reader1.wanadoo.fr...
Je crois que ce n'est pas demain la veille que C++ intègrera une GUI.
C'est
lié, de mon point de vue, au positionnement de C++ en ce qui concerne
l'efficacité : standardiser quelque chose qui dépend autant de
l'environnement ne peut se faire que par un nivellement par le bas (tant
sur
le plan des performances que du nombre de fonctionnalités).
Je ne suis pas d'accord, c'est ce que j'appelle (de leur part) une
position de Ponce-Pilate : puisque les experts, avec les contraintes
réelles que tu cites, ne peuvent faire quelque chose d'idéal, laissons
donc les autres faire ce qu'ils veulent chacun dans leur coin, ce qui
laisse les mains libres par la suite pour critiquer leur façon de faire,
et leur balancer, en plus, avec la plus parfaite mauvaise foi, l'argument
de non portabilité. Belle mentalité ! ;-)
--
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
"Christophe Lephay" a écrit dans le message news: bg48p5$hbd$
Je crois que ce n'est pas demain la veille que C++ intègrera une GUI. C'est
lié, de mon point de vue, au positionnement de C++ en ce qui concerne l'efficacité : standardiser quelque chose qui dépend autant de l'environnement ne peut se faire que par un nivellement par le bas (tant sur
le plan des performances que du nombre de fonctionnalités).
Je ne suis pas d'accord, c'est ce que j'appelle (de leur part) une position de Ponce-Pilate : puisque les experts, avec les contraintes réelles que tu cites, ne peuvent faire quelque chose d'idéal, laissons donc les autres faire ce qu'ils veulent chacun dans leur coin, ce qui laisse les mains libres par la suite pour critiquer leur façon de faire, et leur balancer, en plus, avec la plus parfaite mauvaise foi, l'argument de non portabilité. Belle mentalité ! ;-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Alain Naigeon
"Christophe Lephay" a écrit dans le message news: bg54b7$q5$
"Endymion" a écrit dans le message de news:
Est-ce qu'on peut dire que définir une classe abstraite avec quelques méthodes abstraites et quelques champs et demader aux programmeurs d'écrire des sous-classes de cette classe abstraite, c'est de la programmation par contrat ?
Le principe est plus simple que ça, c'est juste d'énoncer clairement quelles valeurs, ou quelles relations entre valeurs, une classe doit vérifier à tout moment, ou en entrée et sortie d'une opération. Et de se donner les moyens, dans le langage, d'exprimer ces contraintes, et d'avertir (de façon récupérable) quand elles sont violées). Enfin, il me semble que ça donne une première idée.
Ensuite, un truc sur le quel Meyer insiste : le contrat n'existe pas seulement pour la classe, mais aussi pour l'appelant d'une méthode : Tel genre de résultat est garanti (et/ou tel ou tel invariant est conservé...) **si** l'entrée vérifie telle et telle condition.
(il ne s'agit pas, évidemment, de demander l'impossible)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
news: bg54b7$q5$1@news-reader5.wanadoo.fr...
"Endymion" <pr.nm@laposte.net> a écrit dans le message de
news:4219ae8a.0307282155.5b57c3d8@posting.google.com...
Est-ce qu'on peut dire que définir une classe abstraite avec quelques
méthodes abstraites et quelques champs et demader aux programmeurs
d'écrire des sous-classes de cette classe abstraite, c'est de la
programmation par contrat ?
Le principe est plus simple que ça, c'est juste d'énoncer clairement
quelles valeurs, ou quelles relations entre valeurs, une classe doit
vérifier à tout moment, ou en entrée et sortie d'une opération.
Et de se donner les moyens, dans le langage, d'exprimer ces
contraintes, et d'avertir (de façon récupérable) quand elles sont
violées).
Enfin, il me semble que ça donne une première idée.
Ensuite, un truc sur le quel Meyer insiste : le contrat n'existe pas
seulement pour la classe, mais aussi pour l'appelant d'une
méthode :
Tel genre de résultat est garanti (et/ou tel ou tel invariant
est conservé...)
**si**
l'entrée vérifie telle et telle condition.
(il ne s'agit pas, évidemment, de demander l'impossible)
--
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
"Christophe Lephay" a écrit dans le message news: bg54b7$q5$
"Endymion" a écrit dans le message de news:
Est-ce qu'on peut dire que définir une classe abstraite avec quelques méthodes abstraites et quelques champs et demader aux programmeurs d'écrire des sous-classes de cette classe abstraite, c'est de la programmation par contrat ?
Le principe est plus simple que ça, c'est juste d'énoncer clairement quelles valeurs, ou quelles relations entre valeurs, une classe doit vérifier à tout moment, ou en entrée et sortie d'une opération. Et de se donner les moyens, dans le langage, d'exprimer ces contraintes, et d'avertir (de façon récupérable) quand elles sont violées). Enfin, il me semble que ça donne une première idée.
Ensuite, un truc sur le quel Meyer insiste : le contrat n'existe pas seulement pour la classe, mais aussi pour l'appelant d'une méthode : Tel genre de résultat est garanti (et/ou tel ou tel invariant est conservé...) **si** l'entrée vérifie telle et telle condition.
(il ne s'agit pas, évidemment, de demander l'impossible)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Loïc Joly
Martinez Jerome wrote:
James Kanze wrote:
Sans parler de l'aspect risque. Quand j'étais à la Dresdner Bank, ils ont décidé de réécrire toute une application en Java, parce que la bibliothèque de fenêtrage sur laquelle elle était basée était retirée du marché.
D'ou l'interet de l'open-source... (Et c'est pourquoi je préfère WxWindows a Qt, trop restrictif a mon gout)
Il me semble que sur ce point particulier, TrollTech a signé un contrat
stipulant qu'en cas de faillite, QT basculerait automatiquement dans l'OpenSource.
-- Loïc
Martinez Jerome wrote:
James Kanze wrote:
Sans parler de l'aspect risque. Quand j'étais à la Dresdner
Bank, ils ont décidé de réécrire toute une application en
Java, parce que la bibliothèque de fenêtrage sur laquelle elle
était basée était retirée du marché.
D'ou l'interet de l'open-source...
(Et c'est pourquoi je préfère WxWindows a Qt, trop restrictif a mon gout)
Il me semble que sur ce point particulier, TrollTech a signé un contrat
stipulant qu'en cas de faillite, QT basculerait automatiquement dans
l'OpenSource.
Sans parler de l'aspect risque. Quand j'étais à la Dresdner Bank, ils ont décidé de réécrire toute une application en Java, parce que la bibliothèque de fenêtrage sur laquelle elle était basée était retirée du marché.
D'ou l'interet de l'open-source... (Et c'est pourquoi je préfère WxWindows a Qt, trop restrictif a mon gout)
Il me semble que sur ce point particulier, TrollTech a signé un contrat
stipulant qu'en cas de faillite, QT basculerait automatiquement dans l'OpenSource.
-- Loïc
Olivier LUONG
Ce n'est pas dit. Si tu fais attention à ne travailler qu'avec les double[], le résultat pourrait être même plus vite qu'avec C++. Sur certaines plateformes, en tout cas -- la portabilité à ce niveau, ce n'est pas le fort de Java.
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... :) )
Jeffrey Richter dans son livre sur .NET Framework, explique pourquoi dans certain cas une application peut tourner plus vite avec tu codes précompilé plutot qu'un code compilé.
En général tu distribues non pas ton code (hors open source) mais ton binaire hors le binaire que tu vas compilé tu vas faire en sorte qu'il soit compatible avec autant de plateforme possible. Donc tu vas évité toute optimisation lié au matériel, ou bien comme c'etait le cas avec FlaskMPEG tu auras une version pour athlon et une version générique...
Alors qu'avec une compilation précompilé, tu vas permettre au compilateur de compilé le code en fonction des spécificité du matériel de la machine exécutant le code => gain de possible de performance durant l'exécution...
donc précompilé = coût fixe + gain variable fonction notamment de la durée d'exécution code compilé pas de coût fixe, mais pas ou peu d'optimisation si tu veux pouvoir optimisé on peut s'attendre a une certaine lourdeur de ton code => difficulté de maintenance....
tout ceci reste pour moi théorique, si vous avez des exemples concret je suis preneur :)
Olivier
Ce n'est pas dit. Si tu fais attention à ne travailler qu'avec les
double[], le résultat pourrait être même plus vite qu'avec C++. Sur
certaines plateformes, en tout cas -- la portabilité à ce niveau, ce
n'est pas le fort de Java.
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... :) )
Jeffrey Richter dans son livre sur .NET Framework, explique pourquoi dans
certain cas une application peut tourner plus vite avec tu codes précompilé
plutot qu'un code compilé.
En général tu distribues non pas ton code (hors open source) mais ton
binaire
hors le binaire que tu vas compilé tu vas faire en sorte qu'il soit
compatible avec
autant de plateforme possible. Donc tu vas évité toute optimisation lié au
matériel, ou
bien comme c'etait le cas avec FlaskMPEG tu auras une version pour athlon
et une version générique...
Alors qu'avec une compilation précompilé, tu vas permettre au compilateur
de compilé le code en fonction des spécificité du matériel de la machine
exécutant le code => gain de possible de performance durant l'exécution...
donc précompilé = coût fixe + gain variable fonction notamment de la durée
d'exécution
code compilé pas de coût fixe, mais pas ou peu d'optimisation si tu veux
pouvoir
optimisé on peut s'attendre a une certaine lourdeur de ton code =>
difficulté de maintenance....
tout ceci reste pour moi théorique, si vous avez des exemples concret je
suis preneur :)
Ce n'est pas dit. Si tu fais attention à ne travailler qu'avec les double[], le résultat pourrait être même plus vite qu'avec C++. Sur certaines plateformes, en tout cas -- la portabilité à ce niveau, ce n'est pas le fort de Java.
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... :) )
Jeffrey Richter dans son livre sur .NET Framework, explique pourquoi dans certain cas une application peut tourner plus vite avec tu codes précompilé plutot qu'un code compilé.
En général tu distribues non pas ton code (hors open source) mais ton binaire hors le binaire que tu vas compilé tu vas faire en sorte qu'il soit compatible avec autant de plateforme possible. Donc tu vas évité toute optimisation lié au matériel, ou bien comme c'etait le cas avec FlaskMPEG tu auras une version pour athlon et une version générique...
Alors qu'avec une compilation précompilé, tu vas permettre au compilateur de compilé le code en fonction des spécificité du matériel de la machine exécutant le code => gain de possible de performance durant l'exécution...
donc précompilé = coût fixe + gain variable fonction notamment de la durée d'exécution code compilé pas de coût fixe, mais pas ou peu d'optimisation si tu veux pouvoir optimisé on peut s'attendre a une certaine lourdeur de ton code => difficulté de maintenance....
tout ceci reste pour moi théorique, si vous avez des exemples concret je suis preneur :)
Olivier
Loïc Joly
Vincent wrote:
Euh? En C++ on peut écrire une fonction redéfinissable mais pas appelable par la classe fille?
Oui.
class A { private: virtual void f(); };
f est redéfinissable, mais non appelable, ni par le client, ni par la classe fille.
du reste, je n'ai jamais trouvé cet argument particulièrement pertinent. C'est à l'environnement de développement d'être capable, à partir d'un fichier source, de fournir l'interface. De ce côté-là, javadoc est plutôt performant.
Je ne sais pas si la remarque initiale conceranait l'aspect documentaire, il est vrai que dans ce cas javadoc est la réponse.
Je pense que l'argument principal est de pouvoir modifier l'implémentation en étant certain de ne pas toucher l'interface (et une gestion par fichier permet au système de compilation de tenir compte facilement de ce fait pour optimiser énormément le temps de compilation).
-- Loïc
Vincent wrote:
Euh? En C++ on peut écrire une fonction redéfinissable mais pas
appelable par la classe fille?
Oui.
class A
{
private:
virtual void f();
};
f est redéfinissable, mais non appelable, ni par le client, ni par la
classe fille.
du reste, je n'ai jamais trouvé cet argument particulièrement pertinent.
C'est à l'environnement de développement d'être capable, à partir d'un
fichier source, de fournir l'interface. De ce côté-là, javadoc est
plutôt performant.
Je ne sais pas si la remarque initiale conceranait l'aspect
documentaire, il est vrai que dans ce cas javadoc est la réponse.
Je pense que l'argument principal est de pouvoir modifier
l'implémentation en étant certain de ne pas toucher l'interface (et une
gestion par fichier permet au système de compilation de tenir compte
facilement de ce fait pour optimiser énormément le temps de compilation).
Euh? En C++ on peut écrire une fonction redéfinissable mais pas appelable par la classe fille?
Oui.
class A { private: virtual void f(); };
f est redéfinissable, mais non appelable, ni par le client, ni par la classe fille.
du reste, je n'ai jamais trouvé cet argument particulièrement pertinent. C'est à l'environnement de développement d'être capable, à partir d'un fichier source, de fournir l'interface. De ce côté-là, javadoc est plutôt performant.
Je ne sais pas si la remarque initiale conceranait l'aspect documentaire, il est vrai que dans ce cas javadoc est la réponse.
Je pense que l'argument principal est de pouvoir modifier l'implémentation en étant certain de ne pas toucher l'interface (et une gestion par fichier permet au système de compilation de tenir compte facilement de ce fait pour optimiser énormément le temps de compilation).
-- Loïc
Loïc Joly
Vincent wrote:
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.
je te recommande chaudement la lecture de "Modern C++ Design", ou bien de te pencher sur le design de certaines librairies (Boost, ATL, Blitz,....). Les templates ne servent pas qu'à faire des conteneurs de T, loin de là.
Oui, mais quoi qu'il arrive ça ne fait que remplacer le <template> par le vrai type, non? D'où l'idée de "commodité syntaxique"...
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.
-- Loïc
Vincent wrote:
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.
je
te recommande chaudement la lecture de "Modern C++ Design", ou bien de te
pencher sur le design de certaines librairies (Boost, ATL, Blitz,....). Les
templates ne servent pas qu'à faire des conteneurs de T, loin de là.
Oui, mais quoi qu'il arrive ça ne fait que remplacer le <template> par
le vrai type, non? D'où l'idée de "commodité syntaxique"...
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.
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.
je te recommande chaudement la lecture de "Modern C++ Design", ou bien de te pencher sur le design de certaines librairies (Boost, ATL, Blitz,....). Les templates ne servent pas qu'à faire des conteneurs de T, loin de là.
Oui, mais quoi qu'il arrive ça ne fait que remplacer le <template> par le vrai type, non? D'où l'idée de "commodité syntaxique"...
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.
-- Loïc
Fabien LE LEZ
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...
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
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...
--
Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/
et http://www.aminautes.org/forums/serveurs/tablefr.html
Archives : http://groups.google.com/advanced_group_search
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
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...
-- Tout sur fr.* (FAQ, etc.) : http://www.usenet-fr.net/fur/ et http://www.aminautes.org/forums/serveurs/tablefr.html Archives : http://groups.google.com/advanced_group_search http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
Gabriel Dos Reis
Fabien LE LEZ writes:
| 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...
comme libg++ ? :-)
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| 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...
| 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...
comme libg++ ? :-)
-- Gaby
Gabriel Dos Reis
Loïc Joly writes:
| Un argument est que si tu as codé vite, il te reste du temps pour | optimiser là où tu en a besoin.
J'ai souvent entendu « si tu codes vite, il te restera du temps pour debugguer » ;-)
-- Gaby
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| Un argument est que si tu as codé vite, il te reste du temps pour
| optimiser là où tu en a besoin.
J'ai souvent entendu « si tu codes vite, il te restera du temps pour
debugguer » ;-)
| Un argument est que si tu as codé vite, il te reste du temps pour | optimiser là où tu en a besoin.
J'ai souvent entendu « si tu codes vite, il te restera du temps pour debugguer » ;-)
-- Gaby
kanze
(Vincent) wrote in message 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.
je te recommande chaudement la lecture de "Modern C++ Design", ou bien de te pencher sur le design de certaines librairies (Boost, ATL, Blitz,....). Les templates ne servent pas qu'à faire des conteneurs de T, loin de là.
Oui, mais quoi qu'il arrive ça ne fait que remplacer le <template> par le vrai type, non? D'où l'idée de "commodité syntaxique"...
D'abord, évidemment, les paramètres d'un template ne sont pas forcément des types -- il peut être des entiers ou des pointeurs ou des références aussi. Deuxièmement, en C++, on peut avoir des fonctions templatées aussi, et non seulement des classes, et enfin (et surtout), le compilateur peut déduire lui-même les paramètres d'une fonction templatée.
Et évidemment, on peut aussi faire des spécialisations explicites.
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. Et du moment qu'on peut calculer, ou même faire des décisions simple, c'est plus qu'un simple commodité syntaxique.
Considère un exemple simple : tu veux déclarer un buffer assez grand pour contenir des chiffres générés par la conversion d'un int en décimal. D'une façon portable -- c'est clair que sous Windows, la réponse est 11 (10 chiffres plus la signe), mais toutes les machines n'ont pas des int de 32 bits. En C++ moderne, tu utilises la template suivante :
template< size_t N > struct MaxDigits { static size_t const value = 1 + MaxDigits< N / 10 >::value ; } ;
instantié sur INT_MAX (ou SHRT_MAX, ou ta valeur maximum, n'importe ce qu'elle est), ainsi : char buffer[ MaxDigits< INT_MAX >::value ] ; Évidemment, tu peux faire la calcule à la main, et puis y écrire la valeur voulue. Mais il ne faut pas oublier de le faire de nouveau chaque fois tu passes à une autre machine.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
vclassine@elan.fr (Vincent) wrote in message
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.
je te recommande chaudement la lecture de "Modern C++ Design", ou
bien de te pencher sur le design de certaines librairies (Boost,
ATL, Blitz,....). Les templates ne servent pas qu'à faire des
conteneurs de T, loin de là.
Oui, mais quoi qu'il arrive ça ne fait que remplacer le <template> par
le vrai type, non? D'où l'idée de "commodité syntaxique"...
D'abord, évidemment, les paramètres d'un template ne sont pas forcément
des types -- il peut être des entiers ou des pointeurs ou des références
aussi. Deuxièmement, en C++, on peut avoir des fonctions templatées
aussi, et non seulement des classes, et enfin (et surtout), le
compilateur peut déduire lui-même les paramètres d'une fonction
templatée.
Et évidemment, on peut aussi faire des spécialisations explicites.
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. Et du moment qu'on peut calculer, ou même faire
des décisions simple, c'est plus qu'un simple commodité syntaxique.
Considère un exemple simple : tu veux déclarer un buffer assez grand
pour contenir des chiffres générés par la conversion d'un int en
décimal. D'une façon portable -- c'est clair que sous Windows, la
réponse est 11 (10 chiffres plus la signe), mais toutes les machines
n'ont pas des int de 32 bits. En C++ moderne, tu utilises la template
suivante :
template< size_t N >
struct MaxDigits
{
static size_t const value = 1 + MaxDigits< N / 10 >::value ;
} ;
instantié sur INT_MAX (ou SHRT_MAX, ou ta valeur maximum, n'importe ce
qu'elle est), ainsi :
char buffer[ MaxDigits< INT_MAX >::value ] ;
Évidemment, tu peux faire la calcule à la main, et puis y écrire la
valeur voulue. Mais il ne faut pas oublier de le faire de nouveau chaque
fois tu passes à une autre machine.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
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.
je te recommande chaudement la lecture de "Modern C++ Design", ou bien de te pencher sur le design de certaines librairies (Boost, ATL, Blitz,....). Les templates ne servent pas qu'à faire des conteneurs de T, loin de là.
Oui, mais quoi qu'il arrive ça ne fait que remplacer le <template> par le vrai type, non? D'où l'idée de "commodité syntaxique"...
D'abord, évidemment, les paramètres d'un template ne sont pas forcément des types -- il peut être des entiers ou des pointeurs ou des références aussi. Deuxièmement, en C++, on peut avoir des fonctions templatées aussi, et non seulement des classes, et enfin (et surtout), le compilateur peut déduire lui-même les paramètres d'une fonction templatée.
Et évidemment, on peut aussi faire des spécialisations explicites.
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. Et du moment qu'on peut calculer, ou même faire des décisions simple, c'est plus qu'un simple commodité syntaxique.
Considère un exemple simple : tu veux déclarer un buffer assez grand pour contenir des chiffres générés par la conversion d'un int en décimal. D'une façon portable -- c'est clair que sous Windows, la réponse est 11 (10 chiffres plus la signe), mais toutes les machines n'ont pas des int de 32 bits. En C++ moderne, tu utilises la template suivante :
template< size_t N > struct MaxDigits { static size_t const value = 1 + MaxDigits< N / 10 >::value ; } ;
instantié sur INT_MAX (ou SHRT_MAX, ou ta valeur maximum, n'importe ce qu'elle est), ainsi : char buffer[ MaxDigits< INT_MAX >::value ] ; Évidemment, tu peux faire la calcule à la main, et puis y écrire la valeur voulue. Mais il ne faut pas oublier de le faire de nouveau chaque fois tu passes à une autre machine.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
