J'ai aussi entendu parler de ogre3d qui est un wrapper dx/ogl totalement orientée objet ou du moins m'en inspirer grandement.
Ogre est un moteur de jeu 3D, c'est différent. Enfin cela peut correspondre à tes besoins.
Fabien LE LEZ
On Sun, 18 Dec 2005 16:01:22 +0100, loufoque :
On peut choisir de l'utiliser tel quel ou utiliser un wrapper C++ qui sera plus orienté objet.
Je me vois mal utiliser directement une bibliothèque en C dans un programme en C++. De toutes façons, il faudra un wrapper, quitte à l'écrire soi-même.
On Sun, 18 Dec 2005 16:01:22 +0100, loufoque
<loufoque@remove.gmail.com>:
On peut choisir de l'utiliser tel quel ou utiliser un wrapper C++ qui
sera plus orienté objet.
Je me vois mal utiliser directement une bibliothèque en C dans un
programme en C++. De toutes façons, il faudra un wrapper, quitte à
l'écrire soi-même.
On peut choisir de l'utiliser tel quel ou utiliser un wrapper C++ qui sera plus orienté objet.
Je me vois mal utiliser directement une bibliothèque en C dans un programme en C++. De toutes façons, il faudra un wrapper, quitte à l'écrire soi-même.
James Kanze
Fabien LE LEZ wrote:
On Sun, 18 Dec 2005 00:56:44 +0100, Averroes :
Le plus grand avantage du java est la programmation objet, la rapidité de programmation et surtout le framework enorme de sun.
Euh... ça fait trois.
Pour le framework, je veux bien. Il est vrai que la relation du programmeur avec les bibliothèques doit être assez différente en C++ et en Java.
Pour la rapidité de programmation, j'ai des doutes. C'est surtout qu'on n'utilisera pas forcément C++ et Java pour le même type de programmes. À chaque langage ses applications.
Si le but est d'écrire un programme qui se compile et qui ne provoque pas de core dump, on y arrive bien plus vite en Java qu'en C++. Si les exigences de correction dépasse simplement « ne pas faire de core dump », c'est moins évident.
Mais pour la "programmation objet", je ne vois pas bien en quoi Java a l'avantage sur C++. À part peut-être que (AFAIK) Java a tendance à imposer un paradigme, alors que C++ laisse le choix au programmeur.
Il y a autant de définitions de « programmation objet » qu'il y a des programmeurs qui la pratiquent. Selon la définition de certains (et y compris la définition que je trouve le plus utile), c'est impossible de faire de la programmation objet en Java. En fait, le Java impose non seulement la programmation objet (y compris quand il ne convient pas), mais SA définition de la programmation objet, qui n'est peut être pas TA définition, ou la définition qui convient à l'application en question. (En fait, d'après mon expérience -- et ça n'engage que moi -- la définition imposée par Java convient assez bien pour des programmes d'affichage pûr, mais pas pour grand chose d'autre.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Sun, 18 Dec 2005 00:56:44 +0100, Averroes
<averroes@no_where.com>:
Le plus grand avantage du java est la programmation objet, la
rapidité de programmation et surtout le framework enorme de
sun.
Euh... ça fait trois.
Pour le framework, je veux bien. Il est vrai que la relation
du programmeur avec les bibliothèques doit être assez
différente en C++ et en Java.
Pour la rapidité de programmation, j'ai des doutes. C'est
surtout qu'on n'utilisera pas forcément C++ et Java pour le
même type de programmes. À chaque langage ses applications.
Si le but est d'écrire un programme qui se compile et qui ne
provoque pas de core dump, on y arrive bien plus vite en Java
qu'en C++. Si les exigences de correction dépasse simplement
« ne pas faire de core dump », c'est moins évident.
Mais pour la "programmation objet", je ne vois pas bien en
quoi Java a l'avantage sur C++. À part peut-être que (AFAIK)
Java a tendance à imposer un paradigme, alors que C++ laisse
le choix au programmeur.
Il y a autant de définitions de « programmation objet » qu'il y
a des programmeurs qui la pratiquent. Selon la définition de
certains (et y compris la définition que je trouve le plus
utile), c'est impossible de faire de la programmation objet en
Java. En fait, le Java impose non seulement la programmation
objet (y compris quand il ne convient pas), mais SA définition
de la programmation objet, qui n'est peut être pas TA
définition, ou la définition qui convient à l'application en
question. (En fait, d'après mon expérience -- et ça n'engage que
moi -- la définition imposée par Java convient assez bien pour
des programmes d'affichage pûr, mais pas pour grand chose
d'autre.)
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Le plus grand avantage du java est la programmation objet, la rapidité de programmation et surtout le framework enorme de sun.
Euh... ça fait trois.
Pour le framework, je veux bien. Il est vrai que la relation du programmeur avec les bibliothèques doit être assez différente en C++ et en Java.
Pour la rapidité de programmation, j'ai des doutes. C'est surtout qu'on n'utilisera pas forcément C++ et Java pour le même type de programmes. À chaque langage ses applications.
Si le but est d'écrire un programme qui se compile et qui ne provoque pas de core dump, on y arrive bien plus vite en Java qu'en C++. Si les exigences de correction dépasse simplement « ne pas faire de core dump », c'est moins évident.
Mais pour la "programmation objet", je ne vois pas bien en quoi Java a l'avantage sur C++. À part peut-être que (AFAIK) Java a tendance à imposer un paradigme, alors que C++ laisse le choix au programmeur.
Il y a autant de définitions de « programmation objet » qu'il y a des programmeurs qui la pratiquent. Selon la définition de certains (et y compris la définition que je trouve le plus utile), c'est impossible de faire de la programmation objet en Java. En fait, le Java impose non seulement la programmation objet (y compris quand il ne convient pas), mais SA définition de la programmation objet, qui n'est peut être pas TA définition, ou la définition qui convient à l'application en question. (En fait, d'après mon expérience -- et ça n'engage que moi -- la définition imposée par Java convient assez bien pour des programmes d'affichage pûr, mais pas pour grand chose d'autre.)
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
"Apprendre Java et C++ en parallèle", par Jean Bernard Boichat.
Deux chapitres sont disponibles en téléchargement : 1 et 9.
Le chapitre 1 me paraît un peu bordélique, mais je suppose qu'il est toujours difficile d'écrire une introduction à un langage (ou deux).
J'y ai relevé une perle : "Avec un int main() en C++, il est nécessaire de retourner une valeur qu'il est judicieux de définir négativement en cas d'erreur."
Passons sur le "nécessaire" erroné ; mais quelqu'un pourrait-il m'expliquer ce que signifie le "négativement" ici ? :-/
Que la valeur doit être négative ? Mais alors, on effreint aux conventions de Unix, au moins.
Dans le code portable, il y a EXIT_SUCCESS et EXIT_FAILURE. Et c'est quasiment tout. Dans le code moins portable, il convient à s'aligner sur les conventions du système : sous Unix, par exemple, un entier entre 0 et 127. (En passant, les conventions d'Unix marchait assez bien sous MS-DOS. Je ne sais pas ce qu'il en est pour Windows.)
Est-ce qu'on pourrait dire que c'est carrément faux ?
Dans le chapitre 9 (qui traite des iostream), il ose proposer le code suivant :
Un comble pour un livre dont on aurait pû penser qu'il éviterait les ornières du C, alors même qu'il donne, quelques lignes plus loin, une version Java correcte :-/
La première question serait peut-être sur la date de publication.
Pas que ça change grand chose. Avant la disponibilité de std::string, on utilisait sa propre classe de string.
À noter que le PDF disponible en téléchargement doit être un brouillon, et pas la version corrigée. On peut notamment y lire "librairie" à la place de "bibliothèque".
À noter aussi qu'il utilise des fonctions non portables (comme opendir()) sans trop prévenir qu'elles ne font pas partie du C++, et qu'il s'étend sur la syntaxe de sprintf, et qu'il a d'une manière générale une forte tendance à préférer char[] à std::string.
Le deuxième peut être un effet de l'âge, bien que comme je disais avant... Je ne me suis plus servi de char[] dans les programmes C++ depuis 1990. À une époque où je ne savais même pas qu'il y avait une norme C++ (ni un comité de normalisation).
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Sun, 18 Dec 2005 12:34:45 +0100, "ByB" <email@email.com>:
"Apprendre Java et C++ en parallèle", par Jean Bernard Boichat.
Deux chapitres sont disponibles en téléchargement : 1 et 9.
Le chapitre 1 me paraît un peu bordélique, mais je suppose
qu'il est toujours difficile d'écrire une introduction à un
langage (ou deux).
J'y ai relevé une perle :
"Avec un int main() en C++, il est nécessaire de retourner
une valeur qu'il est judicieux de définir négativement en
cas d'erreur."
Passons sur le "nécessaire" erroné ; mais quelqu'un
pourrait-il m'expliquer ce que signifie le "négativement" ici
? :-/
Que la valeur doit être négative ? Mais alors, on effreint aux
conventions de Unix, au moins.
Dans le code portable, il y a EXIT_SUCCESS et EXIT_FAILURE. Et
c'est quasiment tout. Dans le code moins portable, il convient à
s'aligner sur les conventions du système : sous Unix, par
exemple, un entier entre 0 et 127. (En passant, les conventions
d'Unix marchait assez bien sous MS-DOS. Je ne sais pas ce qu'il
en est pour Windows.)
Est-ce qu'on pourrait dire que c'est carrément faux ?
Dans le chapitre 9 (qui traite des iostream), il ose proposer
le code suivant :
Un comble pour un livre dont on aurait pû penser qu'il
éviterait les ornières du C, alors même qu'il donne, quelques
lignes plus loin, une version Java correcte :-/
La première question serait peut-être sur la date de
publication.
Pas que ça change grand chose. Avant la disponibilité de
std::string, on utilisait sa propre classe de string.
À noter que le PDF disponible en téléchargement doit être un
brouillon, et pas la version corrigée. On peut notamment y
lire "librairie" à la place de "bibliothèque".
À noter aussi qu'il utilise des fonctions non portables (comme
opendir()) sans trop prévenir qu'elles ne font pas partie du
C++, et qu'il s'étend sur la syntaxe de sprintf, et qu'il a
d'une manière générale une forte tendance à préférer char[] à
std::string.
Le deuxième peut être un effet de l'âge, bien que comme je
disais avant... Je ne me suis plus servi de char[] dans les
programmes C++ depuis 1990. À une époque où je ne savais même
pas qu'il y avait une norme C++ (ni un comité de normalisation).
--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
"Apprendre Java et C++ en parallèle", par Jean Bernard Boichat.
Deux chapitres sont disponibles en téléchargement : 1 et 9.
Le chapitre 1 me paraît un peu bordélique, mais je suppose qu'il est toujours difficile d'écrire une introduction à un langage (ou deux).
J'y ai relevé une perle : "Avec un int main() en C++, il est nécessaire de retourner une valeur qu'il est judicieux de définir négativement en cas d'erreur."
Passons sur le "nécessaire" erroné ; mais quelqu'un pourrait-il m'expliquer ce que signifie le "négativement" ici ? :-/
Que la valeur doit être négative ? Mais alors, on effreint aux conventions de Unix, au moins.
Dans le code portable, il y a EXIT_SUCCESS et EXIT_FAILURE. Et c'est quasiment tout. Dans le code moins portable, il convient à s'aligner sur les conventions du système : sous Unix, par exemple, un entier entre 0 et 127. (En passant, les conventions d'Unix marchait assez bien sous MS-DOS. Je ne sais pas ce qu'il en est pour Windows.)
Est-ce qu'on pourrait dire que c'est carrément faux ?
Dans le chapitre 9 (qui traite des iostream), il ose proposer le code suivant :
Un comble pour un livre dont on aurait pû penser qu'il éviterait les ornières du C, alors même qu'il donne, quelques lignes plus loin, une version Java correcte :-/
La première question serait peut-être sur la date de publication.
Pas que ça change grand chose. Avant la disponibilité de std::string, on utilisait sa propre classe de string.
À noter que le PDF disponible en téléchargement doit être un brouillon, et pas la version corrigée. On peut notamment y lire "librairie" à la place de "bibliothèque".
À noter aussi qu'il utilise des fonctions non portables (comme opendir()) sans trop prévenir qu'elles ne font pas partie du C++, et qu'il s'étend sur la syntaxe de sprintf, et qu'il a d'une manière générale une forte tendance à préférer char[] à std::string.
Le deuxième peut être un effet de l'âge, bien que comme je disais avant... Je ne me suis plus servi de char[] dans les programmes C++ depuis 1990. À une époque où je ne savais même pas qu'il y avait une norme C++ (ni un comité de normalisation).
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ
On Mon, 26 Dec 2005 22:27:55 +0100, James Kanze :
La première question serait peut-être sur la date de publication.
D'après l'éditeur : "Parution : 11/09/2003".
Le deuxième peut être un effet de l'âge
Ben non.
En plus, il me semble que std::string est au moins aussi vieux que Java, non ?
On Mon, 26 Dec 2005 22:27:55 +0100, James Kanze <kanze@none>:
La première question serait peut-être sur la date de
publication.
D'après l'éditeur : "Parution : 11/09/2003".
Le deuxième peut être un effet de l'âge
Ben non.
En plus, il me semble que std::string est au moins aussi vieux que
Java, non ?
La première question serait peut-être sur la date de publication.
D'après l'éditeur : "Parution : 11/09/2003".
Le deuxième peut être un effet de l'âge
Ben non.
En plus, il me semble que std::string est au moins aussi vieux que Java, non ?
kanze
Fabien LE LEZ wrote:
On Mon, 26 Dec 2005 22:27:55 +0100, James Kanze :
La première question serait peut-être sur la date de publication.
D'après l'éditeur : "Parution : 11/09/2003".
Le deuxième peut être un effet de l'âge
Ben non.
En plus, il me semble que std::string est au moins aussi vieux que Java, non ?
Il date très exactement du 1-9-1998. Comme toute la norme.
Il y a eu une proposition d'une classe string déjà depuis mes premiers contacts avec le comité -- 1992 ou 1993, si mes souvenirs sont exact. Une proposition qui s'est pas mal modifiée avec le temps -- la première version que j'ai vu n'était pas un template, par exemple, et l'addition de la fonction push_back et la spécification de la validité des références et des itérateurs sont une réaction aux commentaires (surtout du French National Body) au CD2.
Comme d'habitude, les implémentations réeles étaient à la traine. Pas autant que pour export, évidemment, mais il y a eu de la variation dans les implémentations jusqu'à une date assez récente.
L'écriture du texte en question précède forcément la date de parution ; de combien, nous n'en savons rien.
Ceci dit, vue les autres problèmes, je doute que ce soit la véritable raison pour l'absence de std::string. Mais l'absence en elle-même n'est pas forcément une indication d'un problème. L'utilisation de char[] à la place d'une classe, oui, mais selon la date où le texte a été écrit, cette classe ne serait pas forcément std::string.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Mon, 26 Dec 2005 22:27:55 +0100, James Kanze <kanze@none>:
La première question serait peut-être sur la date de
publication.
D'après l'éditeur : "Parution : 11/09/2003".
Le deuxième peut être un effet de l'âge
Ben non.
En plus, il me semble que std::string est au moins aussi vieux
que Java, non ?
Il date très exactement du 1-9-1998. Comme toute la norme.
Il y a eu une proposition d'une classe string déjà depuis mes
premiers contacts avec le comité -- 1992 ou 1993, si mes
souvenirs sont exact. Une proposition qui s'est pas mal modifiée
avec le temps -- la première version que j'ai vu n'était pas un
template, par exemple, et l'addition de la fonction push_back et
la spécification de la validité des références et des itérateurs
sont une réaction aux commentaires (surtout du French National
Body) au CD2.
Comme d'habitude, les implémentations réeles étaient à la
traine. Pas autant que pour export, évidemment, mais il y a eu
de la variation dans les implémentations jusqu'à une date assez
récente.
L'écriture du texte en question précède forcément la date de
parution ; de combien, nous n'en savons rien.
Ceci dit, vue les autres problèmes, je doute que ce soit la
véritable raison pour l'absence de std::string. Mais l'absence
en elle-même n'est pas forcément une indication d'un problème.
L'utilisation de char[] à la place d'une classe, oui, mais selon
la date où le texte a été écrit, cette classe ne serait pas
forcément std::string.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
La première question serait peut-être sur la date de publication.
D'après l'éditeur : "Parution : 11/09/2003".
Le deuxième peut être un effet de l'âge
Ben non.
En plus, il me semble que std::string est au moins aussi vieux que Java, non ?
Il date très exactement du 1-9-1998. Comme toute la norme.
Il y a eu une proposition d'une classe string déjà depuis mes premiers contacts avec le comité -- 1992 ou 1993, si mes souvenirs sont exact. Une proposition qui s'est pas mal modifiée avec le temps -- la première version que j'ai vu n'était pas un template, par exemple, et l'addition de la fonction push_back et la spécification de la validité des références et des itérateurs sont une réaction aux commentaires (surtout du French National Body) au CD2.
Comme d'habitude, les implémentations réeles étaient à la traine. Pas autant que pour export, évidemment, mais il y a eu de la variation dans les implémentations jusqu'à une date assez récente.
L'écriture du texte en question précède forcément la date de parution ; de combien, nous n'en savons rien.
Ceci dit, vue les autres problèmes, je doute que ce soit la véritable raison pour l'absence de std::string. Mais l'absence en elle-même n'est pas forcément une indication d'un problème. L'utilisation de char[] à la place d'une classe, oui, mais selon la date où le texte a été écrit, cette classe ne serait pas forcément std::string.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
