ma boucle marche pas !!!

[Céroce]

>Céroce

Justement en utilisant des classes comme NSMutableARRay et compagnie on mets des garde-fous qu'il ne semble pas y avoir avec des tab[] et consorts. tu fais tab[10000000] sans problème, mais le résultat est plus que douteux à l'execution. Par contre avec un NSMutableArray...
Autre truc : tu veux envoyer un message whatTimeIsItPlease à tous tes objets d'un NSArray. Tape :
[montableau makeObjectsPerformSelectorselector(whatTimeIsItPlease)]
(A condition que tes objets y répondent) . Je trouve ca supercool, mais c'est peut-être une question de gout

Non, c'est pas une question de goût, c'est une question de lisibilité (regarde, le programme en C# est bien plus lisible) et de PERFORMANCES.

Créer des objets (allocation dynamique) et leur envoyer des messages prend beaucoup plus de temps que de réserver un simple tableau (sur la pile, d'où l'impossibilité de réserver 40 000 000 d'octets). Je ne dénigre pas l'utilité des NSArray pour autant.
Les langages basés sur le C (comme ObjC) restent proches de la machine. Ça présente des avantages (vitesse, compacité) mais aussi de grandes responsabilités sur le développeur.

 

[Didier Guillion]

Bonjour,

Oui, et on se pose la question si la syntaxe d'Objectice C (ou autre C sharp) est encore "humaine".

Personnellement, je prefere une syntaxe C pure et dure bien verbeuse et abondamment commentée.

Cordialement

 

[Céroce]

Une programme qui marche:



- (IBAction)genererid)sender
{
int nombre;
int nombres[NOMBRES_A_GENERER];
int compteurNombres;
int compteurDeja;
BOOL dejaDansTableau;

// Le premier nombre est forcément absent du tableau
nombres[0] = (random() % 49) + 1;

// Pour les autres nombres
for(compteurNombres = 0; compteurNombres < NOMBRES_A_GENERER; compteurNombres++)
{
do
{
nombre = (random() % 49) + 1;

dejaDansTableau = NO;
for(compteurDeja = 0; compteurDeja < compteurNombres; compteurDeja++)
{
if(nombres[compteurDeja] == nombre)
{
dejaDansTableau = YES;
break;
}
}
} while (dejaDansTableau == YES);

// On a trouvé un nouveau nombre; on le stocke
nombres[compteurNombres] = nombre;
}

// Affichage
[champ1 setIntValue:nombres[0]];
[champ2 setIntValue:nombres[1]];
[champ3 setIntValue:nombres[2]];
[champ4 setIntValue:nombres[3]];
[champ5 setIntValue:nombres[4]];
[champ6 setIntValue:nombres[5]];
[champ7 setIntValue:nombres[6]];
}

 

[_remi]

Non, c'est pas une question de goût, c'est une question de lisibilité (regarde, le programme en C# est bien plus lisible) et de PERFORMANCES.

Créer des objets (allocation dynamique) et leur envoyer des messages prend beaucoup plus de temps que de réserver un simple tableau (sur la pile, d'où l'impossibilité de réserver 40 000 000 d'octets). Je ne dénigre pas l'utilité des NSArray pour autant.
Les langages basés sur le C (comme ObjC) restent proches de la machine. Ça présente des avantages (vitesse, compacité) mais aussi de grandes responsabilités sur le développeur.

Pourtant en C# j'initialise bien un objet avec le constructeur: int[] tab = new int[7];
seulement en C# la condition: if ((i != j) && (tab == tab[j])) fonctionne.

alors que en ObjectiveCocoa: if( (i != j) && ([remTableau objectAtIndex: j] == [remTableau objectAtIndex: i])) non.

 

[_remi]

< Cérose:

Merci j'allais abandonner la comparaison des objets dans le tableau pour l'écrire en C. Je préfère la syntaxe par point, la gestion de la memoire et les espaces nommés du C# sans remettre en cause l'efficacité de l'ObjectiveCocoa, je m'intéresse à ces langages par curiosité je développe surtout des produits multimédia sur IShell...

 

[tatouille]

ne laisse pas tomber

mais

1/ utilises des tableaux simples au lieu de mutable ca ne te sert à rien

2 / une comparaison lineaire est toujours mieux que recursive


3/ print ta sortie dans tes 2 boucles et tu vas comprendre ce que t'a dit arnolix

 

[arnolix]

Bon en y regardant de plus près il y a un truc qui m'a échappé c'est le test :

[remTableau objectAtIndex: i] == [remTableau objectAtIndex: j]


C'est une erreur classique, en fait [remTableau objectAtIndex: i] renvoit l'adresse de l'objet qui se trouve à l'index i du tableau, et non pas la valeur de l'objet (ici un nombre). Avec ca tu testes donc si deux objets sont distincts ou non physiquement, mais qui peuvent en fait avoir des champs égaux (des jumeaux en quelque sorte).

Il faut utiliser la méthode -isEqual: qui appelle la méthode -description pour comparer leur contenu.

Par exemple, tape quelque part dans ton code, et consulte ta console lors de l'éxecution :

NSLog(@"[remTableau objectAtIndex: i] = %d",[remTableau objectAtIndex: i])

ainsi que :

NSLog(@"[[remTableau objectAtIndex: i] description] = %@",[[remTableau objectAtIndex: i] description])

Tu verras alors la différence

Pour un test correct, ca devrait donner :

[[remTableau objectAtIndex: i] isEqual:[remTableau objectAtIndex: j]]

Essaie le.

PS : suis pas trop dispo en ce moment. Mes réponses tarderont peut-être

 

[arnolix]

>céroce et guillon


Suis pas un défenseur de Obj-C et de sa syntaxe qui devient lourdingue.

Sauf que le problème de -remy c'est d'utiliser correctement le framework cocoa .

Son truc de fabriquer des tableaux, on le fait comme on veut.

L'avantage de cocoa c'est de disposer, pour un tableau par exemple, de fonctionnalités poussées sans avoir à les implémenter soi-même. Mais ce au prix de la vélocité.

C'est au dévellopeur de faire ces choix. Et c'est tant mieux.

 

[_remi]

Bon en y regardant de plus près il y a un truc qui m'a échappé c'est le test :


Pour un test correct, ca devrait donner :

[[remTableau objectAtIndex: i] isEqual:[remTableau objectAtIndex: j]]

Essaie le.

désolé mais je crois que la syntaxe n'est pas bonne... il me dit qu'il y a une erreur avant isEqual.

mais Bon week-end

 

[_remi]

Une programme qui marche

// Le premier nombre est forcément absent du tableau
nombres[0] = (random() % 49) + 1;

}

mais non pourquoi ?
il marche très bien sans cette ligne...
merci, tant pis pour cocoa...

 

[Céroce]

En effet.
C'est une optimisation et le programme me paraît plus clair ainsi.
Là, c'est une affaire de goût pour le coup.