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
Richard Delorme
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. 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
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. 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.
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. 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
kilobug
(Gaël Le Mignot) writes: [...]
| > 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.
certes
| 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é.
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
kilobug@freesurf.fr (Gaël Le Mignot) writes:
[...]
| > 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.
certes
| 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é.
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" - kilobug@nerim.net - 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
| > 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.
certes
| 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é.
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
espie
In article <3fd1fd3f$0$6982$, Richard Delorme wrote:
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.
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...)
In article <3fd1fd3f$0$6982$7a628cd7@news.club-internet.fr>,
Richard Delorme <abulmo@nospam.fr> wrote:
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.
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...)
In article <3fd1fd3f$0$6982$, Richard Delorme wrote:
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.
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...)
Gabriel Dos Reis
Richard Delorme writes:
| | > 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
Richard Delorme <abulmo@nospam.fr> writes:
|
| > 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.
| | > 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
DINH Viêt Hoà
évalué la taille maximum de la liste, ce que l'on peut résoudre par limiter la taille de la liste, ce qui permet dans le meilleur des cas d'obtenir un unique malloc(), voire zéro dans le cas d'une déclaration statique.
tu sais ce que je pense de ces limitations là... ça soit limite vraiment l'utilisateur, soit on est large et on gaspille bcp de mémoire
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
évalué la taille maximum de la liste, ce que l'on peut résoudre par
limiter la taille de la liste, ce qui permet dans le meilleur des
cas d'obtenir un unique malloc(), voire zéro dans le cas d'une
déclaration statique.
tu sais ce que je pense de ces limitations là... ça soit limite
vraiment l'utilisateur, soit on est large et on gaspille bcp de
mémoire
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
évalué la taille maximum de la liste, ce que l'on peut résoudre par limiter la taille de la liste, ce qui permet dans le meilleur des cas d'obtenir un unique malloc(), voire zéro dans le cas d'une déclaration statique.
tu sais ce que je pense de ces limitations là... ça soit limite vraiment l'utilisateur, soit on est large et on gaspille bcp de mémoire
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
Richard Delorme
In article <3fd1fd3f$0$6982$, Richard Delorme wrote:
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.
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...)
Voilà, cela dépend de l'application, c'est ce que je voulais faire remarquer.
-- Richard
In article <3fd1fd3f$0$6982$7a628cd7@news.club-internet.fr>,
Richard Delorme <abulmo@nospam.fr> wrote:
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.
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...)
Voilà, cela dépend de l'application, c'est ce que je voulais faire
remarquer.
In article <3fd1fd3f$0$6982$, Richard Delorme wrote:
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.
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...)
Voilà, cela dépend de l'application, c'est ce que je voulais faire remarquer.
-- Richard
Richard Delorme
Richard Delorme writes:
| | > 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.
Non, c'est plutôt l'heure de sortir pour aller faire la fête.
-- Richard
Richard Delorme <abulmo@nospam.fr> writes:
|
| > 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.
Non, c'est plutôt l'heure de sortir pour aller faire la fête.
| | > 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.
Non, c'est plutôt l'heure de sortir pour aller faire la fête.
-- Richard
DINH Viêt Hoà
Non, c'est plutôt l'heure de sortir pour aller faire la fête.
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
Non, c'est plutôt l'heure de sortir pour aller faire la fête.
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
