Discussion :

[Dilettante]

Bonjour !

J'essaie désespérément d'allouer de la mémoire pour un tableau de pointeurs déclaré ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
  STState* leafs[];

La taille du tableau dépend d'une variable "taille" que je passe en paramètre d'un constructeur. Du coup, je tente d'allouer la mémoire comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
  leafs = (STState*) malloc( taille * sizeof(STState*) );

Mais apparemment le compilateur (gcc 4.1.1) n'aime pas trop mon cast car il dit ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
erreur: incompatible types in assignment of ‘STState*’ to ‘STState* [0u]’

J'ai essayé de caster de plusierus manières différentes, mais toujours avec le même résultat. Je commence à désespérer de trouver la solution un jour...

Quelqu'un saurait-il m'indiquer la bonne manière de faire ?

[Médinoc]

[] signifie tableau, tableau.

Si tu veux un tableau de pointeurs de taille non-spécifiée, tu dois utiliser un pointeur de pointeur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

STState ** ppLeafs = NULL;

Il pointera sur le dernier pointeur du tableau.

Et tu pourras l'allouer ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ppLeafs = new STState* [taille];
//Ou bien
ppLeafs = static_cast< STState ** >( malloc(taille * sizeof *ppLeafs) );

PS1: Pas de cast C-Style en C++, s'il te plait.
PS2: Dans la mesure du possible, on utilise new à la place de malloc() (les exceptions notables étant la nécessité de réallocation et l'interaction avec certains codes C).
PS3: Pourquoi ne pas utiliser un std::vector< STState* > ?

[coyotte507]

Pourquoi utiliser un vector quand on en n'a pas besoin?

[Dilettante]

Ca marche bien maintenant, ouf !

Pour les vectors, je ne peux pas les utiliser car ma struture doit être la plus légère possible tant en mémoire qu'en complexité...

Merci beaucoup !

[Médinoc]

Pourquoi utiliser un vector quand on en n'a pas besoin?

C'est ce que je me suis longtemps dit, mais il semblerait qu'ici la politique est "pourquoi se farcir la gestion d'un tableau quand un vector s'en occupe ?"

Bien sûr, dans le cas présent, on a notre réponse: On veut un tableau flyweight.

[Laurent Gomila]

Pourquoi utiliser un vector quand on en n'a pas besoin?

A partir du moment où tu alloues un tableau dynamiquement, tu as besoin de std::vector. Au moins pour avoir du code exception-safe.

Pour les vectors, je ne peux pas les utiliser car ma struture doit être la plus légère possible tant en mémoire qu'en complexité...

C'est pas plus complexe, et niveau occupation mémoire tu vas payer un ou deux entiers en plus par tableau. C'est réellement un problème ?

[Dilettante]

C'est pas plus complexe, et niveau occupation mémoire tu vas payer un ou deux entiers en plus par tableau. C'est réellement un problème ?

Ben, dans ce cas particulier, avoir une complexité en (12*taille de la donnée) plutot qu'en (15*taille de la donnée) reste très intéressant, donc ça joue pas mal. Surtout que typiquement, je m'attend à gérer des tableaux de 4 éléments. si bien qu'en payant deux entiers en plus, ça multiplie ma complexité par 1,5 !

Par contre :

A partir du moment où tu alloues un tableau dynamiquement, tu as besoin de std::vector. Au moins pour avoir du code exception-safe

C'est pas terrible cette histoire, y a pas moyen d'éviter ça !?

[Laurent Gomila]

Ben, dans ce cas particulier, avoir une complexité en (12*taille de la donnée) plutot qu'en (15*taille de la donnée) reste très intéressant, donc ça joue pas mal. Surtout que typiquement, je m'attend à gérer des tableaux de 4 éléments. si bien qu'en payant deux entiers en plus, ça multiplie ma complexité par 1,5 !

Ca reste quand même anecdotique. Tu travailles sur quel genre de système pour avoir de telles contraintes ?

C'est pas terrible cette histoire, y a pas moyen d'éviter ça !?

Si, il "suffit" de ne pas oublier de libérer la mémoire allouée dynamiquement (et toute ressource en général) à chaque fois qu'une exception est levée. Ca peut sembler facile mais ça ne l'est pas tant que ça, d'autant plus que ça peut vite multiplier la taille du code.
Je t'invite à lire ceci pour mieux te rendre compte :
http://c.developpez.com/faq/cpp/?pag...POINTEURS_raii

[Dilettante]

Ca reste quand même anecdotique.

Oui, sans doute ^^

Tu travailles sur quel genre de système pour avoir de telles contraintes ?

Je travaille sur les Oracles des suffixes, une structure d'index utilisée entre autres pour la recherche de mots dans un texte. On sait depuis longtemps écrire des algos de complexité linéaire en temps et en mémoire pour faire ça, mais on travaille encore activement à en trouver de meilleurs.
Dans mon cas par exemple, ça peut servir à chercher des séquences d'ADN dans des bass de données de gènes, tâches qui peuvent prendre beaucoup de temps, et donc où on aurait bien envie de rester deux fois moins de temps à attendre devant son ordinateur

[Luc Hermitte]

Euh ... je veux bien que la compléxité soit proportionnelle à tes données, mais si tu as 4 données, que tu utilises 50 ou 4 octets pour les stocker ne changera rien à la compléxité de tes algos.
Les impacts seront liés au cache et à la quantité d'éléments simultanément chargeables en mémoire.

Quant au vecteur, typiquement il rajoutera a priori:
- deux sizeof(int) (ou long) par rapport à un tableau statiquement connu pour contenir 4 éléments (boost::array<4>, ...)
- un sizeof(int/long) par rapport à un tableau dynamique non redimensionnable qui se souvient du nombre d'éléments qu'il contient
- rien par rapport à des tableaux redimensionnables.

J'ai déjà vu des abus de roues réinventées pour faire plus léger/rapide qui étaient bien plus couteuses. Fais un typedef sur des vecteurs, prototype avec, tu seras toujours à temps de changer le typedef une fois les autres solutions classiques appliquées (pas de copies inutiles, resize/reserve au lieu de news intempestifs, ...)