Fonction retournant un pointeur...
Le
thierryabrard
Bonjour,
Lorsque l'on défini une fonction, peut-elle retourner un pointeur
(tableau) ?
Actuellement, j'ai défini quelques fonctions du type :
void MaFonction (char Data1, char Data2)
{
le calcul
Resultat[0] = ?;
Resultat[1] = ?;
}
Pour réutiliser mon tableau Resultat et ces données dans le main, je
le défini donc en variables globale (char Resultat[2]). Mais je trouve
que cette méthode n'est pas très simple à utiliser par la suite en
effet, dans le main je me retrouve avec des fonctions :
Mafonction (Octet1, Octet2)
et faut ensuite se souvenir de quelle variable globale y est
associé
J'aimerais donc savoir si il est possible en C (j'ai encore beaucoup à
découvir) d'avoir une fonction du style : Resultat =
MaFonction(Octet1, Octet2) avec Resultat comme tableau
Faut-il faire jouer les pointeurs là dedans ?
J'ai essayé :
Char * MaFonction (char Data1, char Data2)
{
char Resultat[2];
mes calculs (Resultat[0] = ?, Resultat[1]=?)
return Resultat;
}
puis dans le main :
Resultat[0]=Mafonction(Octet1, Octet2)
Mais Resultat[1] n'est pas correct
Si vous avez une piste à ce sujet pour obtenir ce que je souhaite
Je vous remercie,
TA
Lorsque l'on défini une fonction, peut-elle retourner un pointeur
(tableau) ?
Actuellement, j'ai défini quelques fonctions du type :
void MaFonction (char Data1, char Data2)
{
le calcul
Resultat[0] = ?;
Resultat[1] = ?;
}
Pour réutiliser mon tableau Resultat et ces données dans le main, je
le défini donc en variables globale (char Resultat[2]). Mais je trouve
que cette méthode n'est pas très simple à utiliser par la suite en
effet, dans le main je me retrouve avec des fonctions :
Mafonction (Octet1, Octet2)
et faut ensuite se souvenir de quelle variable globale y est
associé
J'aimerais donc savoir si il est possible en C (j'ai encore beaucoup à
découvir) d'avoir une fonction du style : Resultat =
MaFonction(Octet1, Octet2) avec Resultat comme tableau
Faut-il faire jouer les pointeurs là dedans ?
J'ai essayé :
Char * MaFonction (char Data1, char Data2)
{
char Resultat[2];
mes calculs (Resultat[0] = ?, Resultat[1]=?)
return Resultat;
}
puis dans le main :
Resultat[0]=Mafonction(Octet1, Octet2)
Mais Resultat[1] n'est pas correct
Si vous avez une piste à ce sujet pour obtenir ce que je souhaite
Je vous remercie,
TA
[...]
| > struct cellule {
| > /* ... */
| > unsigned int suivant;
| > };
|
| > struct cellule liste_chainee[LISTE_TAILLE_MAX];
|
| En effet, mais là, bonjour le gaspillage de mémoire ou la limitation :/
Cela dépend du projet et de l'utilisatio.
| enfin, ça + realloc, pkoi pas :)
Celui qui fait realloc sur un tableau alloué statiquement doit être
considéré comme un individu dangereux pour la communauté.
-- Gaby
Je ne suis pas d'accord, le tableau et la liste chainée ont des applications
différentes et ne sont pas uniquement des zones de stockage. La liste
chainée est particulièrement utile quand on pratique des suppressions et
des insertions d'éléments quelconques, et explose dans ce cas, le tableau.
On peut concevoir des liste chainées avec un minimum d'allocation, et même
en utilisant que de la mémoire automatique.
--
Richard
certes
Oui, bien sûr, c'est pas ce que je voulais dire, je voulais dire ce type
de liste plus un tableau alloué avec malloc/realloc
--
Gael Le Mignot "Kilobug" - - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
Meme pas clair. Il faut faire des mesures. Ca depend extraordinairement du
nombre d'insertions/suppressions par rapport a la taille de la structure.
On a depuis quelques annees des structures intermediaires, dont les
performances theoriques sont plus dures a evaluer, qui ont souvent des
comportements amortis bien meilleurs que les structures simples
(fractional cascading, arbres pagodes, j'en passe et des meilleures...)
J'ai toujours un peu tendance a considerer qu'on passe beaucoup de temps,
dans les cours d'algorithmique, a parler de listes chainees, arbres
equilibres et autres objets sympathiques... entre autres parce que c'est
important de savoir bien les programmer, et aussi parce que l'analyse est
simple: on passe quinze plombes a expliquers les perfs du tri par tas, deux
plombes de plus pour quicksort, et on passe generalement Shell-Metzner sous
silence, parce qu'on sait tres mal l'analyser...
Dans les programmes pratiques, se cachent plus souvent de betes tableaux
et des tables de hachage qu'on ne le pense. Le travail du programmeur est
bien sur different, puisqu'il doit aller passer un peu de temps a regarder
les performances pratiques au detriment des aspects theoriques (en bref,
mettre cinq minutes les mains dans le cambouis)... et ca, j'ai vu peu de
cours qui expliquaient les performances d'un programme par rapport au
concept de localite et de bande passante de la memoire.
Quant aux conceptions de notre cher ami Hurdien, elles ne m'etonnent pas
du tout. Cette attitude du `tout generique, on ne va surtout pas limiter
notre utilisateur' alliee a `ca coute pas cher en performance de toutes
facons', c'est de la qu'on sort nos derniers programmes gigantesques qui
se trainent, qui de generalite en generalite, de 2% de perf perdues par ci
a 3% de perf perdues par la, se retrouvent souvent inmaintenables, et 100%
plus lents que les petits programmes un peu plus limites, mais qui au bout
du compte, sont plus conviviaux pour l'utilisateur.
Je pourrais citer bien des exemples (gnu-m4, GCC, en sont deux que je
connais bien...)
|
| > Voici donc le couplet standard, vite vu.
| >
| > Supposons qu'on ait une structure de donnees a stocker en nombre
| > consequents, disons struct machin.
| >
| > - on peut faire des listes chainees avec, ce qui implique plein de
| > pointeurs et de malloc, et des gros problemes de localite des donnees.
| >
| > - on peut tout stocker dans un tableau de taille limitee, quitte a faire
| > un coup de realloc() lorsque le tableau deborde.
| >
| > La 2e approche explose tres regulierement la premiere en termes de
| > performances.
|
| Je ne suis pas d'accord, le tableau et la liste chainée ont des applications
| différentes et ne sont pas uniquement des zones de stockage.
Je suppose que c'est le moment de sotir son cours sur les types
abstraits de données.
-- Gaby
ne crois-tu pas desfois que cela est nécessaire de limiter
l'utilisateur ?
N'est-ce pas ce qu'il se cache derrière la notion de "sécurité" ?
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Voilà, cela dépend de l'application, c'est ce que je voulais faire
remarquer.
--
Richard
Non, c'est plutôt l'heure de sortir pour aller faire la fête.
--
Richard
oulà malheureux ! mais le samedi soir, c'est le meilleur moment pour
coder au calme.
--
DINH V. Hoa,
etPan! - newsreader, mail user agent -- http://libetpan.sf.net/etpan
Content-Transfer-Encoding: 8bit
DINH Viêt Hoà
--=-=- Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
|
| > Non, c'est plutôt l'heure de sortir pour aller faire la fête.
T'habite dans le nord ?
| oulà malheureux ! mais le samedi soir, c'est le meilleur moment pour
| coder au calme.
de là où j'écris, il est midi :-)
[ mais c'est vrai, ils ont prévu un barbecue géant -- « the best and
the biggest in the world » comme ils disent ]
-- Gaby
--=-=-=--