Personnellement, je réalise mes programmes avec DELPHI (langage Pascal de
BORLAND) où sont définis des "tableaux dynamiques". Ce sont des tableaux
dont on peut fixer la taille (le nombre d'éléments) à l'exécution.
J'utilise ce type de tableaux pour échanger des infos entre un programme et
des DLL.
Existe-t-il l'équivalent, pour ne pas dire la même chose, dans d'autres
langages, notamment le C++ de chez Microsoft.
Sinon, comment faites-vous pour échanger entre .exe et .dll quand vous ne
connaissez pas à la compilation la taille des infos à échanger ;le nombre de
pixels de l'image en cours de traitement par exemple.
c'est le cas, puisqu'il est dynamique dans le cas du malloc, il est créé à l'utilisation, pas à la compilation. le 'dynamique' tel que défini plus haut est redimensionnable
J'ai pas dit le contraire, mais je pense qu'il y a eu malentendu. A mon avis, quand on a besoin de créer un tableau de façon dynamique, ça veut dire que soit on n'en connaît la dimension fixe qu'au moment de le créer (i.e. pas à la compilation) et le malloc va bien, soit cette dimension varie au cours de l'application et la liste chaînée conviendra sans doute mieux que le realloc si ça varie souvent. Je préfère la liste chaînée à titre perso, mais je reste par nature adogmatique.
Un shéma de réallocation où l'on alloue plus que ce qui est demandé à chaque fois, et avec croissance géométrique a des chances d'être plus performant pour faire un tableau dynamique à la taille variant au cours de l'exécution qu'une liste chaînée (on est en O(1) amorti, et en accès direct et avec moins de mémoire allouée). C'est d'ailleur le comportement d'un std::vector en C++.
-- Loïc
Bertrand Lenoir-Welter wrote:
c'est le cas, puisqu'il est dynamique
dans le cas du malloc, il est créé à l'utilisation, pas à la compilation.
le 'dynamique' tel que défini plus haut est redimensionnable
J'ai pas dit le contraire, mais je pense qu'il y a eu malentendu. A mon
avis, quand on a besoin de créer un tableau de façon dynamique, ça veut
dire que soit on n'en connaît la dimension fixe qu'au moment de le créer
(i.e. pas à la compilation) et le malloc va bien, soit cette dimension
varie au cours de l'application et la liste chaînée conviendra sans
doute mieux que le realloc si ça varie souvent. Je préfère la liste
chaînée à titre perso, mais je reste par nature adogmatique.
Un shéma de réallocation où l'on alloue plus que ce qui est demandé à
chaque fois, et avec croissance géométrique a des chances d'être plus
performant pour faire un tableau dynamique à la taille variant au cours
de l'exécution qu'une liste chaînée (on est en O(1) amorti, et en accès
direct et avec moins de mémoire allouée). C'est d'ailleur le
comportement d'un std::vector en C++.
c'est le cas, puisqu'il est dynamique dans le cas du malloc, il est créé à l'utilisation, pas à la compilation. le 'dynamique' tel que défini plus haut est redimensionnable
J'ai pas dit le contraire, mais je pense qu'il y a eu malentendu. A mon avis, quand on a besoin de créer un tableau de façon dynamique, ça veut dire que soit on n'en connaît la dimension fixe qu'au moment de le créer (i.e. pas à la compilation) et le malloc va bien, soit cette dimension varie au cours de l'application et la liste chaînée conviendra sans doute mieux que le realloc si ça varie souvent. Je préfère la liste chaînée à titre perso, mais je reste par nature adogmatique.
Un shéma de réallocation où l'on alloue plus que ce qui est demandé à chaque fois, et avec croissance géométrique a des chances d'être plus performant pour faire un tableau dynamique à la taille variant au cours de l'exécution qu'une liste chaînée (on est en O(1) amorti, et en accès direct et avec moins de mémoire allouée). C'est d'ailleur le comportement d'un std::vector en C++.
-- Loïc
Alexandre
> Existe-t-il l'équivalent, pour ne pas dire la même chose, dans d'autres langages, notamment le C++ de chez Microsoft.
le C++ n'est pas de microsoft. Microsoft fait des compilateurs C++ mais le langage est le même que chez les autres éditeurs. En C++ il y a des tableaux dynamiques (std::vector) des listes chainées (std::list) des files d'attente (std::queue) des piles (std::stack) et même des ensembles (std::set) et des tables (std::map). Donc tu as tout ce qu'il te faut.
Sinon, comment faites-vous pour échanger entre .exe et .dll quand vous ne connaissez pas à la compilation la taille des infos à échanger ;le nombre de pixels de l'image en cours de traitement par exemple.
Merci de votre aide.
Pierre.
> Existe-t-il l'équivalent, pour ne pas dire la même chose, dans d'autres
langages, notamment le C++ de chez Microsoft.
le C++ n'est pas de microsoft. Microsoft fait des compilateurs C++ mais le
langage est le même que chez les autres éditeurs.
En C++ il y a des tableaux dynamiques (std::vector) des listes chainées
(std::list) des files d'attente (std::queue) des piles (std::stack) et même
des ensembles (std::set) et des tables (std::map). Donc tu as tout ce qu'il
te faut.
Sinon, comment faites-vous pour échanger entre .exe et .dll quand vous ne
connaissez pas à la compilation la taille des infos à échanger ;le nombre
de
pixels de l'image en cours de traitement par exemple.
> Existe-t-il l'équivalent, pour ne pas dire la même chose, dans d'autres langages, notamment le C++ de chez Microsoft.
le C++ n'est pas de microsoft. Microsoft fait des compilateurs C++ mais le langage est le même que chez les autres éditeurs. En C++ il y a des tableaux dynamiques (std::vector) des listes chainées (std::list) des files d'attente (std::queue) des piles (std::stack) et même des ensembles (std::set) et des tables (std::map). Donc tu as tout ce qu'il te faut.
Sinon, comment faites-vous pour échanger entre .exe et .dll quand vous ne connaissez pas à la compilation la taille des infos à échanger ;le nombre de pixels de l'image en cours de traitement par exemple.
Merci de votre aide.
Pierre.
Alexandre
"Bertrand Lenoir-Welter" a écrit dans le message de news: 41947a74$0$13376$
va falloir réviser les pointeurs et les listes .... les tableaux dynamiques ne sont que des listes de listes, avec toute la gestion des pointeurs qui est cachée.
Sans même aller jusque là, il me semble qu'un malloc suffit à faire un tableau dynamique. L'avantage des liste est surtout de faire un tableau élastique, c'est à dire dont la dimension change en cours de route. Dans ce cas de figure, c'est irremplaçable.
en C++ un new est préférable à un malloc. En C++ l'utilisation d'un std::vector est préférable à un new pour faire un tableau dynamique.
"Bertrand Lenoir-Welter" <bertrand.2003@galaad.net> a écrit dans le message
de news: 41947a74$0$13376$8fcfb975@news.wanadoo.fr...
va falloir réviser les pointeurs et les listes ....
les tableaux dynamiques ne sont que des listes de listes, avec toute la
gestion des pointeurs qui est cachée.
Sans même aller jusque là, il me semble qu'un malloc suffit à faire un
tableau dynamique. L'avantage des liste est surtout de faire un tableau
élastique, c'est à dire dont la dimension change en cours de route. Dans
ce cas de figure, c'est irremplaçable.
en C++ un new est préférable à un malloc.
En C++ l'utilisation d'un std::vector est préférable à un new pour faire un
tableau dynamique.
"Bertrand Lenoir-Welter" a écrit dans le message de news: 41947a74$0$13376$
va falloir réviser les pointeurs et les listes .... les tableaux dynamiques ne sont que des listes de listes, avec toute la gestion des pointeurs qui est cachée.
Sans même aller jusque là, il me semble qu'un malloc suffit à faire un tableau dynamique. L'avantage des liste est surtout de faire un tableau élastique, c'est à dire dont la dimension change en cours de route. Dans ce cas de figure, c'est irremplaçable.
en C++ un new est préférable à un malloc. En C++ l'utilisation d'un std::vector est préférable à un new pour faire un tableau dynamique.
Bertrand Lenoir-Welter
> en C++ un new est préférable à un malloc.
Et c'est gravé dans quel marbre, ce dogme ?
Je code en C++ et j'utilise new quand j'ai un type fixe derrière, par exemple une structure pour une liste chaînée - donc à taille fixe. Mais quand j'ai une allocation dont la taille dynamique m'est fournie par une variable, par exemple pour loger un bloc d'octets élastique, alors retour au bon vieux malloc. Honte à moi.
Au fait, ce "préférable", ça veut dire quoi exactement ?
En C++ l'utilisation d'un std::vector est préférable à un new pour faire un tableau dynamique.
Indubitablement. Et des oeillères sont préférables pour ne pas avoir un horizon trop large. Je dois être de la vieille école.
> en C++ un new est préférable à un malloc.
Et c'est gravé dans quel marbre, ce dogme ?
Je code en C++ et j'utilise new quand j'ai un type fixe derrière, par
exemple une structure pour une liste chaînée - donc à taille fixe. Mais
quand j'ai une allocation dont la taille dynamique m'est fournie par une
variable, par exemple pour loger un bloc d'octets élastique, alors
retour au bon vieux malloc. Honte à moi.
Au fait, ce "préférable", ça veut dire quoi exactement ?
En C++ l'utilisation d'un std::vector est préférable à un new pour faire un
tableau dynamique.
Indubitablement. Et des oeillères sont préférables pour ne pas avoir un
horizon trop large. Je dois être de la vieille école.
Je code en C++ et j'utilise new quand j'ai un type fixe derrière, par exemple une structure pour une liste chaînée - donc à taille fixe. Mais quand j'ai une allocation dont la taille dynamique m'est fournie par une variable, par exemple pour loger un bloc d'octets élastique, alors retour au bon vieux malloc. Honte à moi.
Au fait, ce "préférable", ça veut dire quoi exactement ?
En C++ l'utilisation d'un std::vector est préférable à un new pour faire un tableau dynamique.
Indubitablement. Et des oeillères sont préférables pour ne pas avoir un horizon trop large. Je dois être de la vieille école.
Pierre CHAUVEAU
Encore merci à vous tous pour toutes ces infos.
Pierre.
"Pierre CHAUVEAU" a écrit dans le message de news:4193f1ed$0$10631$
Bonjour à toutes et à tous,
Personnellement, je réalise mes programmes avec DELPHI (langage Pascal de BORLAND) où sont définis des "tableaux dynamiques". Ce sont des tableaux dont on peut fixer la taille (le nombre d'éléments) à l'exécution.
J'utilise ce type de tableaux pour échanger des infos entre un programme
et
des DLL.
Existe-t-il l'équivalent, pour ne pas dire la même chose, dans d'autres langages, notamment le C++ de chez Microsoft.
Sinon, comment faites-vous pour échanger entre .exe et .dll quand vous ne connaissez pas à la compilation la taille des infos à échanger ;le nombre
de
pixels de l'image en cours de traitement par exemple.
Merci de votre aide.
Pierre.
Encore merci à vous tous pour toutes ces infos.
Pierre.
"Pierre CHAUVEAU" <pierre.chauveau@wanadoo.fr> a écrit dans le message de
news:4193f1ed$0$10631$8fcfb975@news.wanadoo.fr...
Bonjour à toutes et à tous,
Personnellement, je réalise mes programmes avec DELPHI (langage Pascal de
BORLAND) où sont définis des "tableaux dynamiques". Ce sont des tableaux
dont on peut fixer la taille (le nombre d'éléments) à l'exécution.
J'utilise ce type de tableaux pour échanger des infos entre un programme
et
des DLL.
Existe-t-il l'équivalent, pour ne pas dire la même chose, dans d'autres
langages, notamment le C++ de chez Microsoft.
Sinon, comment faites-vous pour échanger entre .exe et .dll quand vous ne
connaissez pas à la compilation la taille des infos à échanger ;le nombre
de
pixels de l'image en cours de traitement par exemple.
"Pierre CHAUVEAU" a écrit dans le message de news:4193f1ed$0$10631$
Bonjour à toutes et à tous,
Personnellement, je réalise mes programmes avec DELPHI (langage Pascal de BORLAND) où sont définis des "tableaux dynamiques". Ce sont des tableaux dont on peut fixer la taille (le nombre d'éléments) à l'exécution.
J'utilise ce type de tableaux pour échanger des infos entre un programme
et
des DLL.
Existe-t-il l'équivalent, pour ne pas dire la même chose, dans d'autres langages, notamment le C++ de chez Microsoft.
Sinon, comment faites-vous pour échanger entre .exe et .dll quand vous ne connaissez pas à la compilation la taille des infos à échanger ;le nombre
de
pixels de l'image en cours de traitement par exemple.
Merci de votre aide.
Pierre.
Alexandre
"Bertrand Lenoir-Welter" a écrit dans le message de news: 41966291$0$5877$
en C++ un new est préférable à un malloc.
Et c'est gravé dans quel marbre, ce dogme ?
ce n'est pas un dogme... C'est pour de bonnes raisons ;-)
Je code en C++ et j'utilise new quand j'ai un type fixe derrière, par exemple une structure pour une liste chaînée - donc à taille fixe. Mais quand j'ai une allocation dont la taille dynamique m'est fournie par une variable, par exemple pour loger un bloc d'octets élastique, alors retour au bon vieux malloc. Honte à moi.
et ton pointeur est un void* ? Dans ce cas, un malloc est possible, mais ton pointeur va prendre des risques... voir dessous.
Au fait, ce "préférable", ça veut dire quoi exactement ?
1) si new échoue alors lancement d'une exception... et le programme s'arrete proprement si on ne teste rien. Si malloc échoue alors ça renvoie NULL, et ça plante si on ne teste pas. 2) malloc renvoie un void* donc pas de typage fort du pointeur. Tu est obligé de faire un cast "sauvage" (statique, quoi) et souvent ça masque des futurs problèmes...
On peut faire par exemple :
struct C1 { /*....*/ }; struct C2 {/*....*/}; autre objet de taille différente
C1* ptr_mal_alloue = (C1*)malloc(sizeof(C2)); // AIE AIE !!! une simple faute de frappe fait courir au programme un gros risque... Alors qu'un
C1 *ptr_qui_compile_pas = new C2; // ici le compilo bloque, normal !
En C++ l'utilisation d'un std::vector est préférable à un new pour faire un tableau dynamique.
Indubitablement. Et des oeillères sont préférables pour ne pas avoir un horizon trop large. Je dois être de la vieille école.
Mais non. C'est tout simplement inutile en C++ de coder un tableau dynamique puisque ça existe déjà.
"Bertrand Lenoir-Welter" <bertrand.2003@galaad.net> a écrit dans le message
de news: 41966291$0$5877$8fcfb975@news.wanadoo.fr...
en C++ un new est préférable à un malloc.
Et c'est gravé dans quel marbre, ce dogme ?
ce n'est pas un dogme... C'est pour de bonnes raisons ;-)
Je code en C++ et j'utilise new quand j'ai un type fixe derrière, par
exemple une structure pour une liste chaînée - donc à taille fixe. Mais
quand j'ai une allocation dont la taille dynamique m'est fournie par une
variable, par exemple pour loger un bloc d'octets élastique, alors retour
au bon vieux malloc. Honte à moi.
et ton pointeur est un void* ? Dans ce cas, un malloc est possible, mais ton
pointeur va prendre des risques... voir dessous.
Au fait, ce "préférable", ça veut dire quoi exactement ?
1) si new échoue alors lancement d'une exception... et le programme s'arrete
proprement si on ne teste rien.
Si malloc échoue alors ça renvoie NULL, et ça plante si on ne teste pas.
2) malloc renvoie un void* donc pas de typage fort du pointeur. Tu est
obligé de faire un cast "sauvage" (statique, quoi) et souvent ça masque des
futurs problèmes...
On peut faire par exemple :
struct C1 { /*....*/ };
struct C2 {/*....*/}; autre objet de taille différente
C1* ptr_mal_alloue = (C1*)malloc(sizeof(C2)); // AIE AIE !!!
une simple faute de frappe fait courir au programme un gros risque...
Alors qu'un
C1 *ptr_qui_compile_pas = new C2; // ici le compilo bloque, normal !
En C++ l'utilisation d'un std::vector est préférable à un new pour faire
un tableau dynamique.
Indubitablement. Et des oeillères sont préférables pour ne pas avoir un
horizon trop large. Je dois être de la vieille école.
Mais non. C'est tout simplement inutile en C++ de coder un tableau dynamique
puisque ça existe déjà.
"Bertrand Lenoir-Welter" a écrit dans le message de news: 41966291$0$5877$
en C++ un new est préférable à un malloc.
Et c'est gravé dans quel marbre, ce dogme ?
ce n'est pas un dogme... C'est pour de bonnes raisons ;-)
Je code en C++ et j'utilise new quand j'ai un type fixe derrière, par exemple une structure pour une liste chaînée - donc à taille fixe. Mais quand j'ai une allocation dont la taille dynamique m'est fournie par une variable, par exemple pour loger un bloc d'octets élastique, alors retour au bon vieux malloc. Honte à moi.
et ton pointeur est un void* ? Dans ce cas, un malloc est possible, mais ton pointeur va prendre des risques... voir dessous.
Au fait, ce "préférable", ça veut dire quoi exactement ?
1) si new échoue alors lancement d'une exception... et le programme s'arrete proprement si on ne teste rien. Si malloc échoue alors ça renvoie NULL, et ça plante si on ne teste pas. 2) malloc renvoie un void* donc pas de typage fort du pointeur. Tu est obligé de faire un cast "sauvage" (statique, quoi) et souvent ça masque des futurs problèmes...
On peut faire par exemple :
struct C1 { /*....*/ }; struct C2 {/*....*/}; autre objet de taille différente
C1* ptr_mal_alloue = (C1*)malloc(sizeof(C2)); // AIE AIE !!! une simple faute de frappe fait courir au programme un gros risque... Alors qu'un
C1 *ptr_qui_compile_pas = new C2; // ici le compilo bloque, normal !
En C++ l'utilisation d'un std::vector est préférable à un new pour faire un tableau dynamique.
Indubitablement. Et des oeillères sont préférables pour ne pas avoir un horizon trop large. Je dois être de la vieille école.
Mais non. C'est tout simplement inutile en C++ de coder un tableau dynamique puisque ça existe déjà.
AMcD®
Alexandre wrote:
1) si new échoue alors lancement d'une exception... et le programme s'arrete proprement si on ne teste rien.
C'est les nazes qui programment sans vérifier les retours de fonctions...
Si malloc échoue alors ça renvoie NULL, et ça plante si on ne teste pas.
Voir ci-dessus.
2) malloc renvoie un void* donc pas de typage fort du pointeur. Tu est obligé de faire un cast "sauvage" (statique, quoi) et souvent ça masque des futurs problèmes...
Mouarf, quel problème puis-je avoir à cause d'un void* ?
struct C1 { /*....*/ }; struct C2 {/*....*/}; autre objet de taille différente
C1* ptr_mal_alloue = (C1*)malloc(sizeof(C2)); // AIE AIE !!! une simple faute de frappe fait courir au programme un gros risque...
Déjà le gars il à qu'a coder proprement genre PC1 au lieu de C1*, ce sera plus lisible. Ensuite, utiliser des noms plus explicites et il ne fera pas ce genre d'erreur. Tu me rappelles ma jeunesse où, pour taquiner mes huîtres de profs, je codais toutes mes variables x1, x2, x3, x4... Gnihihi. Non, sérieusement, appeler une variable C1, tu vas au devant d'autres ennuis qu'un simple mélange entre un C1 et C2 : l'inmaintenabilité de ton code.
Note que le transtypage sauvage comme tu l'appelles a son intérêt pour certaines choses. C'est parfois utile de faire croire à un BYTE qu'il est un CHAR :-).
Mais non. C'est tout simplement inutile en C++ de coder un tableau dynamique puisque ça existe déjà.
Sur ce point, tu as entièrement raison.
-- AMcD®
http://arnold.mcdonald.free.fr/
Alexandre wrote:
1) si new échoue alors lancement d'une exception... et le programme
s'arrete proprement si on ne teste rien.
C'est les nazes qui programment sans vérifier les retours de fonctions...
Si malloc échoue alors ça renvoie NULL, et ça plante si on ne teste
pas.
Voir ci-dessus.
2) malloc renvoie un void* donc pas de typage fort du pointeur.
Tu est obligé de faire un cast "sauvage" (statique, quoi) et souvent
ça masque des futurs problèmes...
Mouarf, quel problème puis-je avoir à cause d'un void* ?
struct C1 { /*....*/ };
struct C2 {/*....*/}; autre objet de taille différente
C1* ptr_mal_alloue = (C1*)malloc(sizeof(C2)); // AIE AIE !!!
une simple faute de frappe fait courir au programme un gros risque...
Déjà le gars il à qu'a coder proprement genre PC1 au lieu de C1*, ce sera
plus lisible. Ensuite, utiliser des noms plus explicites et il ne fera pas
ce genre d'erreur. Tu me rappelles ma jeunesse où, pour taquiner mes huîtres
de profs, je codais toutes mes variables x1, x2, x3, x4... Gnihihi. Non,
sérieusement, appeler une variable C1, tu vas au devant d'autres ennuis
qu'un simple mélange entre un C1 et C2 : l'inmaintenabilité de ton code.
Note que le transtypage sauvage comme tu l'appelles a son intérêt pour
certaines choses. C'est parfois utile de faire croire à un BYTE qu'il est un
CHAR :-).
Mais non. C'est tout simplement inutile en C++ de coder un tableau
dynamique puisque ça existe déjà.
1) si new échoue alors lancement d'une exception... et le programme s'arrete proprement si on ne teste rien.
C'est les nazes qui programment sans vérifier les retours de fonctions...
Si malloc échoue alors ça renvoie NULL, et ça plante si on ne teste pas.
Voir ci-dessus.
2) malloc renvoie un void* donc pas de typage fort du pointeur. Tu est obligé de faire un cast "sauvage" (statique, quoi) et souvent ça masque des futurs problèmes...
Mouarf, quel problème puis-je avoir à cause d'un void* ?
struct C1 { /*....*/ }; struct C2 {/*....*/}; autre objet de taille différente
C1* ptr_mal_alloue = (C1*)malloc(sizeof(C2)); // AIE AIE !!! une simple faute de frappe fait courir au programme un gros risque...
Déjà le gars il à qu'a coder proprement genre PC1 au lieu de C1*, ce sera plus lisible. Ensuite, utiliser des noms plus explicites et il ne fera pas ce genre d'erreur. Tu me rappelles ma jeunesse où, pour taquiner mes huîtres de profs, je codais toutes mes variables x1, x2, x3, x4... Gnihihi. Non, sérieusement, appeler une variable C1, tu vas au devant d'autres ennuis qu'un simple mélange entre un C1 et C2 : l'inmaintenabilité de ton code.
Note que le transtypage sauvage comme tu l'appelles a son intérêt pour certaines choses. C'est parfois utile de faire croire à un BYTE qu'il est un CHAR :-).
Mais non. C'est tout simplement inutile en C++ de coder un tableau dynamique puisque ça existe déjà.
Sur ce point, tu as entièrement raison.
-- AMcD®
http://arnold.mcdonald.free.fr/
Pierre Maurette
"AMcD®" a écrit:
Alexandre wrote:
1) si new échoue alors lancement d'une exception... et le programme s'arrete proprement si on ne teste rien.
C'est les nazes qui programment sans vérifier les retours de fonctions...
Si malloc échoue alors ça renvoie NULL, et ça plante si on ne teste pas.
Voir ci-dessus.
2) malloc renvoie un void* donc pas de typage fort du pointeur. Tu est obligé de faire un cast "sauvage" (statique, quoi) et souvent ça masque des futurs problèmes...
Mouarf, quel problème puis-je avoir à cause d'un void* ?
+1 -- Pierre
"AMcD®" <arnold.mcdonald@free.fr> a écrit:
Alexandre wrote:
1) si new échoue alors lancement d'une exception... et le programme
s'arrete proprement si on ne teste rien.
C'est les nazes qui programment sans vérifier les retours de fonctions...
Si malloc échoue alors ça renvoie NULL, et ça plante si on ne teste
pas.
Voir ci-dessus.
2) malloc renvoie un void* donc pas de typage fort du pointeur.
Tu est obligé de faire un cast "sauvage" (statique, quoi) et souvent
ça masque des futurs problèmes...
Mouarf, quel problème puis-je avoir à cause d'un void* ?
1) si new échoue alors lancement d'une exception... et le programme s'arrete proprement si on ne teste rien.
C'est les nazes qui programment sans vérifier les retours de fonctions...
Si malloc échoue alors ça renvoie NULL, et ça plante si on ne teste pas.
Voir ci-dessus.
2) malloc renvoie un void* donc pas de typage fort du pointeur. Tu est obligé de faire un cast "sauvage" (statique, quoi) et souvent ça masque des futurs problèmes...
Mouarf, quel problème puis-je avoir à cause d'un void* ?
+1 -- Pierre
Vincent Burel
"Alexandre" wrote in message news:41964d72$0$10715$
"Bertrand Lenoir-Welter" a écrit dans le
message
de news: 41947a74$0$13376$ >> va falloir réviser les pointeurs et les listes .... >> les tableaux dynamiques ne sont que des listes de listes, avec toute la >> gestion des pointeurs qui est cachée. > > Sans même aller jusque là, il me semble qu'un malloc suffit à faire un > tableau dynamique. L'avantage des liste est surtout de faire un tableau > élastique, c'est à dire dont la dimension change en cours de route. Dans > ce cas de figure, c'est irremplaçable.
en C++ un new est préférable à un malloc.
C'est une confusion classique chez les "pseudo-programmeur" C++, je le répète donc, le NEW en C++ sert à hinstancier, créer et déclencher l'appel du constructeur d'un object de type C++. le Malloc est une fonction qui permet d'allouer de la mémoire. Donc, il n'y a pas grand rapport avec ces deux fonctions, ou plutot fonctionnalités, car "malloc" est une fonction d'un librairie, "new" est un mot réservé du langage...
En C++ l'utilisation d'un std::vector est préférable à un new pour faire
un
tableau dynamique.
Ce choix là, vous regarde, ceci dit le NEW ne peut pas servir à faire un tableau dynamique, il peut éventuellement servire à hinstancier un objet de gestion de tableau dynamique, voire hinstancier les objets qui seront stocker dans un tableau dynamique... Mais encore une fois vous faites confusion. C'est comme si je disais, "New sert à faire un jeu vidéo".
VB
"Alexandre" <alex.g@netcourrier.com> wrote in message
news:41964d72$0$10715$626a14ce@news.free.fr...
"Bertrand Lenoir-Welter" <bertrand.2003@galaad.net> a écrit dans le
message
de news: 41947a74$0$13376$8fcfb975@news.wanadoo.fr...
>> va falloir réviser les pointeurs et les listes ....
>> les tableaux dynamiques ne sont que des listes de listes, avec toute la
>> gestion des pointeurs qui est cachée.
>
> Sans même aller jusque là, il me semble qu'un malloc suffit à faire un
> tableau dynamique. L'avantage des liste est surtout de faire un tableau
> élastique, c'est à dire dont la dimension change en cours de route. Dans
> ce cas de figure, c'est irremplaçable.
en C++ un new est préférable à un malloc.
C'est une confusion classique chez les "pseudo-programmeur" C++, je le
répète donc, le NEW en C++ sert à hinstancier, créer et déclencher l'appel
du constructeur d'un object de type C++. le Malloc est une fonction qui
permet d'allouer de la mémoire. Donc, il n'y a pas grand rapport avec ces
deux fonctions, ou plutot fonctionnalités, car "malloc" est une fonction
d'un librairie, "new" est un mot réservé du langage...
En C++ l'utilisation d'un std::vector est préférable à un new pour faire
un
tableau dynamique.
Ce choix là, vous regarde, ceci dit le NEW ne peut pas servir à faire un
tableau dynamique, il peut éventuellement servire à hinstancier un objet de
gestion de tableau dynamique, voire hinstancier les objets qui seront
stocker dans un tableau dynamique... Mais encore une fois vous faites
confusion. C'est comme si je disais, "New sert à faire un jeu vidéo".
"Alexandre" wrote in message news:41964d72$0$10715$
"Bertrand Lenoir-Welter" a écrit dans le
message
de news: 41947a74$0$13376$ >> va falloir réviser les pointeurs et les listes .... >> les tableaux dynamiques ne sont que des listes de listes, avec toute la >> gestion des pointeurs qui est cachée. > > Sans même aller jusque là, il me semble qu'un malloc suffit à faire un > tableau dynamique. L'avantage des liste est surtout de faire un tableau > élastique, c'est à dire dont la dimension change en cours de route. Dans > ce cas de figure, c'est irremplaçable.
en C++ un new est préférable à un malloc.
C'est une confusion classique chez les "pseudo-programmeur" C++, je le répète donc, le NEW en C++ sert à hinstancier, créer et déclencher l'appel du constructeur d'un object de type C++. le Malloc est une fonction qui permet d'allouer de la mémoire. Donc, il n'y a pas grand rapport avec ces deux fonctions, ou plutot fonctionnalités, car "malloc" est une fonction d'un librairie, "new" est un mot réservé du langage...
En C++ l'utilisation d'un std::vector est préférable à un new pour faire
un
tableau dynamique.
Ce choix là, vous regarde, ceci dit le NEW ne peut pas servir à faire un tableau dynamique, il peut éventuellement servire à hinstancier un objet de gestion de tableau dynamique, voire hinstancier les objets qui seront stocker dans un tableau dynamique... Mais encore une fois vous faites confusion. C'est comme si je disais, "New sert à faire un jeu vidéo".
VB
Patrick D.
On Sun, 14 Nov 2004 08:23:42 +0100, Vincent Burel wrote:
Ce choix là, vous regarde, ceci dit le NEW ne peut pas servir à faire un tableau dynamique, il peut éventuellement servire à hinstancier un objet de gestion de tableau dynamique, voire hinstancier les objets qui seront stocker dans un tableau dynamique... Mais encore une fois vous faites confusion. C'est comme si je disais, "New sert à faire un jeu vidéo".
manifestement tu as pris l'habitude de préfixer tes variables d'instance avec le préfixe 'hinst' . c'est bien. de là à en faire dériver un verbe en français ....
'instancier' et non 'hinstancier' je me demande d'ailleurs si ce verbe existe en dehors du jargon informatique.
vu le nombre d'utilisations que tu en as faites, je n'ai pu m'empêcher d'instancier cette correction !
cordialement
-- * enlevez '.don't.spam' et '.invalid' de mon adresse eMail si vous voulez m'écrire * * Donne un poisson à un homme, il aura à manger pour un jour * Apprends-lui à pêcher, il aura à manger pour tous les jours de sa vie *
On Sun, 14 Nov 2004 08:23:42 +0100, Vincent Burel
<vincent.burel@spam-wanadoo.fr> wrote:
Ce choix là, vous regarde, ceci dit le NEW ne peut pas servir à faire un
tableau dynamique, il peut éventuellement servire à hinstancier un objet
de
gestion de tableau dynamique, voire hinstancier les objets qui seront
stocker dans un tableau dynamique... Mais encore une fois vous faites
confusion. C'est comme si je disais, "New sert à faire un jeu vidéo".
manifestement tu as pris l'habitude de préfixer tes variables d'instance
avec le préfixe 'hinst' . c'est bien.
de là à en faire dériver un verbe en français ....
'instancier' et non 'hinstancier'
je me demande d'ailleurs si ce verbe existe en dehors du jargon
informatique.
vu le nombre d'utilisations que tu en as faites, je n'ai pu m'empêcher
d'instancier cette correction !
cordialement
--
* enlevez '.don't.spam' et '.invalid' de mon adresse eMail si vous voulez
m'écrire *
* Donne un poisson à un homme, il aura à manger pour un jour
* Apprends-lui à pêcher, il aura à manger pour tous les jours de sa vie *
On Sun, 14 Nov 2004 08:23:42 +0100, Vincent Burel wrote:
Ce choix là, vous regarde, ceci dit le NEW ne peut pas servir à faire un tableau dynamique, il peut éventuellement servire à hinstancier un objet de gestion de tableau dynamique, voire hinstancier les objets qui seront stocker dans un tableau dynamique... Mais encore une fois vous faites confusion. C'est comme si je disais, "New sert à faire un jeu vidéo".
manifestement tu as pris l'habitude de préfixer tes variables d'instance avec le préfixe 'hinst' . c'est bien. de là à en faire dériver un verbe en français ....
'instancier' et non 'hinstancier' je me demande d'ailleurs si ce verbe existe en dehors du jargon informatique.
vu le nombre d'utilisations que tu en as faites, je n'ai pu m'empêcher d'instancier cette correction !
cordialement
-- * enlevez '.don't.spam' et '.invalid' de mon adresse eMail si vous voulez m'écrire * * Donne un poisson à un homme, il aura à manger pour un jour * Apprends-lui à pêcher, il aura à manger pour tous les jours de sa vie *
