j'ai entendu que les jeux videos de nos jours, sont toujours concu en c
et non en c++,
ma quesiton est POUrquoi??, le c++ a quand meme beaucoup plus d'avantage
que le c non
merci
Ps: ceci n'est pas un troll; je suis en premiere année informatique, et
je commence a apprendre le c++, et les differences du c, et etant
passionné de jeu (c'est la dedans que j'aimerais travailler) je me
posait cette question
a écrit dans le message de news: 3f81312e$0$28911$
amerio wrote:
T'as intérêt à aimer les maths :-)
Pourquoi ?
Dans les jeux, il y pas mal de maths, et notamment d'opérations sur les vecteurs, dans un moteur 3D par exemple...
Vrai, et pas QUE dans le moteur 3D...
Mais c'est vrai que ce ne sont pas des maths *très haut niveau*, comme Gaby en a fait ;-)
Tros gros, passeras pas (tient, si, il passe !) Alors, là, s'il est vrai que l'Algèbre Lineaire, qui constitue un bon 80% des besoins en
maths d'un programmeur de jeu est de loin beaucoup plus facile que la maîtrises des
espaces de Minkowski (par ex.), il ne faut pas oublier les (assez récentes) additions que
sont par exemple : les systèmes d'équation sur-contraints (ex : physiques des chocs),
l'application du calcul des Harmoniques Sphériques (d'habitude, ca sert au calcul des
orbitales electroniques, mais on s'en sert pour les simulations d'eclairages globales,
dans Half Life 2 par ex.), la modélisation booléene (ou CSG, loin d'être triviale pour
être temps réel), les automates à logique floue ou les réseaux de neurones ou les algo
biologiques, etc. (mon but n'est pas d'etaler ma confiture ;-> mais bien de montrer que
les maths dans un jeu ne se résument _plus_ à matrice*vecteur...)
Le département R&D des sociétés de jeux vidéos n'existe pas pour rien. Mais en générale, c'est plutôt la recherche public qui avance dans ce domaine, et le privée qui l'utilise tout fait, en version simplifié, utilisable en temps réel
C'est une vision qui risque de choquer les chercheurs americains, qui travaillent essenciellement pour des societes privees (c'est aussi valable pour les universitaires us qui sont particulierement bien subventionnes par les societes privees) Mais il est vrai aussi que nos recherches publiques ne produisent pas assez de resultats appliques (je veux dire par la que les societes privees nationnales ont tendance a ne pas toujours voir le cote applicatif des recherches) Mais cela devient une question politique et non plus une question C++.
Fred
<antrax@ifrance.Com> a écrit dans le message de news:
3f81312e$0$28911$626a54ce@news.free.fr...
amerio wrote:
T'as intérêt à aimer les maths :-)
Pourquoi ?
Dans les jeux, il y pas mal de maths, et notamment d'opérations sur les
vecteurs, dans un moteur 3D par exemple...
Vrai, et pas QUE dans le moteur 3D...
Mais c'est vrai que ce ne sont
pas des maths *très haut niveau*, comme Gaby en a fait ;-)
Tros gros, passeras pas
(tient, si, il passe !)
Alors, là, s'il est vrai que l'Algèbre Lineaire, qui constitue un bon
80% des besoins en
maths d'un programmeur de jeu est de loin beaucoup plus facile que la
maîtrises des
espaces de Minkowski (par ex.), il ne faut pas oublier les (assez
récentes) additions que
sont par exemple : les systèmes d'équation sur-contraints (ex :
physiques des chocs),
l'application du calcul des Harmoniques Sphériques (d'habitude, ca sert
au calcul des
orbitales electroniques, mais on s'en sert pour les simulations
d'eclairages globales,
dans Half Life 2 par ex.), la modélisation booléene (ou CSG, loin d'être
triviale pour
être temps réel), les automates à logique floue ou les réseaux de
neurones ou les algo
biologiques, etc. (mon but n'est pas d'etaler ma confiture ;-> mais bien
de montrer que
les maths dans un jeu ne se résument _plus_ à matrice*vecteur...)
Le département R&D des sociétés de jeux vidéos n'existe pas pour rien.
Mais en générale, c'est plutôt la recherche public qui avance dans ce
domaine, et le privée qui l'utilise tout fait, en version simplifié,
utilisable en temps réel
C'est une vision qui risque de choquer les chercheurs americains, qui
travaillent essenciellement pour des societes privees (c'est aussi valable
pour les universitaires us qui sont particulierement bien subventionnes par
les societes privees)
Mais il est vrai aussi que nos recherches publiques ne produisent pas assez
de resultats appliques (je veux dire par la que les societes privees
nationnales ont tendance a ne pas toujours voir le cote applicatif des
recherches)
Mais cela devient une question politique et non plus une question C++.
a écrit dans le message de news: 3f81312e$0$28911$
amerio wrote:
T'as intérêt à aimer les maths :-)
Pourquoi ?
Dans les jeux, il y pas mal de maths, et notamment d'opérations sur les vecteurs, dans un moteur 3D par exemple...
Vrai, et pas QUE dans le moteur 3D...
Mais c'est vrai que ce ne sont pas des maths *très haut niveau*, comme Gaby en a fait ;-)
Tros gros, passeras pas (tient, si, il passe !) Alors, là, s'il est vrai que l'Algèbre Lineaire, qui constitue un bon 80% des besoins en
maths d'un programmeur de jeu est de loin beaucoup plus facile que la maîtrises des
espaces de Minkowski (par ex.), il ne faut pas oublier les (assez récentes) additions que
sont par exemple : les systèmes d'équation sur-contraints (ex : physiques des chocs),
l'application du calcul des Harmoniques Sphériques (d'habitude, ca sert au calcul des
orbitales electroniques, mais on s'en sert pour les simulations d'eclairages globales,
dans Half Life 2 par ex.), la modélisation booléene (ou CSG, loin d'être triviale pour
être temps réel), les automates à logique floue ou les réseaux de neurones ou les algo
biologiques, etc. (mon but n'est pas d'etaler ma confiture ;-> mais bien de montrer que
les maths dans un jeu ne se résument _plus_ à matrice*vecteur...)
Le département R&D des sociétés de jeux vidéos n'existe pas pour rien. Mais en générale, c'est plutôt la recherche public qui avance dans ce domaine, et le privée qui l'utilise tout fait, en version simplifié, utilisable en temps réel
C'est une vision qui risque de choquer les chercheurs americains, qui travaillent essenciellement pour des societes privees (c'est aussi valable pour les universitaires us qui sont particulierement bien subventionnes par les societes privees) Mais il est vrai aussi que nos recherches publiques ne produisent pas assez de resultats appliques (je veux dire par la que les societes privees nationnales ont tendance a ne pas toujours voir le cote applicatif des recherches) Mais cela devient une question politique et non plus une question C++.
Fred
Fred
"Fabien LE LEZ" a écrit dans le message de news:
On Sun, 05 Oct 2003 20:10:58 +0200, ricky wrote:
les routines internes sont plutot ecrites en c
Tu as l'air de sous-entendre que le C serait plus rapide que le C++. Ça me paraît passablement douteux. Pour avoir des résultats sûr, il faudrait bien sûr des tests sur la machine concernée, mais je ne vois pas pourquoi un accès à un std::vector<> serait plus lent qu'un accès à un tableau C, ou qu'un appel à void f (MaStructure*, int); serait plus lent qu'un appel à void MaStructure::f (int);
Mais
char* monBeauTableau=new char[2];
C'est du C++
et
void f (MaStructure*, int);
C'est aussi du C++
Fred
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
s9r0ov83kg303moi5i7clf2uomts6fubtm@4ax.com...
On Sun, 05 Oct 2003 20:10:58 +0200, ricky <eric_nyme@yahoo.fr> wrote:
les routines internes sont plutot ecrites en c
Tu as l'air de sous-entendre que le C serait plus rapide que le C++.
Ça me paraît passablement douteux. Pour avoir des résultats sûr, il
faudrait bien sûr des tests sur la machine concernée, mais je ne vois
pas pourquoi un accès à un std::vector<> serait plus lent qu'un accès
à un tableau C, ou qu'un appel à
void f (MaStructure*, int);
serait plus lent qu'un appel à
void MaStructure::f (int);
Tu as l'air de sous-entendre que le C serait plus rapide que le C++. Ça me paraît passablement douteux. Pour avoir des résultats sûr, il faudrait bien sûr des tests sur la machine concernée, mais je ne vois pas pourquoi un accès à un std::vector<> serait plus lent qu'un accès à un tableau C, ou qu'un appel à void f (MaStructure*, int); serait plus lent qu'un appel à void MaStructure::f (int);
Mais
char* monBeauTableau=new char[2];
C'est du C++
et
void f (MaStructure*, int);
C'est aussi du C++
Fred
Marc Boyer
Richard Delorme wrote:
Bien sûr un programme C compatible C++ fonctionne à la même vitesse que le compilateur soit en mode C ou C++. Néanmoins les approches offertes par le C++, comme la programmation objet, générique,... peuvent conduire à un programme légèrement plus lent,
Heuh... En quoi la généricité rendrait-elle plus lent ? Quand à l'objet, je vois pas non plus pourquoi il serait plus lent (à moins de, comme aiment à le faire certains en découvrant C++, d'ajouter du virtual partout).
ou consommant plus de mémoire, qu'un programme écrit uniquement dans le style programmation structurée du C. En plus, le système est souvent (Unix + X11, Windows, openGL, ...) écrit en C à la base, et l'utilisation du C++ invite à écrire une surcouche objet dessus qui introduit un peu de lenteur.
Hum... La encore, je demande à voir pourquoi une surcouche objet introduirait quoi que ce soit de lenteur.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Richard Delorme wrote:
Bien sûr un programme C compatible C++ fonctionne à la même vitesse que le
compilateur soit en mode C ou C++. Néanmoins les approches offertes par le
C++, comme la programmation objet, générique,... peuvent conduire à un
programme légèrement plus lent,
Heuh... En quoi la généricité rendrait-elle plus lent ?
Quand à l'objet, je vois pas non plus pourquoi il serait
plus lent (à moins de, comme aiment à le faire certains
en découvrant C++, d'ajouter du virtual partout).
ou consommant plus de mémoire, qu'un
programme écrit uniquement dans le style programmation structurée du C. En
plus, le système est souvent (Unix + X11, Windows, openGL, ...) écrit en C
à la base, et l'utilisation du C++ invite à écrire une surcouche objet
dessus qui introduit un peu de lenteur.
Hum... La encore, je demande à voir pourquoi une surcouche objet
introduirait quoi que ce soit de lenteur.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Bien sûr un programme C compatible C++ fonctionne à la même vitesse que le compilateur soit en mode C ou C++. Néanmoins les approches offertes par le C++, comme la programmation objet, générique,... peuvent conduire à un programme légèrement plus lent,
Heuh... En quoi la généricité rendrait-elle plus lent ? Quand à l'objet, je vois pas non plus pourquoi il serait plus lent (à moins de, comme aiment à le faire certains en découvrant C++, d'ajouter du virtual partout).
ou consommant plus de mémoire, qu'un programme écrit uniquement dans le style programmation structurée du C. En plus, le système est souvent (Unix + X11, Windows, openGL, ...) écrit en C à la base, et l'utilisation du C++ invite à écrire une surcouche objet dessus qui introduit un peu de lenteur.
Hum... La encore, je demande à voir pourquoi une surcouche objet introduirait quoi que ce soit de lenteur.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Luc Hermitte
Richard Delorme wrote in news:3f814650$0$20944$:
Bien sûr un programme C compatible C++ fonctionne à la même vitesse que le compilateur soit en mode C ou C++. Néanmoins les approches offertes par le C++, comme la programmation objet, générique,... peuvent conduire à un programme légèrement plus lent, ou consommant plus de mémoire, qu'un programme écrit uniquement dans le style programmation structurée du C.
Cela est loin d'être évident. P.ex. std::sort est plus performant que qsort. Pourquoi ? Parce que les templates permettent un "inlining" là où le C réalise des indirections via des pointeurs sur fonctions. Après, bien sûr le code peut être dupliqué pour chaque instanciation différente d'une classe template ce qui conduit à un exécutable plus gros.
Le draft sur la performance du C++ est vraiment très interressant.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Richard Delorme <abulmo@nospam.fr> wrote in
news:3f814650$0$20944$7a628cd7@news.club-internet.fr:
Bien sûr un programme C compatible C++ fonctionne à la même vitesse
que le compilateur soit en mode C ou C++. Néanmoins les approches
offertes par le C++, comme la programmation objet, générique,...
peuvent conduire à un programme légèrement plus lent, ou consommant
plus de mémoire, qu'un programme écrit uniquement dans le style
programmation structurée du C.
Cela est loin d'être évident. P.ex. std::sort est plus performant que
qsort. Pourquoi ? Parce que les templates permettent un "inlining" là où le
C réalise des indirections via des pointeurs sur fonctions.
Après, bien sûr le code peut être dupliqué pour chaque instanciation
différente d'une classe template ce qui conduit à un exécutable plus gros.
Le draft sur la performance du C++ est vraiment très interressant.
--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>
Bien sûr un programme C compatible C++ fonctionne à la même vitesse que le compilateur soit en mode C ou C++. Néanmoins les approches offertes par le C++, comme la programmation objet, générique,... peuvent conduire à un programme légèrement plus lent, ou consommant plus de mémoire, qu'un programme écrit uniquement dans le style programmation structurée du C.
Cela est loin d'être évident. P.ex. std::sort est plus performant que qsort. Pourquoi ? Parce que les templates permettent un "inlining" là où le C réalise des indirections via des pointeurs sur fonctions. Après, bien sûr le code peut être dupliqué pour chaque instanciation différente d'une classe template ce qui conduit à un exécutable plus gros.
Le draft sur la performance du C++ est vraiment très interressant.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
Mickael Pointier
bonjour,
j'ai entendu que les jeux videos de nos jours, sont toujours concu en c et non en c++,
[Note: quand j'écrit C dans ce qui suit, je veux dire que ca compile avec un compilo C, même si ca à l'extension CPP... et quand j'écrit C++ ca veut dire que les fonctionnalités propre au C++ sont utilisées (références, templates, classes, dérivation, etc...)]
J'aurais tendance à dire que c'est faux. Même certains jeux GameBoy Advance sont écrits en C++.
Si je prend par exemple les jeux développés à Eden Studios: 1999: VRally 2 (PSX), VRally 1 (N64) => C 2000: VRally 2 (PC/DreamCast), NFS (PSX) => C 2002: VRally 3 (PS2) => 80% C & 20% C++ 2003: Kya (PS2) => 90% C++
Les % c'est parce que nous avons pas mal de librairies, donc certaines sont encore en C.
A priori tous les prochains jeux seront en C++ intégralement.
ma quesiton est POUrquoi??, le c++ a quand meme beaucoup plus d'avantage que le c non
J'y vois plusieurs raisons: 1) Une légende qui veut que le C++ soit plus lent que le C 2) Des compilateurs C++ sur console qui ont été très longtemps completement à la rue.
Même si j'avais voulu faire VR2 DreamCast en C++, je n'aurais pas pu, bettement parce que les deux seuls compilateurs C++ capable de générer du code SH4 à l'époque étaient GCC et CodeWarrior. Manque de bol GCC était plus une version SH3E+ qu'une version SH4, donc les optimisations étaient pathétiques, les instructions spécifiques non implémentées, et les bugs de génération de code je ne les compte même pas... quand à CodeWarrior dreamcast, il faut mieux ne pas en parler...
Ne pas faire de C++ sur PC serait une grosse erreur, les compilos existent depuis longtemps. Par contre sur console, la durée de vie des machines est courte, donc les compilos sont toujours très neufs.
Mickael Pointier
bonjour,
j'ai entendu que les jeux videos de nos jours, sont toujours concu en
c et non en c++,
[Note: quand j'écrit C dans ce qui suit, je veux dire que ca compile
avec un compilo C, même si ca à l'extension CPP... et quand j'écrit C++
ca veut dire que les fonctionnalités propre au C++ sont utilisées
(références, templates, classes, dérivation, etc...)]
J'aurais tendance à dire que c'est faux.
Même certains jeux GameBoy Advance sont écrits en C++.
Si je prend par exemple les jeux développés à Eden Studios:
1999: VRally 2 (PSX), VRally 1 (N64) => C
2000: VRally 2 (PC/DreamCast), NFS (PSX) => C
2002: VRally 3 (PS2) => 80% C & 20% C++
2003: Kya (PS2) => 90% C++
Les % c'est parce que nous avons pas mal de librairies, donc certaines
sont encore en C.
A priori tous les prochains jeux seront en C++ intégralement.
ma quesiton est POUrquoi??, le c++ a quand meme beaucoup plus
d'avantage que le c non
J'y vois plusieurs raisons:
1) Une légende qui veut que le C++ soit plus lent que le C
2) Des compilateurs C++ sur console qui ont été très longtemps
completement à la rue.
Même si j'avais voulu faire VR2 DreamCast en C++, je n'aurais pas pu,
bettement parce que les deux seuls compilateurs C++ capable de générer
du code SH4 à l'époque étaient GCC et CodeWarrior. Manque de bol GCC
était plus une version SH3E+ qu'une version SH4, donc les optimisations
étaient pathétiques, les instructions spécifiques non implémentées, et
les bugs de génération de code je ne les compte même pas... quand à
CodeWarrior dreamcast, il faut mieux ne pas en parler...
Ne pas faire de C++ sur PC serait une grosse erreur, les compilos
existent depuis longtemps. Par contre sur console, la durée de vie des
machines est courte, donc les compilos sont toujours très neufs.
j'ai entendu que les jeux videos de nos jours, sont toujours concu en c et non en c++,
[Note: quand j'écrit C dans ce qui suit, je veux dire que ca compile avec un compilo C, même si ca à l'extension CPP... et quand j'écrit C++ ca veut dire que les fonctionnalités propre au C++ sont utilisées (références, templates, classes, dérivation, etc...)]
J'aurais tendance à dire que c'est faux. Même certains jeux GameBoy Advance sont écrits en C++.
Si je prend par exemple les jeux développés à Eden Studios: 1999: VRally 2 (PSX), VRally 1 (N64) => C 2000: VRally 2 (PC/DreamCast), NFS (PSX) => C 2002: VRally 3 (PS2) => 80% C & 20% C++ 2003: Kya (PS2) => 90% C++
Les % c'est parce que nous avons pas mal de librairies, donc certaines sont encore en C.
A priori tous les prochains jeux seront en C++ intégralement.
ma quesiton est POUrquoi??, le c++ a quand meme beaucoup plus d'avantage que le c non
J'y vois plusieurs raisons: 1) Une légende qui veut que le C++ soit plus lent que le C 2) Des compilateurs C++ sur console qui ont été très longtemps completement à la rue.
Même si j'avais voulu faire VR2 DreamCast en C++, je n'aurais pas pu, bettement parce que les deux seuls compilateurs C++ capable de générer du code SH4 à l'époque étaient GCC et CodeWarrior. Manque de bol GCC était plus une version SH3E+ qu'une version SH4, donc les optimisations étaient pathétiques, les instructions spécifiques non implémentées, et les bugs de génération de code je ne les compte même pas... quand à CodeWarrior dreamcast, il faut mieux ne pas en parler...
Ne pas faire de C++ sur PC serait une grosse erreur, les compilos existent depuis longtemps. Par contre sur console, la durée de vie des machines est courte, donc les compilos sont toujours très neufs.
Mickael Pointier
Mickael Pointier
j'ai entendu que les jeux videos de nos jours, sont toujours concu en c et non en c++, [...]
Le C est plutôt utilisé sur PS2. Les moteurs les plus performants sont écrits en C, c'est un fait.
Pourrais tu donner tes sources ?
D'expérience j'aurais tendance à dire l'inverse sur tes deux affirmations.
Mickael Pointier
j'ai entendu que les jeux videos de nos jours, sont toujours concu en
c et non en c++,
[...]
Le C est plutôt utilisé sur PS2.
Les moteurs les plus performants sont écrits en C, c'est un fait.
Pourrais tu donner tes sources ?
D'expérience j'aurais tendance à dire l'inverse sur tes deux
affirmations.
j'ai entendu que les jeux videos de nos jours, sont toujours concu en c et non en c++, [...]
Le C est plutôt utilisé sur PS2. Les moteurs les plus performants sont écrits en C, c'est un fait.
Pourrais tu donner tes sources ?
D'expérience j'aurais tendance à dire l'inverse sur tes deux affirmations.
Mickael Pointier
Fabien LE LEZ
On Mon, 6 Oct 2003 13:55:52 +0200, "Fred" wrote:
char* monBeauTableau=new char[2];
C'est du C++
Sans doute. Mais c'est une structure rarement utilisée. En fait, il m'arrive d'allouer des objets directement par new, mais je ne sais pas si new[] a réellement une utilité.
On Mon, 6 Oct 2003 13:55:52 +0200, "Fred" <no.spam@spam.no> wrote:
char* monBeauTableau=new char[2];
C'est du C++
Sans doute. Mais c'est une structure rarement utilisée.
En fait, il m'arrive d'allouer des objets directement par new, mais je
ne sais pas si new[] a réellement une utilité.
Sans doute. Mais c'est une structure rarement utilisée. En fait, il m'arrive d'allouer des objets directement par new, mais je ne sais pas si new[] a réellement une utilité.
Sans doute. Mais c'est une structure rarement utilisée. En fait, il m'arrive d'allouer des objets directement par new, mais je ne sais pas si new[] a réellement une utilité.
Ca permet toutefois de creer un tableau "a la C" et de pouvoir
l'exploiter dans des fonctions "C" et donc offrir une interface C++-C ou C->C++. Ce qui peut etre utile pour ouvrir une bibliotheque C++ au C ou exploiter une bibliotheque C en C++ ... Mais en dehors de ca je vois pas l'interet vu que dans ces deux cas on pourrait se tourner vers calloc afin d'eviter certains soucis (?)
-- Frederic Py
Fabien LE LEZ said on 10/06/03 14:33:
On Mon, 6 Oct 2003 13:55:52 +0200, "Fred" <no.spam@spam.no> wrote:
char* monBeauTableau=new char[2];
C'est du C++
Sans doute. Mais c'est une structure rarement utilisée.
En fait, il m'arrive d'allouer des objets directement par new, mais je
ne sais pas si new[] a réellement une utilité.
Ca permet toutefois de creer un tableau "a la C" et de pouvoir
l'exploiter dans des fonctions "C" et donc offrir une interface C++-C ou
C->C++. Ce qui peut etre utile pour ouvrir une bibliotheque C++ au C ou
exploiter une bibliotheque C en C++ ... Mais en dehors de ca je vois pas
l'interet vu que dans ces deux cas on pourrait se tourner vers calloc
afin d'eviter certains soucis (?)
Sans doute. Mais c'est une structure rarement utilisée. En fait, il m'arrive d'allouer des objets directement par new, mais je ne sais pas si new[] a réellement une utilité.
Ca permet toutefois de creer un tableau "a la C" et de pouvoir
l'exploiter dans des fonctions "C" et donc offrir une interface C++-C ou C->C++. Ce qui peut etre utile pour ouvrir une bibliotheque C++ au C ou exploiter une bibliotheque C en C++ ... Mais en dehors de ca je vois pas l'interet vu que dans ces deux cas on pourrait se tourner vers calloc afin d'eviter certains soucis (?)
-- Frederic Py
Fabien LE LEZ
On Mon, 06 Oct 2003 14:39:02 +0200, Frederic Py wrote:
Sans doute. Mais c'est une structure rarement utilisée. En fait, il m'arrive d'allouer des objets directement par new, mais je ne sais pas si new[] a réellement une utilité.
Ca permet toutefois de creer un tableau "a la C" et de pouvoir
l'exploiter dans des fonctions "C" et donc offrir une interface C++-C ou C->C++.
S'il s'agit d'appeler une fonction C qui s'attend à un "char*", std::vector<char> fonctionne très bien (&v[0]).
On Mon, 06 Oct 2003 14:39:02 +0200, Frederic Py <fpy.nospam@laas.rf>
wrote:
Sans doute. Mais c'est une structure rarement utilisée.
En fait, il m'arrive d'allouer des objets directement par new, mais je
ne sais pas si new[] a réellement une utilité.
Ca permet toutefois de creer un tableau "a la C" et de pouvoir
l'exploiter dans des fonctions "C" et donc offrir une interface C++-C ou
C->C++.
S'il s'agit d'appeler une fonction C qui s'attend à un "char*",
std::vector<char> fonctionne très bien (&v[0]).
On Mon, 06 Oct 2003 14:39:02 +0200, Frederic Py wrote:
Sans doute. Mais c'est une structure rarement utilisée. En fait, il m'arrive d'allouer des objets directement par new, mais je ne sais pas si new[] a réellement une utilité.
Ca permet toutefois de creer un tableau "a la C" et de pouvoir
l'exploiter dans des fonctions "C" et donc offrir une interface C++-C ou C->C++.
S'il s'agit d'appeler une fonction C qui s'attend à un "char*", std::vector<char> fonctionne très bien (&v[0]).
"Frederic Py" a écrit dans le message de news: blrnp6$sra$
Fabien LE LEZ said on 10/06/03 14:33:
On Mon, 6 Oct 2003 13:55:52 +0200, "Fred" wrote:
char* monBeauTableau=new char[2];
C'est du C++
Sans doute. Mais c'est une structure rarement utilisée. En fait, il m'arrive d'allouer des objets directement par new, mais je ne sais pas si new[] a réellement une utilité.
Ca permet toutefois de creer un tableau "a la C" et de pouvoir
l'exploiter dans des fonctions "C" et donc offrir une interface C++-C ou C->C++. Ce qui peut etre utile pour ouvrir une bibliotheque C++ au C ou exploiter une bibliotheque C en C++ ... Mais en dehors de ca je vois pas l'interet vu que dans ces deux cas on pourrait se tourner vers calloc afin d'eviter certains soucis (?)
Tu pourrais preciser?
-- Frederic Py
"Frederic Py" <fpy.nospam@laas.rf> a écrit dans le message de news:
blrnp6$sra$1@kane.laas.fr...
Fabien LE LEZ said on 10/06/03 14:33:
On Mon, 6 Oct 2003 13:55:52 +0200, "Fred" <no.spam@spam.no> wrote:
char* monBeauTableau=new char[2];
C'est du C++
Sans doute. Mais c'est une structure rarement utilisée.
En fait, il m'arrive d'allouer des objets directement par new, mais je
ne sais pas si new[] a réellement une utilité.
Ca permet toutefois de creer un tableau "a la C" et de pouvoir
l'exploiter dans des fonctions "C" et donc offrir une interface C++-C ou
C->C++. Ce qui peut etre utile pour ouvrir une bibliotheque C++ au C ou
exploiter une bibliotheque C en C++ ... Mais en dehors de ca je vois pas
l'interet vu que dans ces deux cas on pourrait se tourner vers calloc
afin d'eviter certains soucis (?)
"Frederic Py" a écrit dans le message de news: blrnp6$sra$
Fabien LE LEZ said on 10/06/03 14:33:
On Mon, 6 Oct 2003 13:55:52 +0200, "Fred" wrote:
char* monBeauTableau=new char[2];
C'est du C++
Sans doute. Mais c'est une structure rarement utilisée. En fait, il m'arrive d'allouer des objets directement par new, mais je ne sais pas si new[] a réellement une utilité.
Ca permet toutefois de creer un tableau "a la C" et de pouvoir
l'exploiter dans des fonctions "C" et donc offrir une interface C++-C ou C->C++. Ce qui peut etre utile pour ouvrir une bibliotheque C++ au C ou exploiter une bibliotheque C en C++ ... Mais en dehors de ca je vois pas l'interet vu que dans ces deux cas on pourrait se tourner vers calloc afin d'eviter certains soucis (?)
