Forum Programmation.c retourner un pointeur vers un tableau de pointeurs

Posté par Sygne (site web personnel) le 19 août 2012 à 14:28.

Étiquettes : aucune

août

2012

Bonjour,

Je commence le C, et m'entraîne en modifiant un petit logiciel, et je me heurte à des difficultés…

Une fonction teste une expression et retourne un pointeur vers la fin de l'expression si elle est trouvée. J'aimerais qu'elle retourne en outre un pointeur vers le début de l'expression, soit deux pointeurs. Comment faire ça proprement?

Voici un résumé du code actuel:

char *
expmatch (char *s)
{
    return (s+3);
}

int
main(void)
{
    char *s;
    s=expmatch("Hello world");
}

Et voici le code faux, car je ne sais pas comment noter les pointeurs:

int
main(void)
{
    char **s[2]; //pointeur vers tableau de pointeur ?
    char **s0; // pointeur vers premier pointeur du tableau ?
    char **s1; // pointeur vers deuxième pointeur du tableau ?
    s=expmatch("string");
    s0=s[0];
    s1=s[1];
}

En dehors des usages triviaux, j'ai encore beaucoup de mal avec les pointeurs, aussi, la résolution de ce petit problème m'aiderait beaucoup.

Merci d'avance.

# Deux paramètres

Posté par BFG le 19 août 2012 à 14:59. Évalué à 4.

Plutôt que retourner un tableau de pointeurs, qui serait de taille fixe, vous pouvez utiliser des paramètres de type sortie : avoir des char * et indiquer à la fonction qu'elle doit stocker ses résultats dedans.

/* Pour l'exemple, sortie_debut contiendra le debut de la chaine, sortie_fin la fin de la chaine.
Le début et la fin sont tous les 2 passés en paramètre par souci de cohérence.
Le début est également retourné pour pouvoir l'utiliser dans un if plus facilement (si vous le souhaitez, peut-être cela crée une confusion).
*/
char *expmatch(char *entree, char **sortie_debut, char **sortie_fin) {
    *sortie_debut = entree;
    *sortie_fin = entree + strlen(entree);
    return *sortie_debut;
}

int main(int argc, char **argv) {
    char *debut; /* pas besoin d'initialiser */
    char *fin;

    if (expmatch("Hello world!", &debut, &fin)) {
        /* debut et fin sont valides */
    } else {
        /* pas trouvé, debut et fin non valides (ou NULL) */
    }
}

Vous pouvez également passer un tableau de pointeurs en paramètres qui sera utilisé en sortie.

void expmatch(char *entree, char * sorties[2]);

Si vous souhaitez vraiment retourner un tableau, alors il vous faudra utiliser de l'allocation dynamique (malloc et free).

# Structure

Posté par Obsidian le 19 août 2012 à 15:04. Évalué à 6.
Une fonction teste une expression et retourne un pointeur vers la fin de l'expression si elle est trouvée. J'aimerais qu'elle retourne en outre un pointeur vers le début de l'expression, soit deux pointeurs. Comment faire ça proprement?

Tu reçois donc un pointeur vers le début d'une chaîne de caractères (donc « char * ») et tu veux retourner deux pointeurs vers d'autres endroits de la même chaîne. Ces deux pointeurs de retour seront donc du même type que le paramètre. Évidemment, une fonction ne peux pas prendre deux valeurs différentes pour un même paramètre, donc il va falloir les encapsuler dans quelque chose d'autres. L'idée du tableau n'était donc pas mauvaise, mais ne sera pas la plus appropriée ici :

Tu ne peux pas retourner directement un tableau ni passer son contenu en paramètre parce qu'un tableau en C n'est pas à proprement parler un objet. C'est seulement l'instanciation de n variables du même type et consécutives en mémoire, ni plus ni moins. Il n'y a aucune méta-données associées qui te permette de savoir à l'exécution quelle est la taille du tableau, par exemple. Il y a donc seulement deux cas où un nom de tableau est traité comme tel : sizeof, qui te donne en octets la taille du tableau en mémoire… si elle est connue à la compilation, et l'opérateur unaire « & » qui t'en renvoie l'adresse : « tab » est alors équivalent à « &tab » et renvoie la même valeur. Dans tous les autres cas, le nom d'un tableau au sein d'une expression est développé en pointeur vers le premier élément, comme pour une chaîne de caractères (ou de n'importe quoi d'autre).

Ça veut dire que comme tu ne peux pas le transmettre directement en tant qu'objet, tu es obligé de l'allouer quelque part. Tu peux alors passer en argument un pointeur vers ce tableau pour qu'elle le remplisse. C'est ce qui se passe avec la fonction pipe(), par exemple.

Toutefois, le plus approprié ici reste la définition d'une structure : elle, est définie comme un nouveau type qui peut donner naissance à des variables. Elle contient un certain nombre de sous-variables. Ces membres sont en nombre fixe mais c'est bien le cas dans la situation qui t'occupe. Donc :
```
#include <stdio.h>

typedef struct {
    char * debut;
    char * motif;
} Resultat;

Resultat expmatch (char *s)
{
    Resultat res;

    res.debut = s;
    res.motif = s+3;

    return res;
}

int
main(void)
{
    Resultat r;

    r=expmatch("string");
    printf ("Chaîne entière : %s\nMotif recherché : %s\n",r.debut,r.motif);

    return 0;
}
```
En dehors des usages triviaux, j'ai encore beaucoup de mal avec les pointeurs, aussi, la résolution de ce petit problème m'aiderait beaucoup.

Ben là, c'est un problème très particulier qui t'oblige en plus à suivre plusieurs lièvres à la fois. Donc clairement pas ce qu'il y a de plus didactique.
Pour commencer, et pour t'aider avec les pointeurs, as-tu une idée claire de ce qu'est une adresse mémoire ou pas ?
- [^] # Re: Structure
  
  Posté par Sygne (site web personnel) le 19 août 2012 à 17:47. Évalué à 2.
  
  as-tu une idée claire de ce qu'est une adresse mémoire ou pas ?
  
  Du point de vue théorique, les choses me semblent claires, mais la manipulation symbolique de ces concepts n'est pas encore intégrée, et lorsque je sors de ce que j'ai déjà fait, je galère.
  
  Je crois que j'ai surtout besoin d'entrainement, d'exemples et d'exercice.
  - [^] # Re: Structure
    
    Posté par Obsidian le 20 août 2012 à 02:54. Évalué à 10.
    Ce qu'il faut surtout savoir, c'est que le C est un langage très proche du fonctionnement réel du micro-processeur et, quand on connaît celui-ci, les caractéristiques et les limitations du C deviennent naturelles.
    
    Le micro-processeur est indépendant, en lui-même, de la machine dans laquelle il est installé et on peut ainsi retrouver le même CPU dans des ordinateurs très différents. Mais dans tous les cas, il ne communique avec l'environnement qu'avec un bus d'adresse, un bus de données et une ligne R/W (Read or Write). Les « bus » sont un ensemble de lignes électriques parallèles distribuées simultanément à tous les périphériques d'un ordinateur. Le bus d'adresse sert donc à coder un nombre binaire indiquant le numéro de l'octet en mémoire auquel on cherche à accéder, le bus de données à véhiculer la donnée, soit pour lire son contenu, soit pour écrire dedans et la ligne R/W à savoir justement laquelle des deux opérations on cherche à faire.
    
    Ça veut dire que la seule chose que voit le micro-processeur, c'est une longue plage continue d'octets, eux-mêmes numérotés de 00000000 à FFFFFFFF sur les architectures 32 bits. Ce plan mémoire est principalement occupé par des plages de RAM, quelques plages de ROM, quelques zones vides éventuellement (il y a quelques années, on aurait dit « pratiquement toujours » mais aujourd'hui, les machines équipées de 4 Gio de RAM au moins deviennent courantes) et quelques mini-plages réservées aux ports d'entrées-sorties servant à piloter les différents périphériques et composants de la machine. Ça veut dire également que la seule chose, en fin de compte, que sait faire un micro-processeur, c'est lire des données à un certain endroit, appliquer une opération logique ou arithmétique dessus, et la ré-écrire à un autre. Il est donc possible, en théorie, de piloter un ordinateur entier uniquement avec l'équivalent de « PEEK » et « POKE » en Basic.
    
    Donc, lorsque tu fais « x=1 » dans n'importe quel langage pour affecter la valeur « 1 » à la variable « x », en particulier avec un langage interprété, tu fais appel aux routines du logiciel que tu utilises qui, elles, vont aller déposer cette valeur quelque part en mémoire, dans une zone réputée décrire le contenu de la variable « x ». Le processus est généralement invisible au programmeur mais si tu te débrouilles pour savoir quel est l'adresse de cet emplacement, alors tu peux le modifier en écrivant dedans. Évidemment, c'est de la bidouille et tu fais ta manip' dans le dos du langage, mais c'est marrant de voir sa variable « muter » comme par magie.
    
    En C, en revanche, c'est totalement normal : on manipule directement les adresses mémoire sans utiliser de système sous-jacent, ne serait-ce que parce que le langage C sert justement à écrire ces systèmes. En fait, c'est pour cela qu'il a été conçu : compiler des programmes en un code autonome et restant au plus proche de la machine tout en s'affranchissant de l'assembleur et en écrivant donc des programmes en principe portables partout. Il faut aussi souligner que le C est apparu en 1972 et qu'à cette époque, les ressources systèmes étaient autrement plus limitées qu'elles le sont aujourd'hui.
    
    Maintenant, un pointeur est, comme son nom l'indique, quelque chose qui « pointe » une autre chose en mémoire, donc qui indique l'emplacement. Un pointeur est donc l'adresse mémoire de quelque chose et, par extension, la variable qui contient cette adresse. Un pointeur est donc une variable de type « adresse mémoire » et a généralement la largeur du bus d'adresse, donc quatre octets sur une machine 32 bits. En ce sens, un pointeur est donc en fait un entier non signé mais, sémantiquement parlant, il a été décidé d'en faire un type à part entière. D'abord pour informer le compilateur de ce dont il s'agit, ensuite parce que le format minimum des entiers imposé par la norme C ne correspond pas forcément avec celui du bus d'adresse de la machine cible, et enfin parce qu'il existe une arithmétique propre aux pointeurs, alors qu'en revanche, toutes les opérations applicables aux entiers numériques n'ont pas forcément de sens avec un pointeur, par exemple, le multiplier. Pas plus qu'additionner deux pointeurs d'ailleurs : ce n'est pas parce que toi, tu habites au № 5 et un de tes amis au № 8 qu'à vous deux, vous habitez au № 13. :-)
    
    Si j'utilise « & », je peux connaître l'emplacement en mémoire de mes variables et du code de mes fonctions (plus précisément, leur point d'entrée). Par exemple, en écrivant ceci :
```
#include <stdio.h>

int main (void)
{
    int x;
    int y;

    printf ("Emplacement de x : %p\n",&x);
    printf ("Emplacement de y : %p\n",&y);

    return 0;
}
```
    … j'obtiens :
```
Emplacement de x : 0x7fff93cc99dc
Emplacement de y : 0x7fff93cc99d8
```
    On voit donc clairement où mes variables sont matérialisées, et on voit également que « x » se trouve quatre octets après « y » parce mes entiers tiennent sur 32 bits eux aussi.
    
    Par contre, le seul service que te garantit un pointeur est conserver une adresse mémoire, à laquelle est censé se trouver un objet de type connu. Mais il n'y a aucune garantie que cette adresse soit valide si tu ne l'as pas initialisé correctement. Par exemple, dans l'exemple précédent, si j'affecte à mon pointeur l'adresse de « y » et que je me débrouille pour le faire avancer d'exactement deux octets, je vais me retrouver « à cheval » entre deux variables.
```
#include <stdio.h>

int main (void)
{
    int x = 0;
    int y = 0;
    unsigned int * ptr = NULL;

    printf ("Avant : x=%d ; y=%d\n",x,y);
    ptr = (unsigned int *)(((char *)&y)+2);
    *ptr = 0xffffffff;
    printf ("Après : x=%d ; y=%d\n",x,y);

    printf ("%p %p %p\n",&x,&y,ptr);

    return 0;
}
```
    … ce qui donne :
```
Avant : x=0 ; y=0
Après : x=65535 ; y=-65536
0x7fff720800b4 0x7fff720800b0 0x7fff720800b2
```
    On voit que les deux variables sont affectés. Le C me laisse le faire. Il me laisse même écrire n'importe où en mémoire si j'en ai envie, écrasant éventuellement les autres programmes ou le système d'exploitation, comme on pourrait le faire en assembleur. Heureusement, le mode protégé est désormais sur toutes les machines et c'est le micro-processeur lui-même qui refusera de continuer si on lui demande de lire ou d'écrire dans une zone non explicitement déclarée par ton O.S., déclenchant la célibrissime « segfault ».
- [^] # Re: Structure
  
  Posté par liberforce (site web personnel) le 20 août 2012 à 13:57. Évalué à 2.
  Mouais… Suis pas fan de retourner directement des structures… J'ai tendance à passer par adresse que par valeur, parce que ton truc ne marche plus le jour où tu retournes une grosse structure (enfin si, ça marche, mais c'est lent).
```
#include <assert.h>

void expmatch (char *s, char **debut, char **motif)
{
    assert (debut != NULL);
    assert (motif != NULL);
    *debut = s;
    *motif = s+3;
}

int
main (void)
{
    char *debut = NULL;
    char *motif = NULL;

    /* hop, on passe l'adresse du pointeur plutôt que son contenu */
    expmatch ("string", &debut, &motif);

    printf ("Chaîne entière : %s\nMotif recherché : %s\n", debut, motif);
    return 0;
}
```
  Alors oui, dans le prototype, on voit du pointeur double, mais il ne faut pas avoir peur :)
  
  Et pour bien comprendre les pointeurs, un petit cours avec Binky:
  http://www.youtube.com/watch?gl=FR&hl=fr&v=6pmWojisM_E
  
  Et pour bien lire les déclarations:
  http://www.antlr.org/wiki/display/CS652/How+To+Read+C+Declarations
  (et comme le lien a l'air un peu cassé:)
  http://web.archive.org/web/20090318154941/http://www.antlr.org/wiki/display/CS652/How+To+Read+C+Declarations
  - [^] # Re: Structure
    
    Posté par Sygne (site web personnel) le 20 août 2012 à 17:08. Évalué à 2.
    
    Étant donné que le logiciel que je modifie retournait directement le pointeur, j'ai utilisé la solution d'Obsidian, pour qu'il retourne une structure, car cela modifie les sources de façon moins intrusive, ce qui était donc plus simple à mettre en place.
    
    Mais ta remarque m'intrigue :
    
    le jour où tu retournes une grosse structure […] ça marche, mais c'est lent.
    
    La différence est vraiment notable ? À partir de quand on parle de grosse structure ?
    - [^] # Re: Structure
      
      Posté par liberforce (site web personnel) le 20 août 2012 à 17:42. Évalué à 3.
      
      Mettons que tu as une structure qui contient un tableau d'octets, c'est une très mauvaise idée de le retourner par valeur. Tu vas te retrouver à copier toute la structure alors que tu aurais juste pu passer l'adresse d'une structure déjà allouée à remplir. Copier un pointeur (8 octets en 64 bits) est plus rapide que de copier beaucoup plus d'octets…
      - [^] # Re: Structure
        
        Posté par benoar le 23 août 2012 à 23:58. Évalué à 2.
        
        À noter que sur les architectures ayant un nombre certains de registres (genre RISC), il me semble que ce genre de retour de structures se fait par registre en dessous d'une certaine taille. C'est plus rapide que de passer par la pile, ou que de manipuler des pointeurs.
  - [^] # Re: Structure
    
    Posté par Obsidian le 20 août 2012 à 19:04. Évalué à 4.
    Mouais, c'est un débat récurrent. Il y a même un flag à passer à GCC si on veut qu'il nous signale ce genre de choses. Pour autant, je trouve que c'est encore une des nombreuses mesures parties d'un bon sentiment et qui se sont avérées plus pénibles qu'autre chose à l'usage. Il ne faut pas oublier que le propre d'une fonction, en mathématiques, est d'être une expression évaluable et dont la valeur dépend du paramètre. Qu'on utilise les arguments en entrée et en sortie et qu'on utilise le code de retour que comme état du bon déroulement du processus, c'est un paradigme intéressant, certes, mais il s'agit alors de simples procédures, et plus de fonctions à proprement parler.
    
    Ça commence à devenir franchement lourdingue lorsque ce flag est imposé à la va-vite en entreprise et que ça t'empêche de faire un usage judicieux de tes structures. Le cas d'école que l'on brandit à chaque fois est celui des nombres complexes, bien sûr. Mais de façon similaire, et c'est intéressant parce que c'est un cas vécu, on pourrait parler des timestamps, par exemple.
    
    J'ai travaillé sur un filtre qui loguait certains événements sous forme d'objets datés avec une « struct timeval » utilisée entre autres par gettimeofday() et qui embarque un nombre de secondes et un nombre de micro-secondes. Au bout d'un moment, pour pouvoir les comparer facilement et traiter les échéances, j'ai fini par écrire une panoplie de fonctions pour pouvoir additionner, soustraire et comparer des durées, ainsi que quelques autres opérations.
```
struct timeval timeadd (struct timeval, struct timeval); /* Additionne deux durées */
struct timeval timesub (struct timeval, struct timeval); /* Soustrait deux durées  */
int            timecmp (struct timeval, struct timeval); /* Compare deux durées    */
```
    ce qui me permettait d'écrire directement des trucs du style :
```
if (timecmp(timesub(datefin,datedebut),dureemaximum)>0) action_approriee();
```
    Essaie de faire facilement la même chose avec des pointeurs. Tu te retrouves obligé de tout allouer toi-même et décomposer ton calcul. Ensuite, soit tu fais des malloc()/free() en gérant les erreurs éventuelles ce qui, même à l'exécution, est autrement plus long à traiter que huit octets passés dans la pile, soit tu déclares à l'avance des variables locales pour recevoir des résultats et là, dans un cas comme dans l'autre, les résultats se retrouveront dans la pile, avec la conséquence supplémentaire que tes variables auront une existence plus longue que les paramètres et la valeur de retour de chacune de ces fonctions.
    
    Alors autant je suis le premier à dire qu'il faut s'efforcer autant possible d'être sobre avec la pile (on voit beaucoup de débutants allouer des tableaux d'entiers de 2 Gio) et ne pas l'encombrer pour rien, autant je pense que dans ce genre de cas, aujourd'hui, on peut se permettre de passer des objets jusqu'à une centaine d'octets quand leur taille est fixe, qu'il faut en produire beaucoup et qu'ils sont éphémères.
# Merci!

Posté par Sygne (site web personnel) le 19 août 2012 à 17:51. Évalué à 2.

Vos exemples sont très clairs.

Je remarque que je cherchais une solution compliquée à un problème pourtant simple…

Merci !
- [^] # Re: Merci!
  
  Posté par Obsidian le 19 août 2012 à 19:02. Évalué à 4.
  
  C'est souvent le cas ! :-) Un problème bien compris et/ou bien exposé est à moitié résolu.
  
  Bonne chance pour la suite.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.