fonction qui renvoie un tableau

bonjour
J'ai une question qui peut paraitre simple, mais je n'arrive pas a trouver la solution.
J'aimerais créer une fonction qui renvoie un tableau (de taille donnée):

Code:

---

1 2 3 4 5 6 7 8 9

char fndkk(void) { char c; for(int i=0;i<4;i++){ char c[i]=i; } return c; }

---

Forcément c'est faux, mais quel serait la bonne déclaration de fndkk?
(on pourrait utiliser autre chose que les char)
merci

Code:

---

1 2 3 4 5 6 7 8 9

char* fndkk(unsigned int taille) { char* tab = new char[taille]; for (unsigned int i = 0; i < taille; ++i) { tab[i] = i; } return tab; }

---

n'oublie pas de faire delete [] tab apres avoir appellé ta fonction

merci
corrige moi si je me trompe, mais s'agit il d'un pointeur sur fonction?

pourquoi mettre le signe & devant la fonction?

DKK_API char fndkk(void)
{
char c;
for(int i=0;i<4;i++){
char c[i]=i;
}
return c;
}

déjà ton c est un simple caractère pas un tableau,

alors pour commencer simple :

DKK_API c'est quoi? des objets?


pour renvoyer un tableau de caracteres:


char* fndkk(void)
{
char c[4];
for(int i=0;i<4;i++){
char c[i]=i;
}
return *c;
}

oups pris de vitesse

pour le signe & c'est une erreur il n'est pas bon, je l'ai enlevé.

Ce n'est pas un pointeur vers une fonction mais c'est une fonction qui renvoie un pointeur.

Et les pointeurs 'sont' des tableaux.

pour l'utiliser tu fais :

Code:

---

1 2 3 4

unsigned int taille = 4; char* tab = fndk(taille);   delete [] tab;

---

sleigh, tu alloues le tableau statiquement, il est detruit a la fin de la fonction et tu renvoies donc un pointeur non valide ! D'ailleurs tu ne renvoie pas le tableau mais la p^remiere valeur du tableau.
Tu dois faire un new dans ta fonction ou alors tu alloue ton tableau statique avant l'appel et tu passe ton tableau en argument de la fonction et dans ce cas elle ne renvoie rien.

est t on obligé de faire un new char?
j'y avais pensé, mais je me suis dit que ce n'etait pas la peine.
car la déclaration le créerait automatiquement.

Si tu veux créer ton tableau à l'intérieur de ta fonction, il faut l'allouer dynamiquement (avec new ou malloc) pour pouvoir l'utiliser une fois sorti de ta fonction.

Renseigne toi sur les allocations dynamique vs statiques.

Tu peux ne pas utiliser de new si ton tableau a été déclaré en amont de la fonction, mais dans ce cas il faut le passer en argument. C'est également une pratique courante :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

void remplir(char* tab, unsigned int taille) { for (unsigned int i = 0; i < taille; ++i) { tab[i] = i; } }   int main() { unsigned int taille = 4; char tab[taille];   remplir(tab, taille); }

---

Tu ne peux pas retourner un tableau.
C'est bizarre mais c'est comme ça.

Si tu veux faire une telle chose, il faut mettre ton tableau dans une structure.
std::tr1::array permet d'automatiser cela.

Bien sur que si on peut.
Pourquoi ne peut-on pas?

NiamorH j'ai regarder ton programme ave le tableau en parametre car j'en avait également besoin et sa ne marche pas le compilateur me sort une erreur:

Citation:

---

1>e:\Partie.cpp(22) : error C2664: 'Partie::PlacementBateaux'*: impossible de convertir le paramètre 1 de 'int [25][25]' en 'int **'

---

pour info voila mon code :

Citation:

---

void PlacementBateaux(int **);

---

==> Dans ma classe

Citation:

---

Partie1.PlacementBateaux(TabBateauxJ1);

---

==> appel de fonction

Citation:

---

void Partie::PlacementBateaux(int ** Tab){}

---

==> Declaration fonction

Citation:

---

Bien sur que si on peut.
Pourquoi ne peut-on pas?

---

Parce que le standard dit que c'est interdit.

Code:

---

1 2 3 4 5

int foo()[10] { int tmp[10] = {0}; return tmp; }

---

Ce code ne compilera pas.

Citation:

---

Code:

---

test.cpp:1: erreur: ‘foo’ declared as function returning an array

---

---

Il faut faire

Code:

---

1 2 3 4 5 6 7 8 9 10

struct tableau { int value[10]; };   tableau foo() { tableau tmp = {0}; return tmp; }

---

tigger_riric, il faut eviter au maximum les tableaux 2D, fait plutot un tableau 1D de dimension [largeur * longueur] et accede aux elements comme ça : [y*largeur + x]. La ca marchera.

loufoque, un char* est un tableau et rien n'interdit de renvoyer un char*, alors ce que tu dis me semble bizare ?

Evidement que le code que tu as donné ne compile pas, mais celui que j'ai donné compile lui et le resultat est qu'il renvoie un tableau.

Citation:

---

un char* est un tableau

---

un char* est un pointeur sur char. Après, que ce pointeur pointe sur plusieurs éléments (un tableau) ou non, c'est déjà une autre histoire.

Ne jouons pas sur les mots, ce que loufoque veut dire c'est que le C++ n'autorise pas de renvoyer directement un tableau, mais on peut évidemment le faire via des moyens détournés comme renvoyer un pointeur vers celui-ci.

Citation:

---

un char* est un pointeur sur char. Après, que ce pointeur pointe sur plusieurs éléments (un tableau) ou non, c'est déjà une autre histoire.

---

Alors, sur quoi peut il pointer s'il peut pointer sur autre chose qu'un tableau?

Citation:

---

Envoyé par deubelte

Alors, sur quoi peut il pointer s'il peut pointer sur autre chose qu'un tableau?

---

Sur un seul caractère, ou encore sur rien (pointeur nul).

Sur un simple char. Mais même dans ce cas on peut considérer que c'est un tableau de 1 élément.

EDIT : ou 0 bien sur !!!

La seule différence c'est la façon dont on doit le détruire. S'il s'agit d'un vrai tableau il faut appeller delete [] sinon delete seulement.

Mais il ne faut pas présenter les choses à quelqu'un qui commence en c++ en lui disant qu'on ne peux pas renvoyer ou passer en parametre un tableau sans expliquer. Et encore moins en lui proposant de renvoyer une structure, ce qui n'est utilisé que dans des cas très précis.

L'usage reste quand même le char*

Citation:

---

Envoyé par NiamorH

L'usage reste quand même le char*

---

Pour moi ce serait plutôt std::string ou std::vector<char> (selon l'utilisation qui en est faite).

Les solutions proposées plus haut allouent un tableau sur le tas et renvoient un pointeur vers son premier élément. Ce qui veut dire qu'en plus il faudra le libérer quelque part en dehors de la fonction, ce qui est tout sauf propre.
Ma solution retourne tout simplement un tableau, sur la pile.

Oui mais tu fais une copie complete de ton tableau au moment du retour si je ne me trompe pas.

Si ton tableau est enorme cela peut etre genant.

De plus, si tu veux faire un tableau d'objets, avec ta methode tu est obligé de te taper les constructeurs par copie.

Si on ne veut pas faire de new j'ai donné aussi une solution en passant le tableau en parametre.

Citation:

---

Oui mais tu fais une copie complete de ton tableau au moment du retour si je ne me trompe pas.

---

Cela dépend des cas.
Dans le cas où la valeur de retour est utilisée pour initialiser un nouveau tableau, non.
Dans le cas où la valeur de retour est utilisée pour assigner une nouvelle valeur à un tableau existant, bien évidemment, oui, les données ont besoin d'être copiées.

Enfin, aucune copie effectuée n'est inutile.

Citation:

---

De plus, si tu veux faire un tableau d'objets, avec ta methode tu est obligé de te taper les constructeurs par copie.

---

Tout conteneur copiable se doit de contenir des éléments eux-mêmes copiables, c'est évident.

perso, je ne perds pas mon temps a ecrire des constructeurs par copie pour mes objets ou alors dans de rares execptions pour des objets très basiques.

Dans ce cas-là il faut que tu rendes tes objets non copiables avec un constructeur de copie privé, sinon un problème est vite arrivé.

De toute façon c'est très simple de faire des objets copiables, il suffit de commencer par utiliser std::vector et pas des pointeurs par exemple.

Tout ce que tu me dis la semble s'appliquer à des applications non orientées temps réel.

Tu peux pas toujours te permettre de faire des copies de tableaux qui font plus de 100Mo en RAM par exemple.

Si on a la possibilité d'éviter les copies inutiles autant le faire.

TR ? -> queues de messages et futures sont pas mal pour les échanges inter-threads.

Sinon, vector powa' ! Avec un bon compilo, RVO et RNVO règnent en maitre -- le vieux compilo de Sun m'a d'ailleurs surpris à plus d'une occasion à ce sujet. "Bientôt" on aura les rvalue références pour les cas non optimisables en R(N)VO.

Mieux vaut un truc qui tourne juste en situation dégradée, plutôt qu'un truc qui se viande à la première poussière d'octet sous le tapis.

Et puis, si tu sais que tu as vraiment 100megs, soit tu interdis la copie, soit tu enforces la sémantique de déplacement, mais en aucune cas tu ne peux faire confiance aux opérations de copie générées par défaut.