Discussion :

[Le Barde]

Bonjour,

J'ai besoin de récupérer la taille d'un tableau alloué dynamiquement. Par contre, je n'utilise pas les vector de la STL, ce qui donne ceci, dans le genre :

Code :

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

1
2
3
4
5
6
 
int RecupTaille(int* TabeauDEntiers)
{
    int Taille;
    // Et maintenant... On veut récupérer la taille du tableau.
}

1. J'ai bien vu la FAQ C++ à ce sujet, qui dit que pour récupérer la taille d'un tableau alloué dynamiquement, c'est impossible sans utiliser vector.

2. (Je vais en faire un template, mais plus tard, ici c'est pour l'exemple)

Alors ma question, puisque j'en ai besoin et que je suis obstiné, c'est est-ce qu'il est possible de faire un accès à TableauDEntiers[Taille] jusqu'à ce que l'on obtienne une exception et alors renvoyer Taille ?

--> de cette manière, cela donnerait :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
int RecupTaille(int* TabeauDEntiers)
{
    int Taille=0;
    try
    {
        while 1
        {
            TableauDEntiers[Taille];
        }
    }
    catch(...)
    {
        return Taille;
    }
}

Merci d'avance pour vos remarques, idées...
Le Barde.

[bolhrak]

Salut,

[screetch]

plusieurs solutions, toutes aussi peu propres que les autres!

- allouer une case supplementaire et y stocker la taille
ensuite tu renvoies le premier vrai element du tableau
en gros :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
int* createTableau(int size)
{
    result = (int*) malloc(sizeof(int)*(taille+1));
    *result = size;
    return result+1;
}
 
void destroyTableau(int*)
{
    free(tableau-1);
}
 
int tailleTableau(int* tableau)
{
    return tableau[-1];
}
 
void utiliseTableau(int* tableau)
{
    for(int i = 0; i < tailleTableau(tableau); ++i)
        printf("tableau[%d]=%d\n", i, tableau[i]);
}

- stocke un element de fin, comme les string C : 0 marque la fin de la chaine. Cela signifie que tu ne peux plus mettre 0 dans le tableau. Tu peux prendre une valeur "magique" qui ne sera jamais mise dans le tableau.



Cela signifie que tu dois avoir tes propres routines de creation et de destruction de tableau, si tu les recois de l'exterieur alors c'est foutu, c'est trop tard.

[Alp]

Pourquoi ne peux tu pas utiliser de vector?

[Le Barde]

Ouh là, vous avez répondu trop vite, j'étais en train de rédiger mon message

C'est le bon message maintenant

[Le Barde]

@ Alp : Je ne peux pas utiliser vector... pour la simple et bonne raison que ce n'est pas moi qui ai commencé le projet et que les personnes qui avaient déjà commencé à coder n'en utilisaient pas. Je continue donc dans leur lancée.

[bolhrak]

Le problème c'est que tu n'est pas sûr d'avoir une erreur si tu dépasses la taille du tableau :

- soit la mémoire après ton tableau est invalide et tu auras une segfault ou une valeur qui ne correspond à rien.
- soit la mémoire après a été allouée et dans ce cas tu auras la valeur d'autre chose (pour peu que ce soit du même type).

Fin bref l'accès à la mémoire comme ça a un comportement indéfini, donc impossibel de s'en servir pour déduire quoi que ce soit.

Donc en gros tu peux :

- prendre les solutions proposées par screetch.
- regarder du côté de boost::array si tu souhaites absolument utiliser des tableaux et pas des vecteurs.

[screetch]

non on ne peut pas faire ce que tu fais car ce qu'il y a au dela du tableau t'appartiens peut etre toujours donc ca ne detecte pas la fin du tableau mais la fin de la zone accessible. Quand a savoir si on peut vraiment catcher les violations d'acces, rien que d'y penser ca me fait fremir.

Si tu peux stocke la taille, sinon c'est impossible, tu es mouru =)

[bolhrak]

Quand a savoir si on peut vraiment catcher les violations d'acces, rien que d'y penser ca me fait fremir.

Le debuggeur de Visual le permet bien, ça a son utilité (oui bon pour du debug uniquement pas de la manière proposée ici ^^)

[screetch]

non mais j'ai deja vu du code qui catchait les violations d'acces au cas ou et poursuivait comme ci de rien etait.

Ca fait peur quand tu es pas prevenu ^^"

[Le Barde]

Pourquoi ça te ferait frémir, screetch ? a priori ça peut être intéressant non ?

[bolhrak]

Euh .. plus sérieusement un access violation est dû à une erreur de programmation, c'est un cas qui n'a pas à être traité par le programme !

De plus quel est le traitement à appliquer dans ce cas là ? la donnée à laquelle tu veux accéder soit :
- n'existe pas/plus
- existe mais ailleurs et tu n'as aucun moyen d'y accéder vu que tu pensais pouvoir y accéder par le code qui a levé l'erreur.

Attraper l'exception juste pour éviter le plantage du programme, mais continuer sans traiter le cas (de toute façon on ne peut pas) revient à reporter le plantage à plus tard.

Donc aucun traitement possible de cette erreur si ce n'est :
- stopper l'appli
- ouvrir un debuggeur
- trouver l'erreur (donc là oui c'est intéressant de récupérer l'exception pour voir où ça plante)
- corriger
- recompiler

Les erreurs de programmation ne sont pas des cas à traiter dans le programme.

EDIT : ma réponse est dans le contexte du message de screetch, où apparemment les catch d'access violation sont faits pour éviter un plantage du programme, si j'ai mal compris désolé pour le hors sujet.

[screetch]

dans un but de report d'erreur a la rigueur.

Comme tu ne connais pas la disposition de la memoire, tu ne sais pas quelle est la memoire qui t'appartient ou pas. Tu ne peux pas savoir si a la fin d'un bloc qui t'appartient commence un nouveau bloc qui t'appartient. Il se peut que d'une execution sur l'autre tu tapes dans ta propre memoire ou dans un bloc qui ne t'appartent pas.

Capturer une violation d'acces ca veut dire que tu penses que ton code va taper dans un bloc qui ne t'appartient pas, mais ceci est completement imprevisible et tu ne peux pas savoir si au prochain lancement tu auras la meme.

C'est tellement aleatoire que je refuse de penser que des gens peuvent s'en servir dans le cadre normal du deroulement d'un programme il m'est douloureux de penser que le deroulement du programme depend de choses aleatoires ^^

[Le Barde]

Oui c'est sûr, pour les erreurs de programmation
Merci pour avoir éclairé ma lanterne aussi sur ce point, et en ce qui concerne la récupération de la taille du tableau, je crois que je vais pouvoir me débrouiller avec ta première solution screetch. Merci beaucoup !

[befalimpertinent]

@ Alp : Je ne peux pas utiliser vector... pour la simple et bonne raison que ce n'est pas moi qui ai commencé le projet et que les personnes qui avaient déjà commencé à coder n'en utilisaient pas. Je continue donc dans leur lancée.

Discrètement tu glisses un petit #include <vector> personne n'en saura rien . Franchement si le projet est en C++ pourquoi ce privé d'un apport essentiel par rapport au C : la STL

Sinon pour ta question ça me parait totalement impossible

Le coup du catch exception . Bonjour les problèmes de maintenance après alors que la STL permet justement de l'améliorer énormément.

Enfin bref, impose le vector ou n'essayes pas de récupérer la taille du tableau.

[roulious]

Il est effectivement impossible de récupérer la taille d'un tableau vu que d'après ton prototype, tu as un pointeur et non pas un tableau. Quant à essayer d'aller voir au delà du tableau, celà va causer un comportement indéfini. Donc aucune exception ou autre erreur n'est garantie.

Le plus simple est effectivement d'utiliser vector. En fonction des performances dont tu as besoin, tu peux peut être te permettre d'utiliser vector autant que possible, en copiant ton tableau dans un vector et en propageant l'utilisation du vector petit à petit dans le code existant. Vu que le vector a grosso modo la sémantique d'un tableau C, ça ne devrait poser trop de problèmes.

[Alp]

Si tableau à taille variable : std::vector . Tu peux t'en servir comme un tableau C. Cf

Si tableau de taille fixe : boost::array (cf ma signature)

Te laisse pas faire. Si tu n'as aucune contrainte, utilise les meilleurs outils.
Tu pourras de plus assez facilement te servir de l'un comme de l'autre dans du code C-like.

[loufoque]

Ce n'est pas une bonne solution du tout, et ce pour plusieurs raisons :
- Ce genre d'erreurs est récupérée par le noyau, qui doit ensuite la fournir à l'utilisateur. Cela impose une ABI pour les exceptions extremement lourde. D'ailleurs il me semble qu'elle ne supporte pas finally (les destructeurs).
- Si ton allocateur décide de fournir les octets 128-252 lors d'une allocation, puis les octets 256-380 lors d'une autre allocation, en utilisant les octets 252-256 pour y stocker des infos diverses (comme la taille du segment), tu ne détecteras jamais que tu arrives à la fin de ton tableau qui se trouve aux cases 128-252, tout simplement parce qui suit reste de la mémoire valide allouée par le processus. Au contraire tu risques d'écrire et de faire des conneries à des endroits auxquels tu ne devrais surtout pas toucher.

Il faut que tu stockes l'information sur la taille de ton tableau d'une manière ou d'une autre, par exemple avec un caractère spécial en fin ou avec un champ séparé qui indique la taille.
Alternativement, certains allocateurs permettent de connaître la taille d'un segment à partir de son adresse. (ce qui est généralement plus grand que la taille originellement demandée)

[Le Barde]

Bon, bon. Alors je vois bien que ça pose problème.

Alors voici ce que j'ai fait :

Code :

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

1
2
3
4
5
6
7
 
template<typename TYPE> void Array<TYPE>::Sort(TYPE* Tableau, int* Sequence)
{
int TailleTableau;
TailleTableau = ((std::vector<TYPE>*) Tableau)->size();
...
}

Qu'en pensez-vous ? Le programme compile sans problème, mais j'ai une segmentatoin fault. Le tableau "Tableau" a en pratique une taille égale à 6, et le débogueur me raconte que TailleTableau = 188888916 ??

Y a-t-il moyen de récupérer la taille véritable du tableau ainsi ?

[loufoque]

C'est n'importe quoi.
C'est quoi ce cast horrible au milieu ?

C'est tout simplement du non sens.
Je suggère que tu suives un cours de C++.